| Internet-Draft | A Path Verification Solution based on SR | February 2024 |
| Liu, et al. | Expires 31 August 2024 | [Page] |
A trusted network path is desired for source authentication and path verification. The emergence of IPv6 Segment Routing (SRv6) may bring the opportunity to assemble trusted network paths with a lightweight IP header. This document describes a trusted network path verification mechanism based on SRv6 (Segment Routing to enable Trusted and Private Network Paths, SR-TPP), which supports network path verification with path information protection. SR-TPP extends SRv6 function in protocol header to meet the requirement of path compliance. Path information is sequentially encoded into the segment list in SR-TPP so that path information is partially visible to each intermediate router. The distributed verification of SR-TPP also makes it easier to locate faults.¶
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 31 August 2024.¶
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 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.¶
A trusted network path is a desired security property of the current Internet, especially for the security-critical network services. Enterprises and datacenters may require delivering packets on the pre-specified path. Most current networks can not prevent source spoofing, route hijacking [Route-hijacking] and route-based attacks for lacking of trusted network path. In order to address the problem, many researchers have proposed mechanisms to enforce path compliance, guarantee the correct delivery of packets along the purposed forwarding paths, avoiding cyberattacks such as DDoS, source address spoofing and path detour attacks. However, maintaining path compliance is not enough for the current Internet. For example, ICING [ICING] and OPT [OPT] only ensure that packets are dropped when verification fails, but they did not mention how to locate faults.¶
Privacy protection is another unavoidable topic when we design security mechanisms. Even if packets are delivered along a pre-specified path, and payloads of packets are protected by end-to-end encryption, such as TLS, there are still many risks of leaking privacy. In fact, eavesdropping and traffic analysis will not be detected by most security mechanisms, but risks they pose still cannot be ignored. More importantly, path verification mechanisms above are based on source routing, i.e. the source specifies the forwarding path in the packet header when it sends packets, which could be more likely to cause privacy leaks.¶
How to ensure that the integrity of the original path is not destroyed when the network flow is forwarded by untrusted nodes is an urgent problem that needs to be solved.¶
IPv6 Segment Routing IPv6 (SRv6) [RFC8986] is a protocol designed based on the source routing concept to forward IPv6 data packets on the network. SRv6 based on the IPv6 forwarding plane inserts a routing extension header SRH (Segment Routing Header) into the IPv6 packet, pushes an explicit IPv6 address stack into the SRH, and continuously updates the destination address and offset address through intermediate nodes. Stack operations are used to complete hop-by-hop forwarding. SRH is only recognized by network devices that support SRv6. For network devices that do not support SRv6, packets can also be forwarded normally.¶
In order to reduce the header overhead and introduce privacy protection in the path verification mechanism, This document describes a trusted network path verification mechanism based on SRv6(SR-TPP), a novel mechanism to support network path verification with path information protection. SR-TPP extends SRv6 uses a routing header to ensure source routing and path verification, only leverages lightweight operations to verify the pre-specified path. Specifically, the intermediate node only knows its previous and next hop, i.e. packets sent by the source cannot be linked to the destination, and the source is hidden from the second nodes of the path. SR-TPP provides distributed path verification and centralization-based fault localization, differ from the lightweight fault localization mechanisms (e.g. PPV [PPV] and RFL [RFL]) , only enable destination node to locate faults and cause waste of link resources.¶
Compared with previous methods, the SR-TPP uses the existing SRv6 protocol header to implement the path verification function and save header overhead. At the same time, the path and information at both ends are hidden, and the attacker cannot obtain user behavior and classify the traffic through traffic analysis at a certain node in the path, thus protecting the user's privacy. SR-TPP does not use expensive encryption algorithms, but only involves lightweight operations such as MAC and Hash, which will not bring a great burden to network implementation.¶
MAC: Message Authentication Code, a technology to confirm the integrity and conduct certification.¶
SRH: [RFC8754]Source Routing Head.¶
SRv6: [RFC8986]Segment Routing over IPv6.¶
DoS: Denial of Service.¶
Tag: Mark a packet as part of a class or group of packets. This field initialized with a timestamp value to represent a unique session.¶
Segments Left: Number of remaining routing segments, defined in [RFC8200] Section 4.4.¶
SID: Segment ID.¶
SL: Segments List,an ordered list of SID.¶
IR: Intermediate Router, routers participating in packet forwarding in the path.¶
a. There is a centralized controller that knows the IPv6 address and secret value of all routers. Each router stores its own secret value to generate session keys.¶
b. Each router knows IPv6 addresses of all its adjacency routers and the addresses of routers cannot be forged.¶
c. The initialization of the secret value of routers is trusted, and it is hard for attackers to guess the secret without any clues unless the router is compromised or misconfigured.¶
d. The end hosts (Source and Destination) are trusted, because it is meaningless for an attacker to attack its own flow.¶
e. The controller is trusted, it is maintained by the network administrator and well-protected.¶
It is assumed that an attacker can compromise intermediate routers or spoof the sender on a predetermined path so that it can change the delivery path or forge the source address to send the packet. In this document, hacked or misconfigured routers are called for damaged router. Possible attacks are summarized below:¶
1. Packet tampering and source spoofing. Attackers will forge the sender to send packets, or compromise the route. The server changes the headers of received packets, such as source and destination address and other header information.¶
2. Path deviation. Subject to a compromised router may also modify the packet's payload, then there are three attack methods: (1) Router hop pass. A compromised router redirects packets to skip some of its downstream routers. (2) Router addition. Packets are damaged along the way. The router is redirected to some router and then forwarded back. (3) Out-of-order forwarding. The forwarding sequence will be disrupted by modifying the routing header of the data packet or redirecting the data packet.¶
3. Denial of Service (DoS). An attacker or compromised router forges packets and then sends them to the router to exhaust its memory and computing resources.¶
4. Privacy leak. It is assumed that the attacker can observe the packet header and payload from part of the path. Although packet payloads can be protected through end-to-end encryption and authentication mechanisms such as TLS, many studies have shown that user privacy can be compromised through traffic analysis.¶
This mechanism is used to handle the predetermined forwarding path risks caused by untrusted intermediate routers, e.g. out-of-order delivery, privacy leakage, and packets alteration. The specific functional goals are as follows:¶
1. Source and path verification. Intermediate routers and destination nodes can verify whether the data packet follows the pre-specified path. The path goes through the upstream router and the packet payload can be checked to see if it has been changed.¶
2. Privacy protection. We assume that an adversary cannot observe packets from the entire path. A sender can hide its pre-specified path from malicious observers along part of the path.¶
3. Fault localization. When the intermediate router or the destination fails to verify packets, the controller should be able to locate the faults.¶
SR-TPP mainly depends on the following three steps to ensure path compliance and privacy protection, shown in figure 1.¶
Once the host sends a request to the controller for the trusted path, the controller assembles a path and transmit it to source and destination through a secure channel. Source host creates an SRH with the path and packet payload, and inserts it in Layer 3 (IPv6 header).¶
Upon receiving a packet, each intermediate router generates the session key using hash operation, and the input is the router’s local secret and the timestamp in the SRH. The generation of session key is stateless, it does not require additional storage space on the router. Router then parses the T-SID to obtain the IPv6 address of its downstream router. The router performs MAC operations on T-SID and updates the segment list of SRH to prove that the node has successfully verified and forwarded the data packet. Finally, Router replaces the source and destination filed of IPv6 Header with itself IPv6 address and its downstream router’s IPv6 address and forwards it.¶
If there are any faults during the verification phase (e.g., Router cannot parse T-SID and get next hop IP address correctly, which may be caused by the wrong MAC, wrong upstream router IP address or wrong Timestamp), Router will send a fault message to the controller through a secure channel to trigger the fault localization. The controller locates the misbehaving router by analyzing the error packet. In SRv6, the order of the elements in the segment list is the reverse of the routing order. In this document, we make the order of the elements in the segment list the same as the routing order for convenience. And the original segment ID (SID) in the segment list of SRH includes the 128 bits IPv6 address of the intermediate router, but in SR-TPP, SID is a value computed through a series of operations to ensure path compliance and route unlinkability. To avoid ambiguity, this document defines this particular SID as T-SID.¶
Path Request--> +----------+
+------------------------ |Controller|<-Path Assembly
| <--Path +----------+
| |
| | <-Fault Location
+---+ +----------+ +--------+ +----------+ +---+
| S |-->...-->|Router i-1|-->|Router i|-->|Router i+1|-->...-->| D |
+---+ +----------+ +--------+ +----------+ +---+
^ ^
| |
Initialization Verification
After the controller establishes the path, it uses the local key of each SR router and the path creation time to generate the session key using hash function with session initiation timestamp.¶
The controller then notifies the sender of the session key (changing with different timestamps) and IP address of the entire path, shown in figure 2.¶
+-------+
| Start |
+-------+
|
v
+--------------------------+
| Select nodes in the path |
+--------------------------+
|
v
+-------------------------------------+
| Generate session keys in order |<--+
+-------------------------------------+ |
| | No
v |
+-------------------------------------+ |
| Judge whether it is the last node? |---+
+-------------------------------------+
| Yes
v
+-------------------------------------+
| Send the session key and IP address |
| of the path to the source |
+-------------------------------------+
|
v
+-----+
| End |
+-----+
The main purpose of this step is to initialize SRH, shown in figure 3. The SRH format shown in figure 4 is only involves the Tag field and Segment List field in SRH, and the initialization of other fields is consistent with native SRv6. For each packet to be sent, the Tag field of the SRH is initialized to the time when the path was created. When generating the Segment List, the sender initially maintains an empty temporary list SL, and then begins to traverse each node in the path, sequentially generating its T-SID and writing it into the SRH's Segment List. It is also necessary to calculate MAC on T-SID and insert it into the temporary list SL for subsequent T-SID generation. After completing the initialization of SRH, the sender fills in the source address and destination address of the packet with his own IP address and the address of the first-hop SR router before sending the packet.¶
+----------------------------------------------------------+ | Next Header | Hdr Ext Len | Routing Type | Segments Left |\ +----------------------------------------------------------+ \ +-----------+ | Last Entry | Flags | Tag | \ |IPv6 Header| +----------------------------------------------------------+ \+-----------+ | Segment list[0] | | SRH | +----------------------------------------------------------+ /+-----------+ | ... | / | TCP Header| +----------------------------------------------------------+ / +-----------+ | Segment list[n] |/ +----------------------------------------------------------+
The source host creates an SRH with the path and packet payload, and inserts it in Layer 3 (IPv6 header).¶
Different from the traditional SRH initialization, Source initializes the Tag filed with the timestamp when the path is created. The Tag is used to distinguish sessions and prevent replay attacks. And the core to ensure path compliance is the initialization of segment list field, each element of segment list is a SID of an intermediate router. Each T-SID is generated with the previous-hop IPv6 address, next-hop IPv6 address.¶
+-------+
| Start |
+-------+
|
v
+----------------+
| Receive packet |
+----------------+
|
v
+--------------------------------------+ Yes
| Judge whether the path is expired？ |---------+
+--------------------------------------+ |
| No |
v |
+--------------------------------------+ |
| Generate session key | |
+--------------------------------------+ |
| |
v |
+--------------------------------------+ |
|Decode T-SID to obtain the nexthop IP | |
+--------------------------------------+ |
| |
v |
+--------------------------------------+ +--------+
| Judge whether the next | No | Drop |
| hop IP is legal? |--->| packet |
+--------------------------------------+ +--------+
| Yes |
v |
+------------+ |
|Update T-SID| |
+------------+ |
| |
v |
+--------------------------------------+ |
| Replace the source and destination | |
| of the packet and forward it | |
+--------------------------------------+ |
| |
v |
+-----+ |
| End |<--------------------------+
+-----+
On receiving a packet, if the timestamp from the packet header is valid, the Intermediate Router (IR) computes the session key using the IR’s local key and timestamp. The key generation is stateless, it does not require additional storage space on the router.¶
IR generates a MAC with the partial segment list from the packet Header and the payload. Note that if no error occurs, all elements of SL have been verified and updated by upstream router.¶
IR then parses the T-SID with the session key K to obtain the IPv6 address of its downstream router, and the IP is actually the source address in the packet header. There are two cases according to the location of the node performing the verification operation:¶
For the IR (segments left > 0), if the IPv6 address of its downstream router is valid belongs to the router adjacent to R and it is not equal to IP, IR updates the source address of IP header with its IP address and updates the destination address. Then IR applies a MAC operation using K to T-SID and updates it in the segment list of SRH. Finally, IR decrements the segments left and forwards the packet according to the new destination address. If the next IP is invalid, which means the header or payload of the packet is incorrect, there are malicious attacks or misconfiguration on the upstream node, IR will notify the controller to launch the fault localization.¶
For the destination D (segments left = 0), D removes the packet header and processes the payload. Then IR performs MAC operation on SL to prove it has processed this packet.¶
Finally, router replaces the source and destination filed of IPv6 Header with itself IPv6 address and its downstream router's IPv6 address and forwards it.¶
If there are any faults during the verification phase (e.g., IR) cannot parse T-SID and get next-hop IP address correctly, which may be caused by the wrong PktHash, wrong upstream router IP address or wrong Timestamp, IR will send a fault message to the controller through a secure channel to trigger the fault localization. The controller locates the misbehaving router by analyzing the error packet.¶
Malicious redirection by other routers. Though the malicious router R_m only knows its upstream router and downstream router of the path, it can still redirect packets (randomly) to other routers to disorder path or skip routers. But the incorrect path order will cause verification failure in the next router R_v. Another situation is that R_v and R_m are not in the same path defined in the packet header, and R_v will fail the verification.¶
This memo includes no request to IANA.¶