| Internet-Draft | SRv6 Security Considerations | July 2023 |
| Li, et al. | Expires 25 January 2024 | [Page] |
SRv6 inherits potential security vulnerabilities from source routing in general, and also from IPv6. This document describes various threats and security concerns related to SRv6 networks and existing approaches to solve these threats.¶
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 25 January 2024.¶
Copyright (c) 2023 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.¶
Segment Routing (SR) [RFC8402] 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 [RFC8200] dataplane, called SRv6 [RFC8754], 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 [RFC8754]. 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 [RFC8754]).¶
SRv6 inherits potential security vulnerabilities from source routing in general and also from IPv6 [RFC9099]. There are also some new vulnerabilities faced by SRv6.¶
This document describes various threats to SRv6 networks and also presents existing approaches to avoid or mitigate the threats.¶
This document uses the terminology defined in [RFC5095] and [RFC8754].¶
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.¶
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:¶
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.¶
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:¶
The above threats are not specific to SRv6, existing IPv6 and IPv4 networks all need to cope with them.¶
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.¶
SPRING architecture [RFC8402] 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 [RFC8402].¶
Maintaining such a trust boundary will efficiently avoid most of the threats described in Section 2. 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.¶
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)
* *
***************************
Typically, in any trusted domain, ingress routers MUST be configured with ACL at (1) in Figure 1. 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 Figure 1 in order to allow the externally advertised Binding SIDs. The advertisement scope should be controlled to reduce security risks.¶
An SRv6 router MUST support an ACL at (2) in Figure 1 with the following behavior:¶
1. IF (DA == LocalSID) && (SA != internal address or SID space) : 2. drop¶
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.¶
As per the End definition [RFC8986], 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.¶
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 ([RFC8754] and [RFC8986]).¶
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 [RFC8754]. 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 ([RFC8956] and [I-D.ietf-idr-flowspec-srv6]), which will further simplifies SID control.¶
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.¶
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].¶
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.¶
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.¶
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.¶
This document attempts to give an overview of security considerations of operating an SRv6 network. The document itself does not import security issues.¶
This document has no IANA actions.¶
Manty thanks to Charles Perkins and Stefano Previdi's valuable comments.¶