Security Considerations for SRv6 Networks

Introduction Segment Routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the source node by inserting an ordered list of instructions, called segments. A segment can represent a topological or service-based instruction. When segment routing is deployed on IPv6 dataplane, called SRv6 , a segment is a 128-bit value, and can the IPv6 address of a local interface but it does not have to. For supporting SR, a new type of Routing Extension Header is defined and called the Segment Routing Header (SRH). The SRH contains a list of SIDs and other information such as Segments Left. The SRH is defined in . By using the SRH, an ingress router can steer SRv6 packets into an explicit forwarding path so that many use cases like Traffic Engineering, Service Function Chaining can be deployed easily by SRv6. Note that, in some cases, a SRv6 packet may contain no SRH (see Section 3.1 in ). SRv6 inherits potential security vulnerabilities from source routing in general and also from IPv6 . There are also some new vulnerabilities faced by SRv6.

SRv6 makes use of the SRH which is a new type of Routing Extension Header. Therefore, the security properties of the Routing Extension Header are addressed by the SRH. See and for details.
SRv6 consists of using the SRH on the IPv6 dataplane which security properties can be understood based on previous work , , and .

This document describes various threats to SRv6 networks and also presents existing approaches to avoid or mitigate the threats.

Terminology This document uses the terminology defined in and .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Security Implications in SRv6 Networks

Vulnerabilities of SIDs/SRH SRv6 has similar vulnerabilities to source routing. The SIDs or SRH without protection or exposed to the external may be leveraged to launch attacks. The attackers can intercept/modify/falsify/abuse SIDs or SRH, which results in the following threats:

DoS/DDoS attacks. The attacks can be launched by constructing segment lists to make packets be forwarded repeatedly between two or more routers or hosts on specific links . The generation of ICMPv6 error messages may also be used in order to attempt DoS/DDoS attacks by sending an error-causing destination address or SRH in back-to-back packets .
Escaping security check such as access control or firewall. A segment list can be tailored to specify a particular path so that the malicious packets can bypass the firewall devices or reach otherwise-unreachable Internet systems .
Traffic interception. Unprotected SIDs can be used to intercept traffic. This threat can also be used for man-in-the-middle attacks.
Topology discovery. SRH may leak network information such as topology, traffic flows, and service usage. points out that the disclosure is less relevant to SR because an attacker has other means of learning topology, flows, and service usage.
Identity Spoofing. An attacker spoofs other hosts' identity to use an authorized service.

The above threats have been documented in previous work including , , , and , and there are already some mechanisms to deal with these threats.

Vulnerabilities Inherited from IPv6 SRv6 inherits potential security vulnerabilities from IPv6. A detailed analysis of IPv6 security considerations can be found in . Some common threats will also exist in SRv6 networks such as:

Eavesdropping of service data
Packet Falsification
Identity Spoofing
Packet Replay
DoS/DDoS

The above threats are not specific to SRv6, existing IPv6 and IPv4 networks all need to cope with them.

Implications on Security Devices Firewall devices need to take care of SRv6 packets. Particularly, the stateful firewall needs to record the packet information (e.g., source and destination addresses) of the traffic from inside to outside. When receiving the returned flow, the stateful firewall checks whether such a flow exists in the record table. If not, the flow will be rejected. However, the source address of SRv6 packets can be any of the source node's address like a loopback address (depending on configuration). As a result, the address information of SR packets may be asymmetric (i.e., the source address of the forward packet is not the destination address of the returned packet), which leads to failed validation. The related problem has been analyzed and solved in . Another problem is that the destination address of a SRv6 packet is changing during forwarding because SRv6 hides the real destination address into the segment list. Boundary security devices may not learn the real destination address and fail to take access control on some SRv6 traffic. Besides, the hidden destination address possibly also result in asymmetric address information mentioned above and thus negatively impacts the effectiveness of security devices.

Security Advice on SRv6 Networks SPRING architecture allows clear trust domain boundaries so that source-routing information is only usable within the trusted domain and never exposed to the outside world. It is expected that, by default, explicit routing is only used within the boundaries of the administered domain. Therefore, the data plane does not expose any source routing information when a packet leaves the trusted domain. Traffic is filtered at the domain boundaries . Maintaining such a trust boundary will efficiently avoid most of the threats described in . This section will present the detailed advice on trust domain operations. In most cases, the SR routers in the trust domain can be presumed to be operated by the same administrative entity without malicious intent and also according to specifications of the protocols that they use in the infrastructure. Hence, the SR-capable routers and transit IPv6 routers within the SRv6 trusted domains are trustworthy. The SRv6 packets are treated as normal IPv6 packets in transit nodes and the SRH will not bring new security problem. Of course, the above assumption is not always true in practice. Some normal security operations like those for IPv6 security are still recommended to be taken.

Basic Traffic Filtering The basic security for maintaining a trust domain is described in and . For easier understanding, a simple example is shown in .

SRv6 Security Policy Design

A-E: SRv6 Routers inside the SRv6 domain. A and E are the edge routers which can also be called ingress router instead.
F: Router F outside the SRv6 domain.
h1: A host outside the SRv6 domain connects to Router A.
h2: A host within the SRv6 domain, which connects to Router D.
(1): The filtering point at external interfaces.
(2): The filtering point at internal interfaces connecting to routers.
(3): The filtering point at internal interfaces connecting to internal hosts.

ACL-based Filtering for External Interfaces Typically, in any trusted domain, ingress routers MUST be configured with ACL at (1) in . Any packet externally received with SA/DA having a domain internal address will be filterred out. An SRv6 router typically comply with the same rule. A provider would generally do this for its internal address space in order to prevent access to internal addresses and in order to prevent spoofing. The technique is extended to the local SID space. It should be noted that, in some use cases, Binding SIDs can be leaked outside of SRv6 domain. Detailed ACL SHOULD be then configured at (1) in in order to allow the externally advertised Binding SIDs. The advertisement scope should be controlled to reduce security risks.

ACL-based Filtering for Internal Interfaces An SRv6 router MUST support an ACL at (2) in with the following behavior: This prevents access to locally instantiated SIDs from outside the operator's infrastructure. Such ACL configuration should work for most cases except some particular ones. For example, specific SIDs can be used to provide resources to devices that are outside of the operator's infrastructure.

SID Instantiation As per the End definition , an SRv6 router MUST only implement the End behavior on a local IPv6 address if that address has been explicitly enabled as an SRv6 SID. Thus, a local SID must be explicitly instantiated and explicitly bound to a behavior. The SRv6 packets received with destination address being a local address that has not been enabled as an SRv6 SID MUST be dropped.

Operational Considerations of Basic Traffic Filtering The internal device addresses such as SIDs and interface addresses are usually allocated from specific address blocks. That is, SIDs are from a SID block, and interface addresses belong to another address block. The internal device addresses are clearly distinct from IPv6 addresses allocated for end users, systems, and external networks ( and ). Therefore, conducting the above basic traffic filtering policies for maintaining the security of the SRv6 domain will not induce much operational overhead. Only a small number of ACLs need to be configured for matching seldom changing prefixes at specific interfaces . Different routers typically comply with the same ACL rules. In addition, particular upgrades on devices are not required for supporting the basic traffic filtering policies. There are also some tools for flexible SID filtering ( and ), which will further simplifies SID control.

HMAC TLV HMAC is the enhanced security mechanism for SRv6 as defined in . An operator of an SRv6 domain may delegate SRH addition to a host node within the SR domain. The SRv6 packets sent by the host can contain an HMAC TLV in SRH. The HMAC TLV can be used to ensure that 1) the SRH in a packet was applied by an authorized host, 2) the segments are authorized for use, and 3) the segment list is not modified after generation. HMAC processing can only happen at the ingress nodes (i.e., (3) in ), and other nodes inside the trusted domain could ignore the HMAC TLV. Note that, the SRH is mutable in computing the Integrity Check Value (ICV) of AH , and AH header is processed after SRH as recommended in . Therefore, AH cannot be directly applied to SRv6 packets for securing SRH, and HMAC TLV is needed.

Source Address Validation The ingress filtering mechanisms as defined in BCP 84 ( and ) are RECOMMENDED to be used for preventing source address spoofing. With packets carrying legitimate source addresses, many threats such as identity spoofing and source address spoofing-based DoS/DDoS can be avoided, and it will also benefit tracing back or locating malicious hosts or networks. Deploying source address validation is a common recommendation in the Internet .

Control Plane Security Operations SRv6 information like SIDs can be advertised through various control plane protocols. The security of control plane should be considered. Existing authentication, encryption, filtering, and other security mechanisms of control plane protocols can be taken to ensure the security of SRv6 information. Segment Routing does not define any additional security mechanisms in existing control plane protocols . From a perspective of trust domain, any information related to internal prefixes (like SIDs) and topology SHOULD NOT be exposed to the outside of the domain. Necessary filtering policies like route filtering need to be configured to prevent information leakage.

ICMPv6 Rate-Limiting The ICMPv6 rate-limiting mechanism as defined in can be used locally for preventing ICMPv6-based attacks (e.g., ICMPv6-based DoS/DDoS described in ). ICMPv6 rate-limiting is a popular security action in IPv6 networks.

IPSec IPSec (AH , ESP ) can be used for authentication, encryption, and integrity protection. To some extent, the attacks including eavesdropping, packet falsification, identity spoofing, and packet replay can be avoided or mitigated through IPSec. Note that, IPSec cannot effectively protect SRH. As recommended in , the processing order of SRH (also routing header) is higher than that of AH/ESP extension header. Besides, the SRH is mutable during forwarding process. Therefore, IPSec cannot be directly used to deal with source routing-related attacks.

Operations Related to Security Devices When computing segment lists for normal forwarding or path protection, make sure that the SRv6 path does not bypass the required security devices like firewall . In some cases, stateful security devices (e.g., stateful firewall) are difficult to learn the accurate traffic state due to asymmetric address or hidden destination address (see ). To cope with the issues, operators SHOULD intentionally configure symmetric addresses on routers, e.g., a source address in a outbound packet is set to the destination address in the inbound packet. Besides, the stateful security devices SHOULD be able to figure out the real destination address of SRv6 flow, so that the recorded state can accurately detect the returned flow.

Security Considerations This document attempts to give an overview of security considerations of operating an SRv6 network. The document itself does not import security issues.

IANA Considerations This document has no IANA actions.

Acknowledgements Manty thanks to Charles Perkins and Stefano Previdi's valuable comments.