the architecture of network attestation for secure routing

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 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.

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.

Components

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 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.

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.

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.

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.

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. | Function1 +-----------+ Function2 +------------+ Function3 |==> +------------+ +------\-----+ +--/---------+ \\ // \\ // \\ POT(FF2) // POT(SF2) \\ // \\ // +-----------+ +-\--------/| +-----------+ | Security | POT(SF1) | Security | POT(SF2) | Security | ===>| Function1 +------------+ Function2 +--------------+ Function3 |==> +-----------+ +-----------+ +-----------+ Figure 3: NASR Data Plane Function ]]>

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. | Orchestrater +----------------> | Controller | Status | | Policy | | +------------------+ +--------+---------+ ^ ^ | | | Policy Networks' Security Distribution Conditon Incidents | | | | | | v Figure 4: Orchestration controller functions ]]> 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.

Validator Path and service verification have two modes, one final node validation mode and the other is intermediate node validation mode.

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. | | +-----------+ 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 ]]>

Trusted path procedures

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. | | | 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. | | | | ok traffic forwarding | | | | | | | +----------------------> | | |Secure path validation+--------------------+ | | | Validation Result | Figure 8: Path and security service validation Process ]]>

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. | | |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. | | | |path validation| | | | | | | | | +---------------------------->| | |security service validation +-------------> | |validation | | |result | Figure 10: Path and security service validation Process ]]>

IANA Considerations This memo includes no request to IANA.

Security Considerations TBD