Security Considerations for SRv6 Networks

1.1. Terminology

This document uses the terminology defined in [RFC5095] and [RFC8754].¶

1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1. 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 [RFC5095]. 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 [RFC8754].¶
• 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 [RFC8754].¶
• 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. [RFC8754] 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 [RFC5095], [RFC8402], [RFC8754], and [RFC8986], and there are already some mechanisms to deal with these threats.¶

2.2. Vulnerabilities Inherited from IPv6

SRv6 inherits potential security vulnerabilities from IPv6. A detailed analysis of IPv6 security considerations can be found in [RFC9099].¶

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

2.3. 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 [I-D.yang-spring-sid-as-source-address].¶

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

3.1. Basic Traffic Filtering

The basic security for maintaining a trust domain is described in [RFC8986] and [RFC8754]. For easier understanding, a simple example is shown in Figure 1.¶

        ***************************              *****
        *             (3) h2      *              *   * SRv6 domain
        *               \ |       *              *****
 h1-----A-----B-----C-----D-------E-------F
      / *    (2)    (2)  (2)      * \
  (1,2) *                         *  (1,2)
        *                         *
        ***************************

• 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.¶

1. IF (DA == LocalSID) && (SA != internal address or SID space) :
2.    drop

3.2. HMAC TLV

HMAC [RFC2104] is the enhanced security mechanism for SRv6 as defined in [RFC8754]. 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 Figure 1), 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 [RFC8754], and AH header is processed after SRH as recommended in [RFC8200]. Therefore, AH cannot be directly applied to SRv6 packets for securing SRH, and HMAC TLV is needed.¶

3.3. Source Address Validation

The ingress filtering mechanisms as defined in BCP 84 ([RFC3704] and [RFC8704]) 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 [manrs-antispoofing].¶

3.4. 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 [RFC8402].¶

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

3.5. ICMPv6 Rate-Limiting

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

3.6. IPSec

IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) 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 [RFC8200], 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.¶

3.7. 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 [I-D.li-rtgwg-enhanced-ti-lfa].¶

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 Section 2.3). 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.¶