the architecture for secure routing
draft-chen-secure-path-architecture-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Meiling Chen , Li Su | ||
| Last updated | 2024-03-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-secure-path-architecture-01
Internet Engineering Task Force Chen, Ed.
Internet-Draft L. Su
Intended status: Informational China Mobile
Expires: 5 September 2024 4 March 2024
the architecture for secure routing
draft-chen-secure-path-architecture-01
Abstract
Some users need to choose nodes that meet security requirements to
form secure routing 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 routing and security
services. The purpose of this architecture is to secure the routing,
including node static security assessment, dynamic security defense,
and routing 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 5 September 2024.
Copyright Notice
Copyright (c) 2024 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
Chen & Su Expires 5 September 2024 [Page 1]
Internet-Draft archi-SR March 2024
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. Secure routing architecture . . . . . . . . . . . . . . . . . 3
2.1. Components . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Attester . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Controller . . . . . . . . . . . . . . . . . . . . . 3
2.1.3. Authorizer . . . . . . . . . . . . . . . . . . . . . 4
2.1.4. Secfunction . . . . . . . . . . . . . . . . . . . . . 4
2.2. Secure path Operations . . . . . . . . . . . . . . . . . 4
2.2.1. Indirect Model . . . . . . . . . . . . . . . . . . . 5
2.2.2. Direct Model . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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. For security requirements are
becoming increasingly evident, this includes both user privacy and
security requirements as well as business security requirements.
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
routing.
Chen & Su Expires 5 September 2024 [Page 2]
Internet-Draft archi-SR March 2024
2. Secure routing 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 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
2.1. Components
2.1.1. 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.
2.1.2. Controller
The controller actually contains two functions, one is orchestration
and the other is control. 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.
Chen & Su Expires 5 September 2024 [Page 3]
Internet-Draft archi-SR March 2024
| |
| |
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 X: The function of Orchestration controller
2.1.3. 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.
2.1.4. 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.
2.2. Secure path Operations
Chen & Su Expires 5 September 2024 [Page 4]
Internet-Draft archi-SR March 2024
2.2.1. 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.
+------------+ +----------+ +-----------+ +------------+
|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.
Chen & Su Expires 5 September 2024 [Page 5]
Internet-Draft archi-SR March 2024
+------------+ +----------+ +-----------+ +------------+
|SecFunction | | Attester | | Authorizer| | Controller |
+-----+------+ +-----+----+ +-----+-----+ +------+-----+
| | | |
<------------------+ | |
|enable SecFunction| | |
|----------------->| | |
| ok traffic forwarding | |
| | | |
| +----------------------> |
| |Secure path validation+--------------------+
| | | Validation Result |
Figure 3: Path and security service validation Process
2.2.2. 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.
+-----------+ +----------+ +----------+
|SecFunction| |Authorizer| |Controller|
+-----+-----+ +----+-----+ +----+-----+
| | |
| | |
+---------------------------->| |
|security capability report | |
| +--------+ +------------>|
| |Attester| | attestation |
| +---+----+ | result |
| | |
|<------------+<----------------------------+
| | secure path routing |
| | policy issurance |
| | |
Figure 4: Direct Model
Chen & Su Expires 5 September 2024 [Page 6]
Internet-Draft archi-SR March 2024
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
3. IANA Considerations
This memo includes no request to IANA.
4. Security Considerations
TBD
Authors' Addresses
Meiling Chen (editor)
China Mobile
BeiJing
China
Email: chenmeiling@chinamobile.com
Li Su
China Mobile
BeiJing
China
Email: suli@chinamobile.com
Chen & Su Expires 5 September 2024 [Page 7]