Spring C. Li
Internet-Draft Z. Li
Intended status: Standards Track Huawei
Expires: December 13, 2019 June 11, 2019

Security Considerations for SRv6 Networks


SRv6 inherits potential security vulnerabilities from Source Routing in general, and also from IPv6. This document describes various threats 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 December 13, 2019.

Copyright Notice

Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

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 [I-D.ietf-6man-segment-routing-header], a segment is a 128 bit value, and it can be an IPv6 address of a local interface but it does not have to. For supporting SR, an extended header called Segment Routing Header (SRH), which contains a list of SIDs and several needed information such as Segments Left, has been defined in [I-D.ietf-6man-segment-routing-header]. By using SRH, an Ingress router can steer SRv6 pakcets into an explicit forwarding path so that many use cases like Traffic engineering, Service Function Chaining can be deployed easily by SRv6.

However, SRv6 also bring some new security problems. This document describes various threats to networks employing SRv6. SRv6 inherits potential security vulnerabilities from source routing in general, and also from IPv6.

In this document, we will consider the dangers from the following kinds of threats:

The rest of this document will describe the above security threats in SRv6 networks and existing approaches to guarding against the threats.

2. Terminology

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 [RFC2119] and [RFC8174].

This document uses the terminology defined in [RFC5095] and [I-D.ietf-6man-segment-routing-header].

3. Security Principles of SRv6 Networking

As with other similar source-routing architecture, an attacker may manipulate the traffic path by modifying the packet header. SPRING architecture MUST provide clear trust domain boundaries so that source-routing information is only usable within the trusted domain and never exposed to the outside world [RFC7855]. It is expected that, by default, the explicit routing information is not leaked through the boundaries of the administered domain. Therefore, the data plane MUST NOT expose any source-routing information when a packet leaves the trusted domain.

By default, SR operates within a trusted domain. Traffic MUST be filtered at the domain boundaries [RFC8402].

Unless otherwise noted, the discussion in this document pertain to SR networks which can be characterized as "trusted domains" -- i.e., the SR routers in the domain are presumed to be operating without malicious intent and also to conform to specification for the protocols that they use.

This document assumes that the SR-capable routers and transit IPv6 routers within SRv6 trusted domains are trustworthy, since the SRv6 packets are treated as normal IPv6 packets in transit nodes, SRH will not bring new security problem. The security consideration of IPv6 networks is out of scope of this document.

4. Types of Vulnerabilities in SR Networks

In this section we will make a fuller explanation about the types of vulnerabilities as listed in Section 1. Then for each type we will explain whether or not the vulnerability exists in a trusted domain.

4.1. Eavesdropping Vulnerabilities in SRv6 Networks

As with practically all kinds of networks, traffic in an SRv6 network may be vulnerable to eavesdropping.

4.2. Packet Falsification in SRv6 Networks

As SRv6 domain is a trusted domain, there is no Packet Falsification within the SRv6 domain.

As the packets from outside of SRv6 domain can not be trusted, so Integrity Verification policy should be deployed at the external interfaces of the ingress SRv6 routers to verify the packets from outside of SRv6 domain [I-D.ietf-spring-srv6-network-programming]. Also, the packets with SRH sent form hosts within the SRv6 domain should be verified to prevent the falsification between the host and the ingress router. [I-D.ietf-spring-srv6-network-programming].

4.3. Identity Spoofing in SRv6 Networks

The same as Packet Falsification, there is no Identity Spoofing within the SRv6 domain since it is a trusted domain.

Authentication policy policy should be deployed at the external interfaces of the ingress SRv6 routers to validate the packets from outside of SRv6 domain [I-D.ietf-spring-srv6-network-programming]. Also, the packets with SRH sent form hosts within the SRv6 domain should be validated to prevent the Identity Spoofing [I-D.ietf-spring-srv6-network-programming].

4.4. Repudiation in SRv6 Networks


4.5. Packet Replay in SRv6 Networks

There are no new Packet Replay threat brought by SRH. ESP can be applied to SRv6 to prevent Packet replay attacks.

4.6. DOS/DDOS in SRv6 Networks

The generation of ICMPv6 error messages may be used to attempt DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) attacks by sending an error-causing destination address or SRH in back-to-back packets [I-D.ietf-6man-segment-routing-header]. An implementation that correctly follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-limiting mechanism.

4.7. Malicious Packet Data in SRv6 Networks


5. Effects of the above on SRv6 Use Cases

This section describeS the effects of the above-mentioned vulnerabilities in terms of applicability statement and the use cases given in citation.


6. Security Policy Design

The basic security for intra-domain deployment is described in [I-D.ietf-spring-srv6-network-programming] and the enhanced security machanism is defined in [I-D.ietf-6man-segment-routing-header].

In [I-D.ietf-spring-srv6-network-programming], it defines three basic security manchanisms.

6.1. Basic Security Design

6.1.1. ACL for External Interfaces

An SRv6 router MUST support an ACL on the external interface that drops any traffic with SA or DA in the internal SID space.

A provider would generally do this for its internal address space to prevent access to internal addresses and in order to prevent spoofing. The technique is extended to the local SID space.But in some use cases, Binding SID can be leaked to outside of SRv6 domain. Detailed ACL should be configured for Binding SID.

The typical counters of an ACL are expected.

6.1.2. ACL for Internal Interface

An SRv6 router MUST support an ACL 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. Note that this ACL may not be enabled in all cases. For example, specific SIDs can be used to provide resources to devices that are outside of the operator's infrastructure.

The typical counters of an ACL are expected.

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

Packets received with destination address representing a local interface that has not been enabled as an SRv6 SID MUST be dropped.

6.2. Enhanced Security Design

HMAC is the enhanced security machanism for SRv6 as defined in [I-D.ietf-6man-segment-routing-header]. HMAC is used for validating the packets with SRH sent from hosts within SRv6 domain.

7. Security Considerations


8. Acknowledgements


9. References

9.1. Normative References

[I-D.ietf-6man-segment-routing-header] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S. and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", Internet-Draft draft-ietf-6man-segment-routing-header-20, June 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5095] Abley, J., Savola, P. and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017.
[RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018.

9.2. Informative References

[I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b. and P. Mattes, "Segment Routing Policy Architecture", Internet-Draft draft-ietf-spring-segment-routing-policy-03, May 2019.
[I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-ietf-spring-srv6-network-programming-00, April 2019.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005.
[RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006.
[RFC4942] Davies, E., Krishnan, S. and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, September 2007.
[RFC7855] Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., Horneffer, M. and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016.

Authors' Addresses

Cheng Li Huawei China EMail: ChengLi13@huawei.com
Zhenbin Li Huawei China EMail: lizhenbin@huawei.com