A Path Verification Solution based on SRv6
draft-jliu-tpp-srv6-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jun Liu , Hewu Li , Tianyu Zhang , Qian Wu , Zongpeng Du | ||
| Last updated | 2024-02-28 | ||
| 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-jliu-tpp-srv6-00
SPRING Working Group J. Liu
Internet-Draft H. Li
Intended status: Informational T. Zhang
Expires: 31 August 2024 Q. Wu
Tsinghua University
Z. Du
China Mobile
28 February 2024
A Path Verification Solution based on SRv6
draft-jliu-tpp-srv6-00
Abstract
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.
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 31 August 2024.
Liu, et al. Expires 31 August 2024 [Page 1]
Internet-Draft A Path Verification Solution based on SR February 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Presupposition . . . . . . . . . . . . . . . . . . . . . 5
3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Functional Goals . . . . . . . . . . . . . . . . . . . . 6
4. Specification framework of SR-TPP . . . . . . . . . . . . . . 6
4.1. Initialization . . . . . . . . . . . . . . . . . . . . . 6
4.2. Verification and forwarding by intermediate routers . . . 6
4.3. Fault localization . . . . . . . . . . . . . . . . . . . 7
5. Initialization . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Path Initialization . . . . . . . . . . . . . . . . . . . 7
5.2. Package Initialization . . . . . . . . . . . . . . . . . 8
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Key generation . . . . . . . . . . . . . . . . . . . . . 11
6.2. Upstream verification . . . . . . . . . . . . . . . . . . 11
6.3. Obtain downstream IP address . . . . . . . . . . . . . . 11
6.4. Replace header . . . . . . . . . . . . . . . . . . . . . 11
7. Fault location . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Liu, et al. Expires 31 August 2024 [Page 2]
Internet-Draft A Path Verification Solution based on SR February 2024
1. 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 [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
Liu, et al. Expires 31 August 2024 [Page 3]
Internet-Draft A Path Verification Solution based on SR February 2024
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.
2. Terminology
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.
Liu, et al. Expires 31 August 2024 [Page 4]
Internet-Draft A Path Verification Solution based on SR February 2024
3. Problem Statement
3.1. 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.
3.2. 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.
Liu, et al. Expires 31 August 2024 [Page 5]
Internet-Draft A Path Verification Solution based on SR February 2024
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.
3.3. 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.
4. 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.
4.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).
4.2. 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
Liu, et al. Expires 31 August 2024 [Page 6]
Internet-Draft A Path Verification Solution based on SR February 2024
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.
4.3. 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.
Path Request--> +----------+
+------------------------ |Controller|<-Path Assembly
| <--Path +----------+
| |
| | <-Fault Location
+---+ +----------+ +--------+ +----------+ +---+
| S |-->...-->|Router i-1|-->|Router i|-->|Router i+1|-->...-->| D |
+---+ +----------+ +--------+ +----------+ +---+
^ ^
| |
Initialization Verification
Figure 1: Process of SR-TPP.
5. Initialization
5.1. 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.
Liu, et al. Expires 31 August 2024 [Page 7]
Internet-Draft A Path Verification Solution based on SR February 2024
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 |
+-----+
Figure 2: Process of Path Initialization.
5.2. 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
Liu, et al. Expires 31 August 2024 [Page 8]
Internet-Draft A Path Verification Solution based on SR February 2024
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] |/
+----------------------------------------------------------+
Figure 3: 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.
6. Verification
Liu, et al. Expires 31 August 2024 [Page 9]
Internet-Draft A Path Verification Solution based on SR February 2024
+-------+
| 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 |<--------------------------+
+-----+
Figure 4: Process of Verification.
Liu, et al. Expires 31 August 2024 [Page 10]
Internet-Draft A Path Verification Solution based on SR February 2024
6.1. 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.
6.2. 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.
6.3. 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.
6.4. 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.
Liu, et al. Expires 31 August 2024 [Page 11]
Internet-Draft A Path Verification Solution based on SR February 2024
7. 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.
8. Acknowledgements
9. IANA Considerations
This memo includes no request to IANA.
10. References
10.1. Normative References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
10.2. Informative References
[ICING] Naous, J., "Verifying and enforcing network paths with
ICING", 2011.
Liu, et al. Expires 31 August 2024 [Page 12]
Internet-Draft A Path Verification Solution based on SR February 2024
[OPT] Kim, T H J., "Lightweight source authentication and path
validation", 2014.
[PPV] Wu, B., "Enabling efficient source and path verification
via probabilistic packet marking", 2018.
[RFL] Wu, B., "Robust and lightweight fault localization", 2017.
[Route-hijacking]
"The new threat: Targeted internet traffic misdirection.",
2013,
<https://www.renesys.com/2013/11/mitminternet-hijacking/>.
Authors' Addresses
Jun Liu
Tsinghua University
Beijing 100084
China
Email: juneliu@tsinghua.edu.cn
Hewu Li
Tsinghua University
Beijing 100084
China
Email: lihewu@cernet.edu.cn
Tianyu Zhang
Tsinghua University
Beijing 100084
China
Email: ty-zhang20@tsinghua.org.cn
Qian Wu
Tsinghua University
Beijing 100084
China
Email: wuqian@cernet.edu.cn
Zongpeng Du
China Mobile
Beijing 100053
China
Email: duzongpeng@chinamobile.com
Liu, et al. Expires 31 August 2024 [Page 13]