Internet-Draft SRv6 Security Considerations July 2023
Li, et al. Expires 25 January 2024 [Page]
Workgroup:
Spring
Internet-Draft:
draft-li-spring-srv6-security-consideration-11
Published:
Intended Status:
Informational
Expires:
Authors:
C. Li
Huawei
N. Geng
Huawei
C. Xie
China Telecom
H. Tian
CAICT
T. Tong
China Unicom
Z. Li
Huawei
J. Mao
Huawei

Security Considerations for SRv6 Networks

Abstract

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.

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 25 January 2024.

Table of Contents

1. Introduction

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.

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. Security Implications in SRv6 Networks

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. Security Advice on SRv6 Networks

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.

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)
        *                         *
        ***************************
Figure 1: 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.

3.1.1. ACL-based Filtering for External Interfaces

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.

3.1.2. ACL-based Filtering for Internal Interfaces

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.

3.1.3. SID Instantiation

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.

3.1.4. 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 ([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.

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.

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

5. IANA Considerations

This document has no IANA actions.

6. Acknowledgements

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

7. References

7.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5095]
Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, , <https://www.rfc-editor.org/info/rfc5095>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[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, , <https://www.rfc-editor.org/info/rfc8754>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.

7.2. Informative References

[RFC4301]
Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, , <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302]
Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, , <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303]
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, , <https://www.rfc-editor.org/info/rfc4303>.
[RFC4942]
Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, , <https://www.rfc-editor.org/info/rfc4942>.
[RFC2104]
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, , <https://www.rfc-editor.org/info/rfc2104>.
[RFC4443]
Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, , <https://www.rfc-editor.org/info/rfc4443>.
[RFC3704]
Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, , <https://www.rfc-editor.org/info/rfc3704>.
[RFC8704]
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <https://www.rfc-editor.org/info/rfc8704>.
[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, , <https://www.rfc-editor.org/info/rfc8986>.
[RFC9099]
Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, , <https://www.rfc-editor.org/info/rfc9099>.
[RFC8956]
Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, , <https://www.rfc-editor.org/info/rfc8956>.
[I-D.yang-spring-sid-as-source-address]
Yang, F. and C. Lin, "SID as source address in SRv6", Work in Progress, Internet-Draft, draft-yang-spring-sid-as-source-address-02, , <https://datatracker.ietf.org/doc/html/draft-yang-spring-sid-as-source-address-02>.
[I-D.ietf-idr-flowspec-srv6]
Li, Z., Li, L., Chen, H., Loibl, C., Mishra, G. S., Fan, Y., Zhu, Y., Liu, L., and X. Liu, "BGP Flow Specification for SRv6", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-srv6-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-srv6-03>.
[I-D.li-rtgwg-enhanced-ti-lfa]
Li, C., Hu, Z., Zhu, Y., and S. Hegde, "Enhanced Topology Independent Loop-free Alternate Fast Re-route", Work in Progress, Internet-Draft, draft-li-rtgwg-enhanced-ti-lfa-08, , <https://datatracker.ietf.org/doc/html/draft-li-rtgwg-enhanced-ti-lfa-08>.
[manrs-antispoofing]
"MANRS Implementation Guide", , <https://www.manrs.org/netops/guide/antispoofing>.

Authors' Addresses

Cheng Li
Huawei
Beijing
China
Nan Geng
Huawei
Beijing
China
Chongfeng Xie
China Telecom
Beijing
China
Hui Tian
CAICT
Beijing
China
Tian Tong
China Unicom
Beijing
China
Zhenbin Li
Huawei
Beijing
China
Jianwei Mao
Huawei
Beijing
China