Spring C. Li
Internet-Draft Z. Li
Intended status: Standards Track Huawei
Expires: December 13, 2019 June 11, 2019
Security Considerations for SRv6 Networks
draft-li-spring-srv6-security-consideration-00
Abstract
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.
Li & Li Expires December 13, 2019 [Page 1]
Internet-Draft SR-security June 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Principles of SRv6 Networking . . . . . . . . . . . 3
4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4
4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4
4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5
4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 6
4.4. Repudiation in SRv6 Networks . . . . . . . . . . . . . . 6
4.5. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 6
4.6. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 7
4.7. Malicious Packet Data in SRv6 Networks . . . . . . . . . 7
5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 7
6. Security Policy Design . . . . . . . . . . . . . . . . . . . 7
6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 7
6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 7
6.1.2. ACL for Internal Interface . . . . . . . . . . . . . 8
6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 8
6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
Li & Li Expires December 13, 2019 [Page 2]
Internet-Draft SR-security June 2019
potential security vulnerabilities from source routing in general,
and also from IPv6.
o SRv6 is a descendent of IPv6 routing header, and its security
properties can be understood based on previous work [RFC5095].
o SRv6 is a descendent of IPv6, and its security properties can be
understood based on previous work [RFC4301], [RFC4302], [RFC4303]
and [RFC4942].
In this document, we will consider the dangers from the following
kinds of threats:
o Wiretapping/eavesdropping
o Packet Falsification
o Identity Spoofing
o Repudiation
o Packet Replay
o DDOS
o Malicious packet data
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
Li & Li Expires December 13, 2019 [Page 3]
Internet-Draft SR-security June 2019
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.
o Threats: Eavesdropping
o Solutions: ESP [RFC4303] can be used to prevent Eavesdropping.
The ESP header is inserted after the IP header and before the next
layer protocol header (transport mode) or before an encapsulated
IP header (tunnel mode). ESP can be used to provide
confidentiality, data origin authentication, connectionless
integrity, an anti-replay service (a form of partial sequence
integrity), and (limited) traffic flow confidentiality. The set
of services provided depends on options selected at the time of
Security Association (SA) establishment and on the location of the
implementation in a network topology.
o Conclusions: In tunnel mode of ESP, packets are encrypted and can
not be eavesdropped in a trusted SRv6 domain. In transport mode
of ESP, the payload of packets are encrypted and can not be
Li & Li Expires December 13, 2019 [Page 4]
Internet-Draft SR-security June 2019
eavesdropped in a trusted SRv6 domain, while the IPv6 header and
SRH is not encrypted.
o Gaps: The IPv6 header and SRH are not encrypted in transport mode
of ESP, since they are out of scope of ESP encryption, which may
be eavesdropped by attackers.
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].
o Threats: Packet Falsification
o Solutions: The packets from outside can not be trusted, so
Integrity Verification policy should be deployed at the external
interfaces by using IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] )
or HMAC [RFC2401]. AH, ESP and HMAC can provide Integrity
Verification for pakcets, while the ESP can encrypt the payload to
provide higher security. However, it has been noted that AH and
ESP are not directly applicable to reducing the vulnerabilities of
SRv6, due to the presence of mutalble fields in the SRH. To solve
this problem, [I-D.ietf-6man-segment-routing-header] defines the
mechanism to carry HMAC TLV in SRH to verify the integrity of
packets including the SRH fields. The HMAC TLV will be processed
based on Local policy, normally, only the ingress routers will
process the HMAC TLV. Within the SRv6 domain, the packets are
trusted, so HMAC TLV SHOULD be ignore. In another word, the SID
list are mutable within the SRv6 domain but can not be changed
before processing the HMAC TLV.
o Conclusions: There is no Packet Falsification within the SRv6
domain. Integrity Verification policy like HMAC processing should
be deployed at the external interfaces of the ingress SRv6 routers
for the packets from outside and the packets with SRH from hosts
within the SRv6 domain.
o Gaps: IPsec can not provide verification for SRH.
Li & Li Expires December 13, 2019 [Page 5]
Internet-Draft SR-security June 2019
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].
o Threats: Identity Spoofing
o Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC
[RFC2401] can be used for Authentication. AH, ESP and HMAC can
provide Authentication of source node, while the ESP can encrypt
the payload to provide higher security. Same as section 3.2.
o Conclusions: There is no Identity Spoofing within the SRv6 domain.
Identity Spoofing policy should be deployed at the external
interfaces of the ingress SRv6 routers for the packets from
outside and the packets with SRH from hosts within the SRv6
domain.
o Gaps: TBA
4.4. Repudiation in SRv6 Networks
TBA
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.
o Threats: Packet Replay
o Solutions: ESP [RFC4303] ) can be used to prevent Replay Attacks.
o Conclusions: There are no new Packet Replay threat brought by SRH.
ESP can be applied to SRv6 to prevent Packet replay attacks.
o Gaps: TBD
Li & Li Expires December 13, 2019 [Page 6]
Internet-Draft SR-security June 2019
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.
o Threats: DOS/DDOS
o Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443]
o Conclusions: There are no DOS/DDOS threats within SRv6 domain, the
threats come from outside of the domain, and can be prevented by
ICMPv6 rate-limiting mechanism.
o Gaps: TBD
4.7. Malicious Packet Data in SRv6 Networks
TBA
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.
TBA.
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.
Li & Li Expires December 13, 2019 [Page 7]
Internet-Draft SR-security June 2019
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
TBA
8. Acknowledgements
TBA
Li & Li Expires December 13, 2019 [Page 8]
Internet-Draft SR-security June 2019
9. References
9.1. Normative References
[]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-20 (work in progress), 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,
<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, December 2007,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
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", draft-ietf-spring-segment-routing-
policy-03 (work in progress), 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", draft-ietf-spring-srv6-network-
programming-00 (work in progress), April 2019.
Li & Li Expires December 13, 2019 [Page 9]
Internet-Draft SR-security June 2019
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, DOI 10.17487/RFC2401,
November 1998, <https://www.rfc-editor.org/info/rfc2401>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[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, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007,
<https://www.rfc-editor.org/info/rfc4942>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., 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, <https://www.rfc-editor.org/info/rfc7855>.
Authors' Addresses
Cheng Li
Huawei
China
Email: ChengLi13@huawei.com
Zhenbin Li
Huawei
China
Email: lizhenbin@huawei.com
Li & Li Expires December 13, 2019 [Page 10]