A Path Verification Solution based on SRv6

Introduction 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 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 and 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) 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 and 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.

Terminology MAC: Message Authentication Code, a technology to confirm the integrity and conduct certification. SRH: Source Routing Head. SRv6: 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 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.

Problem Statement

Presupposition 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.

Threat Model 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.

Functional Goals 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.

Specification framework of SR-TPP SR-TPP mainly depends on the following three steps to ensure path compliance and privacy protection, shown in figure 1.

Initialization 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).

Verification and forwarding by intermediate routers 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.

Fault localization 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.

Process of SR-TPP. +----------+ +------------------------ |Controller|<-Path Assembly | <--Path +----------+ | | | | <-Fault Location +---+ +----------+ +--------+ +----------+ +---+ | S |-->...-->|Router i-1|-->|Router i|-->|Router i+1|-->...-->| D | +---+ +----------+ +--------+ +----------+ +---+ ^ ^ | | Initialization Verification ]]>

Initialization

Path Initialization 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.

Process of Path Initialization.

Package Initialization 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.

SRv6 header format. 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.

Verification

Process of Verification. | packet | +--------------------------------------+ +--------+ | Yes | v | +------------+ | |Update T-SID| | +------------+ | | | v | +--------------------------------------+ | | Replace the source and destination | | | of the packet and forward it | | +--------------------------------------+ | | | v | +-----+ | | End |<--------------------------+ +-----+ ]]>

Key generation 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.

Upstream verification 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.

Obtain downstream IP address 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.

Replace header 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.

Fault location 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.

Acknowledgements

IANA Considerations This memo includes no request to IANA.