| Internet-Draft | BGP-LS2C | October 2023 |
| Chen & Su | Expires 25 April 2024 | [Page] |
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.¶
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 25 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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.¶
+-----------+
+---------+ Authorizer+---------+
| +-----------+ |
| |
+---+------+ +-----+------+
| Attester +------------------+ Controller |
+---+------+ +-----+------+
| |
| +------------+ |
+----------+SecFunction +-------+
+------------+
Figure 1: Basic secure path architecture
¶
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.¶
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.¶
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.¶
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.¶
+------------+ +----------+ +-----------+ +------------+
|SecFunction | | Attester | | Authorizer| | Controller |
+-----+------+ +-----+----+ +-----+-----+ +------+-----+
| | | |
| secure | |
| boot | |
| | | |
+------------------> | |
| 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.¶
+------------+ +----------+ +-----------+ +------------+
|SecFunction | | Attester | | Authorizer| | Controller |
+-----+------+ +-----+----+ +-----+-----+ +------+-----+
| | | |
<------------------+ | |
|enable SecFunction| | |
|----------------->| | |
| ok traffic forwarding | |
| | | |
| +----------------------> |
| |Secure path validation+--------------------+
| | | Validation Result |
Figure 3: Path and security service validation Process
¶
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.¶
+-----------+ +----------+ +----------+
|SecFunction| |Authorizer| |Controller|
+-----+-----+ +----+-----+ +----+-----+
| | |
| | |
+---------------------------->| |
|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.¶
+-----------+ +--------+ +----------+ +----------+
|SecFunction| |Attester| |Authorizer| |Controller|
+-----+-----+ +----+---+ +----+-----+ +----+-----+
| | | |
| | | |
| +-------------->| |
| |path validation| |
| | | |
| | |
+---------------------------->| |
|security service validation +------------->
| |validation |
| |result |
Figure 5: Path and security service validation Process
¶
This memo includes no request to IANA.¶