]> China Mobile

BeiJing China chenmeiling@chinamobile.com

China Mobile

BeiJing China suli@chinamobile.com

Security Internet Engineering Task Force Internet-Draft keyword2 Some users need to choose nodes that meet security requirements to form secure paths and ensure that traffic can defend against dynamic attacks during path forwarding. In this architecture, there are four roles defined: attester, authorizer, controller and secfunction, the interaction of these four roles can achieve the selection of secure paths and security services. the purpose of this architecture is to secure the path, including node static security assessment, dynamic security defense, and path and service validation.

Introduction In the early days, users' demand for the network was accessibility, but now their demand for security is becoming increasingly evident, how to implement secure paths has become a new research direction. To meet users' needs for secure path, 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 evaluated; 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.Secure 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 secure path.

Secure path architecture There are four roles in the secure path architecture, Attester can report the security information to the contoller through the authorizer, the authorizer is responsible for verifing the authenticity of the information. The controller matches the user's requirements based on the obtained information to form a secure routing path strategy, how to match user requirements is out of scope. Then forward data for users along secure paths and provide secure service capabilities. Finally, the authorizer verifies whether the forwarding path is consistent with the issued routing policy and whether the security capability is truly provided.

Components

Attester 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 secure path attester produces evidence of secure boot and information of usable security capabilities to enable the controller to select secure nodes to form routing paths.

Controller The controller can obtain information from all nodes in the network, implement network programming to form forwarding path policies, and distribute the policies to the forwarding nodes.

Authorizer As an vital third party, before the formation of path strategy, the authorizer's responsibility is to verify the authenticity of the attester's claim; After path policy execution or during the execution of routing policies, authorizer verifies if the path is executed as scheduled and the security capability is truly provided.

Secfunction There are two functions for forming a secure path: one is to ensure the static security of the routing node by secure boot, and the other is to provide security capabilities to defend against dynamic attacks during the routing forwarding process. The secfunction 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.

Secure path Operations

Indirect Model Indirect Model: the controller Obtains security function information through the attester node, and then send the security informations to authorizer, 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 2: 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 3: 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 authorizer, 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 4: 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 5: Path and security service validation Process ]]>

IANA Considerations This memo includes no request to IANA.

Security Considerations TBD