Internet Engineering Task Force M. Chen Internet-Draft L. Su Intended status: Informational China Mobile Expires: 16 December 2024 14 June 2024 the architecture of network attestation for secure routing draft-chen-nasr-architecture-00 Abstract This document describes the architecture of Network Attestation for Secure Routing(NASR). In this architecture, there are Three roles defined: attester, validator, and orchestration controller. Its' purpose is to attest to a trusted path and make sure the forwarding complies with the path, including node static security assessment, dynamic security defense, and routing path orchestration, forwarding path and security service consistency validation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Chen & Su Expires 16 December 2024 [Page 1] Internet-Draft archi-nasr June 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. NASR architecture . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Components . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Attester . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. Orchestration Controller . . . . . . . . . . . . . . 4 2.1.3. Validator . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 5 3. Orchestration Controller . . . . . . . . . . . . . . . . . . 6 4. Validator . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Final node validation mode . . . . . . . . . . . . . . . 7 4.2. Intermediate node validation mode . . . . . . . . . . . . 7 5. Trusted path procedures . . . . . . . . . . . . . . . . . . . 8 5.1. Indirect Model . . . . . . . . . . . . . . . . . . . . . 8 5.2. Direct Model . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction In the early stages of internet development, users' demand for the network was that access everywhere, but now users demand is to securely connect to everywhere. Users have higher requirements for data privacy and security, which includes both regulations and business requirements, and they are not satisfied with pure encryption-based data security measures that do not have any control over the underlay networks, they want their flows to transport on trusted devices, trusted links, trusted operating environments or trusted services which have been freshly appraised and verified for trustworthiness, avoid any exposure to insecure or untrusted devices. At least, the following three parts need to be included. 1.Security of static nodes: the trustworthy of nodes in the routing path need to be attested; 2.Routing path defense security: this requires the ability to resist attacks at the routing level, in terms Chen & Su Expires 16 December 2024 [Page 2] Internet-Draft archi-nasr June 2024 of implementation, it is required that ISPs can match security defense capabilities during routing scheduling; 3.Path Validation: on the premise that a secure path has been formed, ensure that user traffic is indeed forwarded according to the pre-formed path. Therefore, this draft attempts to propose an architecture for NASR. 2. NASR architecture There are three roles in the NASR architecture, attester, orchestration controller and validator. The north-south messages can be classified as control plane, the east-west messages can be classified as data plane. The architecture of NASR involves both control plane and data plane. Orchestration controller obtain node information through north-south messages, then orchestrate forwarding paths, When forwarding east- west traffic, it is necessary to ensure that the actual forwarding path is consistent with the planned path, and the actual security services provided are also consistent with the planned ones. Path validation belongs to control plane, and proof of transit belongs to data plane. +--------------------------+ | Orchestration Controller | +--------------------------+ / \ / \ / \ / \ / \ / \ +------------+ +-----------+ | Attester +-----------+ Validator | +------------+ +-----------+ Figure 1: NASR architecture 2.1. Components 2.1.1. Attester Attester: attested node can provide the trusted and healthy information to the contoller, the attested node consists of two types, one is the Forwarding Function and the other is the Security Function. The security function include the security capabilities that the routing node itself can provide externally, the ability to security resource pool supported by virtualization, and the ability Chen & Su Expires 16 December 2024 [Page 3] Internet-Draft archi-nasr June 2024 to provide specialized hardware security devices, such as IPS/ firewall. In Remote ATtestation procedureS (RATS), one peer (the "Attester") produces believable information about itself ("Evidence") to enable a remote peer (the "Relying Party") to decide whether or not to consider that Attester a trustworthy peer, but in NASR attester produces path-level trust attributes, include hardware, software, secure configurations, integrity of routing forwarding table, usable security capabilities and so on to enable the controller to select trusted nodes to form routing paths. 2.1.2. Orchestration Controller Orchestration controller: the controller shouder the responsibility for verifing the authenticity of the information. The controller matches the user's requirements to form a trusted routing path. The controller can obtain informations from nodes in the network, matches the user's requirements, implement network programming to form a trusted routing path, and distribute the policies to the forwarding nodes. 2.1.3. Validator Validator: the validator verifies whether the forwarding path is consistent with the issued routing policy and whether the security service is truly provided, by proof of transit which are tags recorded in data packets. After path policy execution or during the execution of routing policies, validator verifies if the path is executed as scheduled and the security service is truly provided. 2.2. Control Plane The north-south messages can be classified as control plane, path validation belongs to control plane. The control plane involves three functions. Firstly, orchestration controller obtain evidence or attestation result from attested node, after requirement matching and orchestration, a path strategy has been formed. Secondly, the controller issue the path policy to the attested node, such as router. Thirdly, during the forwarding process, cryptographic methods can be used to mark the proof of transit, through the proof of transit, the validator can verify whether the actual forwarded path comply with the distributed path. Chen & Su Expires 16 December 2024 [Page 4] Internet-Draft archi-nasr June 2024 +--------------------------+ +----------+ | Orchestration Controller +-------+Validator | +----------------+---------+ +----------+ ^ | ^ | | | | | | Evidence Path | Path| | Distribution Validation | | | +-----|----------v-----------------------|-------+ | +---+-------------+ +------+------+| | | Attested Node + +Attested Node|| | +-----------------+ +-------------+| +------------------------------------------------+ Figure 2: NASR Control plane function 2.3. Data Plane The east-west messages can be classified as data plane, mainly responsible for forwarding and processing tasks, and POT belongs to data plane. The attested node can be divided into forwarding function and security function. There are three cases for actual data forwarding. 1, Case1: only forwarding, for each node that a user's data passes through, an immutable label will be added to the data header, which can be represented by POT (FF); 2, Case2: only provide security services, for each security function node that a user's data passes through, an immutable label will be added to the data header, which can be represented by POT (SF); 3, Mixture of the first and second cases, which is the actual situation of the current network. The data passes through both the forwarding function node and the security service function node. If it is on the same physical device, it is represented by POT (FF, SF). If it is a separate device, it is identified according to the case1 and case2. Chen & Su Expires 16 December 2024 [Page 5] Internet-Draft archi-nasr June 2024 +------------+ +------------+ +------------+ | Forwarding | POT(FF1) | Forwarding | POT(FF2) | Forwarding | ===>| Function1 +-----------+ Function2 +------------+ Function3 |==> +------------+ +------\-----+ +--/---------+ \\ // \\ // \\ POT(FF2) // POT(SF2) \\ // \\ // +-----------+ +-\--------/| +-----------+ | Security | POT(SF1) | Security | POT(SF2) | Security | ===>| Function1 +------------+ Function2 +--------------+ Function3 |==> +-----------+ +-----------+ +-----------+ Figure 3: NASR Data Plane Function 3. Orchestration Controller The orchestration controller includes two major functions, one is orchestrater and the other is the controller. The core function of the orchestrator is to obtain input information and generate corresponding strategies (AI can be considered based on actual situations); The function of the controller is to follow the strategy of the orchestrator and distribute the strategy to the actual nodes. | | | | User's User's Network Security Requirements Requirments | | v v +------------------+ +------------------+ Devices' | | Path and Security| | -----------> | Orchestrater +----------------> | Controller | Status | | Policy | | +------------------+ +--------+---------+ ^ ^ | | | Policy Networks' Security Distribution Conditon Incidents | | | | | | v Figure 4: Orchestration controller functions Chen & Su Expires 16 December 2024 [Page 6] Internet-Draft archi-nasr June 2024 Path orchestration relies on five types of information collected: 1. The status of the device, such as its availability, health status; 2. The state of the network, such as the level of congestion of the network; 3. Security incidents, such as recent security incidents; 4. User network requirements, such as latency, bandwidth, and budget requirements; 5. The security needs of users, such as the security level. 4. Validator Path and service verification have two modes, one final node validation mode and the other is intermediate node validation mode. 4.1. Final node validation mode After passing through all nodes, the user's traffic data is fed back to the validator with the POT tag made at the last node. After the validator completes the verification, a report is generated and provided to the customer. Customers can obtain actual traffic data from the report to determine whether it has been forwarded along the planned path and whether the network has provided users with predetermined security services. +-----------+ +------+ | Validator +---------------->| | +-----------+ Report | | ^ | | | | | |POT(FF)s |User | |POT(SF)s | | |POT(FF,SF)s | | +----------+ +----------+ +----+-----+ | | | Attested | | Attested | | Attested | traffic | | | Node +------>| Node +---->| Node +---------------->| | +----------+ +----------+ +----------+ +------+ Figure 5: Final node validation mode 4.2. Intermediate node validation mode After passing through one or several nodes, the POT is verified. If the verification passes, it continues to be forwarded. If the verification fails, the result is fed back to the orchestration controller. The orchestration controller makes real-time adjustments and sends the strategy to the next node for path control. Chen & Su Expires 16 December 2024 [Page 7] Internet-Draft archi-nasr June 2024 +--------------------------------+ | Orchestration Controller | +-------------------------------++ ^ | | | | | | | +---------+-----------+ | +------+ | Validator |>>>>>>>>>>>>>>>>>>>| | +---------------------+ | Report | | ^ ^ | | | | | | | | |POT(FF) |POT(FF) | |User | |POT(SF) |POT(SF) v | | |POT(FF,SF) |POT(FF,SF) | | +----+-----+ +-+------------+ | | | Attested | | Attested | traffic | | | Node +------>| Node +---------->| | +----------+ +--------------+ +------+ Figure 6: Intermediate node validation mode 5. Trusted path procedures 5.1. Indirect Model Indirect Model: the controller Obtains security function information through the attester node, and then send the security informations to validator, after verifying the authenticity of the information, the controller can obtain attestation result. After forming routing policy according to users' requirements, secure path policies can be distributed to routing nodes, the whole process can be seen in Figure2. Chen & Su Expires 16 December 2024 [Page 8] Internet-Draft archi-nasr June 2024 +------------+ +----------+ +-----------+ +------------+ |SecFunction | | Attester | | Validator | | Controller | +-----+------+ +-----+----+ +-----+-----+ +------+-----+ | | | | | secure | | | boot | | | | | | +------------------> | | | aware security | | | | capabilities | | | | +--------------------------> | | | security capabilities | | | | & trustworthiness claim +----------------> | | |Attestation | | | | Result | | | | | | | | | <-------------------------------------------+ | | Secure path routing policy issurance | Figure 7: Indirect Model When the network node receives the routing policy, it enable the security functions, then all traffic forwarding will receive security services. During the data forwarding process or after the data forwarding is completed, security validation can be performed on the entire process, including verification of secure paths and verification of whether security services are provided, the final validation results will be given to the controller or present to users. +------------+ +----------+ +-----------+ +------------+ |SecFunction | | Attester | | Validator | | Controller | +-----+------+ +-----+----+ +-----+-----+ +------+-----+ | | | | <------------------+ | | |enable SecFunction| | | |----------------->| | | | ok traffic forwarding | | | | | | | +----------------------> | | |Secure path validation+--------------------+ | | | Validation Result | Figure 8: Path and security service validation Process Chen & Su Expires 16 December 2024 [Page 9] Internet-Draft archi-nasr June 2024 5.2. Direct Model Direct Model: If the security function has a public address, the security function proactively reports its own information to the validator, after verifying the authenticity of the information, the controller can obtain attestation result. After forming routing policy according to users' requirements, secure path policies can be distributed to secfunction, the whole process can be seen in Figure4. +-----------+ +----------+ +----------+ |SecFunction| |Validator | |Controller| +-----+-----+ +----+-----+ +----+-----+ | | | | | | +---------------------------->| | |security capability report | | | +--------+ +------------>| | |Attester| | attestation | | +---+----+ | result | | | | |<------------+<----------------------------+ | | secure path routing | | | policy issurance | | | | Figure 9: Direct Model In the direct model the network node and secfuntion both receive the routing policy, then all traffic forwarding will receive security services. During the data forwarding process or after the data forwarding is completed, security validation can be performed on the entire process, including verification of secure paths and verification of whether security services are provided, the final validation results will be given to the controller or present to users. Chen & Su Expires 16 December 2024 [Page 10] Internet-Draft archi-nasr June 2024 +-----------+ +--------+ +----------+ +----------+ |SecFunction| |Attester| |Validator | |Controller| +-----+-----+ +----+---+ +----+-----+ +----+-----+ | | | | | | | | | +-------------->| | | |path validation| | | | | | | | | +---------------------------->| | |security service validation +-------------> | |validation | | |result | Figure 10: Path and security service validation Process 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations TBD Authors' Addresses Meiling Chen China Mobile BeiJing China Email: chenmeiling@chinamobile.com Li Su China Mobile BeiJing China Email: suli@chinamobile.com Chen & Su Expires 16 December 2024 [Page 11]