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]