< draft-li-spring-srv6-security-consideration-00.txt   draft-li-spring-srv6-security-consideration-01.txt >
Spring C. Li Spring C. Li
Internet-Draft Z. Li Internet-Draft Z. Li
Intended status: Standards Track Huawei Intended status: Informational Huawei
Expires: December 13, 2019 June 11, 2019 Expires: January 9, 2020 July 8, 2019
Security Considerations for SRv6 Networks Security Considerations for SRv6 Networks
draft-li-spring-srv6-security-consideration-00 draft-li-spring-srv6-security-consideration-01
Abstract Abstract
SRv6 inherits potential security vulnerabilities from Source Routing SRv6 inherits potential security vulnerabilities from Source Routing
in general, and also from IPv6. This document describes various in general, and also from IPv6. This document describes various
threats to SRv6 networks and existing approaches to solve these threats and security concerns related to SRv6 networks and existing
threats. approaches to solve these threats.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 13, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Principles of SRv6 Networking . . . . . . . . . . . 3 3. Security Principles of SRv6 Networking . . . . . . . . . . . 3
4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4 4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4
4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4 4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4
4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5 4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5
4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 6 4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 6
4.4. Repudiation in SRv6 Networks . . . . . . . . . . . . . . 6 4.4. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 7
4.5. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 6 4.5. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 7
4.6. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 7 4.6. Malicious Packet Data in SRv6 Networks . . . . . . . . . 8
4.7. Malicious Packet Data in SRv6 Networks . . . . . . . . . 7 5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 8
5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 7 6. Security Policy Design . . . . . . . . . . . . . . . . . . . 8
6. Security Policy Design . . . . . . . . . . . . . . . . . . . 7 6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 9
6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 7 6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 9
6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 7 6.1.2. ACL for Internal Interfaces . . . . . . . . . . . . . 9
6.1.2. ACL for Internal Interface . . . . . . . . . . . . . 8 6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 9
6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 8 6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 9
6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Segment routing (SR) [RFC8402] is a source routing paradigm that Segment routing (SR) [RFC8402] is a source routing paradigm that
explicitly indicates the forwarding path for packets at the source explicitly indicates the forwarding path for packets at the source
node by inserting an ordered list of instructions, called segments. node by inserting an ordered list of instructions, called segments.
A segment can represent a topological or service-based instruction. A segment can represent a topological or service-based instruction.
When segment routing is deployed on IPv6 [RFC8200] dataplane, called When segment routing is deployed on IPv6 [RFC8200] dataplane, called
SRv6 [I-D.ietf-6man-segment-routing-header], a segment is a 128 bit 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 value, and can the IPv6 address of a local interface but it does not
not have to. For supporting SR, an extended header called Segment have to. For supporting SR, a new type of Routing Extension Header
Routing Header (SRH), which contains a list of SIDs and several is defined and called the Segment Routing Header (SRH). The SRH
needed information such as Segments Left, has been defined in contains a list of SIDs and other information such as Segments Left.
[I-D.ietf-6man-segment-routing-header]. By using SRH, an Ingress The SRH is defined in [I-D.ietf-6man-segment-routing-header]. By
router can steer SRv6 pakcets into an explicit forwarding path so using the SRH, an ingress router can steer SRv6 packets into an
that many use cases like Traffic engineering, Service Function explicit forwarding path so that many use cases like Traffic
Chaining can be deployed easily by SRv6. Engineering, Service Function Chaining can be deployed easily by
SRv6.
However, SRv6 also bring some new security problems. This document However, SRv6 also brings some new security concerns. This document
describes various threats to networks employing SRv6. SRv6 inherits describes various threats to networks deploying SRv6. SRv6 inherits
potential security vulnerabilities from source routing in general, potential security vulnerabilities from source routing in general,
and also from IPv6. and also from IPv6.
o SRv6 is a descendent of IPv6 routing header, and its security o SRv6 makes use of the SRH which is a new type of Routing Extension
properties can be understood based on previous work [RFC5095]. Header. Therefore, the security properties of the Routing
Extension Header are addressed by the SRH. See [RFC5095]and
[I-D.ietf-6man-segment-routing-header] for details.
o SRv6 is a descendent of IPv6, and its security properties can be o SRv6 consists of using the SRH on the IPv6 dataplane which
understood based on previous work [RFC4301], [RFC4302], [RFC4303] security properties can be understood based on previous work
and [RFC4942]. [RFC4301], [RFC4302], [RFC4303] and [RFC4942].
In this document, we will consider the dangers from the following In this document, we will consider the dangers from the following
kinds of threats: kinds of threats:
o Wiretapping/eavesdropping o Wiretapping/eavesdropping
o Packet Falsification o Packet Falsification
o Identity Spoofing o Identity Spoofing
o Repudiation
o Packet Replay o Packet Replay
o DDOS o DOS/DDOS
o Malicious packet data o Malicious Packet Data
The rest of this document will describe the above security threats in The rest of this document describes the above security threats in
SRv6 networks and existing approaches to guarding against the SRv6 networks and existing approaches to mitigate and avoid the
threats. threats.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] and [RFC8174]. [RFC2119] and [RFC8174].
This document uses the terminology defined in [RFC5095] and This document uses the terminology defined in [RFC5095] and
[I-D.ietf-6man-segment-routing-header]. [I-D.ietf-6man-segment-routing-header].
3. Security Principles of SRv6 Networking 3. Security Principles of SRv6 Networking
As with other similar source-routing architecture, an attacker may As with other similar source-routing architectures, an attacker may
manipulate the traffic path by modifying the packet header. SPRING manipulate the traffic path by modifying the packet header. SPRING
architecture MUST provide clear trust domain boundaries so that architecture [RFC8402] allows clear trust domain boundaries so that
source-routing information is only usable within the trusted domain source-routing information is only usable within the trusted domain
and never exposed to the outside world [RFC7855]. It is expected and never exposed to the outside world. It is expected that, by
that, by default, the explicit routing information is not leaked default, explicit routing is only used within the boundaries of the
through the boundaries of the administered domain. Therefore, the administered domain. Therefore, the data plane does not expose any
data plane MUST NOT expose any source-routing information when a source-routing information when a packet leaves the trusted domain.
packet leaves the trusted domain. Traffic is filtered at the domain boundaries [RFC8402].
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 Unless otherwise noted, the discussion in this document pertain to SR
networks which can be characterized as "trusted domains" -- i.e., the networks which can be characterized as "trusted domains", i.e., the
SR routers in the domain are presumed to be operating without SR routers in the domain are presumed to be operated by the same
malicious intent and also to conform to specification for the administrative entity without malicious intent and also according to
protocols that they use. specifications of the protocols that they use in the infrastructure.
This document assumes that the SR-capable routers and transit IPv6 This document assumes that the SR-capable routers and transit IPv6
routers within SRv6 trusted domains are trustworthy, since the SRv6 routers within the SRv6 trusted domains are trustworthy. Hence,the
packets are treated as normal IPv6 packets in transit nodes, SRH will SRv6 packets are treated as normal IPv6 packets in transit nodes and
not bring new security problem. The security consideration of IPv6 the SRH will not bring new security problem. The security
networks is out of scope of this document. considerations of IPv6 networks are out of scope of this document.
4. Types of Vulnerabilities in SR Networks 4. Types of Vulnerabilities in SR Networks
In this section we will make a fuller explanation about the types of This section outlines in details the different types of
vulnerabilities as listed in Section 1. Then for each type we will vulnerabilities listed in Section 1. Then, for each type, an attempt
explain whether or not the vulnerability exists in a trusted domain. to determine whether or not the vulnerability exists in a trusted
domain is made.
4.1. Eavesdropping Vulnerabilities in SRv6 Networks 4.1. Eavesdropping Vulnerabilities in SRv6 Networks
As with practically all kinds of networks, traffic in an SRv6 network As with practically all kinds of networks, traffic in an SRv6 network
may be vulnerable to eavesdropping. may be vulnerable to eavesdropping.
o Threats: Eavesdropping o Threats: Eavesdropping
o Solutions: ESP [RFC4303] can be used to prevent Eavesdropping. o Solutions: Encapsulating Security Payload (ESP, [RFC4303]) can be
The ESP header is inserted after the IP header and before the next used in order to prevent Eavesdropping. The ESP header is either
layer protocol header (transport mode) or before an encapsulated inserted between the IP header and the next layer(transport)
IP header (tunnel mode). ESP can be used to provide protocol header, or before an encapsulated IP header (tunnel
confidentiality, data origin authentication, connectionless mode). ESP can be used in order to provide confidentiality, data
integrity, an anti-replay service (a form of partial sequence origin authentication, connectionless integrity, an anti-replay
integrity), and (limited) traffic flow confidentiality. The set service (a form of partial sequence integrity), and (limited)
of services provided depends on options selected at the time of traffic flow confidentiality. The set of services provided
Security Association (SA) establishment and on the location of the depends on the selected options at the time of the Security
implementation in a network topology. Association (SA) establishment and on the location of the
implementation in a network topology.(add reference to the
different points explained in this paragraph).
o Conclusions: In tunnel mode of ESP, packets are encrypted and can o Conclusion: In tunnel mode of ESP, packets are encrypted and can
not be eavesdropped in a trusted SRv6 domain. In transport mode not be eavesdropped in a trusted SRv6 domain. In transport mode
of ESP, the payload of packets are encrypted and can not be of ESP, the payload of packets are encrypted and cannot be
eavesdropped in a trusted SRv6 domain, while the IPv6 header and eavesdropped in a trusted SRv6 domain, even if the IPv6 and SRH
SRH is not encrypted. headers are not encrypted.
o Gaps: The IPv6 header and SRH are not encrypted in transport mode o Gaps: The IPv6 and SRH headers are not encrypted in transport mode
of ESP, since they are out of scope of ESP encryption, which may of ESP which may be eavesdropped by attackers.
be eavesdropped by attackers.
+------------------------------------------------------------------+
|IPv6 Header| SRH | ESP| Payload |ESP Tail| ESP Auth data|
+------------------------------------------------------------------+
|----- Encryption Scope -----|
|------ Authentication Scope -----|
Figure 1: Transport Mode ESP for SRv6 packets
+----------------------------------------------------------------------+
|New IPv6 Header|SRH|ESP|IPv6 Header|SRH|Payload|ESP Tail|ESP Auth data|
+----------------------------------------------------------------------+
|------ Encryption Scope --------|
|------- Authentication Scope -------|
Figure 2: Tunnel Mode ESP for SRv6 packets
4.2. Packet Falsification in SRv6 Networks 4.2. Packet Falsification in SRv6 Networks
As SRv6 domain is a trusted domain, there is no Packet Falsification As SRv6 domain is a trusted domain, there is no Packet Falsification
within the SRv6 domain. within the SRv6 domain.
As the packets from outside of SRv6 domain can not be trusted, so As the packets from outside of SRv6 domain cannot be trusted, an
Integrity Verification policy should be deployed at the external Integrity Verification policy is typically deployed at the external
interfaces of the ingress SRv6 routers to verify the packets from interfaces of the ingress SRv6 routers in order to verify the
outside of SRv6 domain [I-D.ietf-spring-srv6-network-programming]. incoming packets (i.e., from outside of SRv6 domain
Also, the packets with SRH sent form hosts within the SRv6 domain [I-D.ietf-spring-srv6-network-programming]). Also, the packets with
should be verified to prevent the falsification between the host and SRH sent form hosts within the SRv6 domain should be verified in
the ingress router. [I-D.ietf-spring-srv6-network-programming]. order to prevent the falsification between the host and the ingress
router. [I-D.ietf-spring-srv6-network-programming].
o Threats: Packet Falsification o Threats: Packet Falsification
o Solutions: The packets from outside can not be trusted, so o Solutions: The packets from outside can not be trusted, so
Integrity Verification policy should be deployed at the external Integrity Verification policy should be deployed at the external
interfaces by using IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) interfaces by using , e.g., IPSec [RFC4301] (AH [RFC4302], ESP
or HMAC [RFC2401]. AH, ESP and HMAC can provide Integrity [RFC4303] ) or HMAC [RFC2401]. AH [RFC4302], ESP [RFC4303] and
Verification for pakcets, while the ESP can encrypt the payload to HMAC [RFC2401] can provide Integrity Verification for packets,
provide higher security. However, it has been noted that AH and while the ESP can encrypt the payload in order to provide higher
ESP are not directly applicable to reducing the vulnerabilities of security. However, it has been noted that the AH and ESP are not
SRv6, due to the presence of mutalble fields in the SRH. To solve directly applicable in order to reduce the vulnerabilities of SRv6
this problem, [I-D.ietf-6man-segment-routing-header] defines the due to the presence of mutable fields in the SRH. In order to
mechanism to carry HMAC TLV in SRH to verify the integrity of solve this problem, [I-D.ietf-6man-segment-routing-header] defines
packets including the SRH fields. The HMAC TLV will be processed a mechanism in order to carry HMAC TLV in the SRH so to verify the
based on Local policy, normally, only the ingress routers will integrity of packets including the SRH fields. The HMAC TLV is
process the HMAC TLV. Within the SRv6 domain, the packets are usually processed based on the local policy, only at the ingress
trusted, so HMAC TLV SHOULD be ignore. In another word, the SID router. Within the SRv6 domain, the packets are trusted, so HMAC
list are mutable within the SRv6 domain but can not be changed TLV is typically ignored. In other words, the segment list is
before processing the HMAC TLV. mutable within the SRv6 domain but cannot be changed before
processing the HMAC TLV.
o Conclusions: There is no Packet Falsification within the SRv6 o Conclusions: There is no Packet Falsification within a trusted
domain. Integrity Verification policy like HMAC processing should SRv6 domain. Integrity Verification policy like HMAC processing
be deployed at the external interfaces of the ingress SRv6 routers should be deployed at the external interfaces of the ingress SRv6
for the packets from outside and the packets with SRH from hosts routers filtering SRH packets from outside the trusted domain and
within the SRv6 domain. SRH packets from hosts within the SRv6 domain.
o Gaps: IPsec can not provide verification for SRH. o Gaps: IPsec cannot provide verification for SRH.
+-----------------------------------------------------------------+
|IPv6 Header | SRH | AH| Payload |
+-----------------------------------------------------------------+
|--Auth Scope--|HMAC |---------------Auth Scope-------------------|
Figure 3: Transport Mode AH and HMAC for SRv6 packets
+-----------------------------------------------------------------+
|New IPv6 Header|SRH | AH |IPv6 Header|SRH|Payload |
+-----------------------------------------------------------------+
|--Auth Scope---|HMAC|---------------Auth Scope-------------------|
Figure 4: Tunnel Mode AH and HMAC for SRv6 packets
4.3. Identity Spoofing in SRv6 Networks 4.3. Identity Spoofing in SRv6 Networks
The same as Packet Falsification, there is no Identity Spoofing The same as for Packet Falsification, there is no Identity Spoofing
within the SRv6 domain since it is a trusted domain. possible within the boundaries of a SRv6 trusted domain where all
nodes are under control of the same administrative organization.
Authentication policy policy should be deployed at the external Authentication policy should be deployed at the external interfaces
interfaces of the ingress SRv6 routers to validate the packets from of the ingress SRv6 routers in order to validate the packets from
outside of SRv6 domain [I-D.ietf-spring-srv6-network-programming]. outside of SRv6 domain [I-D.ietf-spring-srv6-network-programming].
Also, the packets with SRH sent form hosts within the SRv6 domain Also, the packets with SRH sent form hosts inside the SRv6 domain
should be validated to prevent the Identity Spoofing should be validated in order to prevent the Identity Spoofing
[I-D.ietf-spring-srv6-network-programming]. [I-D.ietf-spring-srv6-network-programming].
o Threats: Identity Spoofing o Threats: Identity Spoofing
o Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC o Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC
[RFC2401] can be used for Authentication. AH, ESP and HMAC can [RFC2401] can be used for Authentication. AH, ESP and HMAC can
provide Authentication of source node, while the ESP can encrypt provide Authentication of source node, while the ESP can encrypt
the payload to provide higher security. Same as section 3.2. the payload in order to provide higher security. Same as section
3.2.
o Conclusions: There is no Identity Spoofing within the SRv6 domain. o Conclusion: There is no Identity Spoofing within a trusted SRv6
Identity Spoofing policy should be deployed at the external domain. Identity Spoofing policy should be deployed on the
interfaces of the ingress SRv6 routers for the packets from external interfaces of the ingress SRv6 routers for the packets
outside and the packets with SRH from hosts within the SRv6 from outside and the packets with SRH from hosts within the SRv6
domain. domain.
o Gaps: TBA o Gaps: TBA
4.4. Repudiation in SRv6 Networks 4.4. Packet Replay in SRv6 Networks
TBA
4.5. Packet Replay in SRv6 Networks
There are no new Packet Replay threat brought by SRH. ESP can be There are no new Packet Replay threat brought by SRH. ESP can be
applied to SRv6 to prevent Packet replay attacks. applied to SRv6 in order to prevent Packet replay attacks.
o Threats: Packet Replay o Threats: Packet Replay
o Solutions: ESP [RFC4303] ) can be used to prevent Replay Attacks. o Solutions: ESP [RFC4303] ) can be used to prevent Replay Attacks.
o Conclusions: There are no new Packet Replay threat brought by SRH. o Conclusion: There are no new Packet Replay threat brought by SRH.
ESP can be applied to SRv6 to prevent Packet replay attacks. ESP can be applied to SRv6 in order to prevent Packet replay
attacks.
o Gaps: TBD o Gaps: TBD
4.6. DOS/DDOS in SRv6 Networks 4.5. DOS/DDOS in SRv6 Networks
The generation of ICMPv6 error messages may be used to attempt The generation of ICMPv6 error messages may be used in order to
DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) attacks by attempt DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service)
sending an error-causing destination address or SRH in back-to-back attacks by sending an error-causing destination address or SRH in
packets [I-D.ietf-6man-segment-routing-header]. An implementation back-to-back packets [I-D.ietf-6man-segment-routing-header]. An
that correctly follows Section 2.4 of [RFC4443] would be protected by implementation that correctly follows Section 2.4 of [RFC4443] would
the ICMPv6 rate-limiting mechanism. be protected by the ICMPv6 rate-limiting mechanism also in the case
of packets with an SRH.
o Threats: DOS/DDOS o Threats: DOS/DDOS
o Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443] o Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443]
o Conclusions: There are no DOS/DDOS threats within SRv6 domain, the o Conclusions: There are no DOS/DDOS threats within SRv6 domain, the
threats come from outside of the domain, and can be prevented by threats come from outside of the domain, and can be prevented by
ICMPv6 rate-limiting mechanism. ICMPv6 rate-limiting mechanism.
o Gaps: TBD o Gaps: TBD
4.7. Malicious Packet Data in SRv6 Networks 4.6. Malicious Packet Data in SRv6 Networks
TBA TBA
5. Effects of the above on SRv6 Use Cases 5. Effects of the above on SRv6 Use Cases
This section describeS the effects of the above-mentioned This section describes the effects of the above-mentioned
vulnerabilities in terms of applicability statement and the use cases vulnerabilities in terms of applicability statement and the use cases
given in citation. given in citation.
TBA. TBA.
6. Security Policy Design 6. Security Policy Design
The basic security for intra-domain deployment is described in The basic security for intra-domain deployment is described in
[I-D.ietf-spring-srv6-network-programming] and the enhanced security [I-D.ietf-spring-srv6-network-programming] and the enhanced security
machanism is defined in [I-D.ietf-6man-segment-routing-header]. mechanism is defined in [I-D.ietf-6man-segment-routing-header].
In [I-D.ietf-spring-srv6-network-programming], it defines three basic In [I-D.ietf-spring-srv6-network-programming], additional basic
security manchanisms. security mechanisms are defined. For easier understanding, a easy
example is shown in Figure 5.
*************************** *****
* (3) h2 * * * SRv6 domain
* \ | * *****
h1-----A-----B-----C-----D-------E-------F
/ * (2) (2) (2) * \
(1,2,3) * * (1,2)
* *
***************************
Figure 5: SRv6 Security Policy Design
o A-E: SRv6 Routers inside the SRv6 domain, A and E are the edge
router, can be called Ingress router instead.
o F: Router F outside the SRv6 domain.
o h1: A host outside the SRv6 domain connects to router Router A.
o h2: A host within SRv6 domain, which connects to the Router D.
o (1): Security policy 1: ACL for External Interface.
o (2): Security policy 2: ACL for Internal Interfaces.
o (3): Security policy 3: Policy for processing HMAC, should be
deployed at the ingress nodes.
6.1. Basic Security Design 6.1. Basic Security Design
6.1.1. ACL for External Interfaces 6.1.1. ACL for External Interfaces
An SRv6 router MUST support an ACL on the external interface that Typically, in any trusted domain, ingress routers are configured with
drops any traffic with SA or DA in the internal SID space. Access Control Lists (ACL) filtering out any packet externally
received with SA/DA having a domain internal address. An SRv6 router
A provider would generally do this for its internal address space to typically comply with the same rule.
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. 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.
However, in some use cases, Binding SID can be leaked outside of SRv6
domain. Detailed ACL should be then configured in order to consider
the externally advertised Binding SID.
6.1.2. ACL for Internal Interface 6.1.2. ACL for Internal Interfaces
An SRv6 router MUST support an ACL with the following behavior: An SRv6 router MUST support an ACL with the following behavior:
1. IF (DA == LocalSID) && (SA != internal address or SID space) : 1. IF (DA == LocalSID) && (SA != internal address or SID space) :
2. drop 2. drop
This prevents access to locally instantiated SIDs from outside the This prevents access to locally instantiated SIDs from outside the
operator's infrastructure. Note that this ACL may not be enabled in operator's infrastructure. Note that this ACL may not be enabled in
all cases. For example, specific SIDs can be used to provide all cases. For example, specific SIDs can be used to provide
resources to devices that are outside of the operator's resources to devices that are outside of the operator's
infrastructure. infrastructure.
The typical counters of an ACL are expected.
6.1.3. SID Instantiation 6.1.3. SID Instantiation
As per the End definition, an SRv6 router MUST only implement the End As per the End definition [I-D.ietf-spring-srv6-network-programming],
behavior on a local IPv6 address if that address has been explicitly an SRv6 router MUST only implement the End behavior on a local IPv6
enabled as an SRv6 SID. address if that address has been explicitly enabled as an SRv6 SID.
Packets received with destination address representing a local Packets received with destination address representing a local
interface that has not been enabled as an SRv6 SID MUST be dropped. interface that has not been enabled as an SRv6 SID MUST be dropped.
6.2. Enhanced Security Design 6.2. Enhanced Security Design
HMAC is the enhanced security machanism for SRv6 as defined in HMAC [RFC2401] is the enhanced security mechanism for SRv6 as defined
[I-D.ietf-6man-segment-routing-header]. HMAC is used for validating in [I-D.ietf-6man-segment-routing-header]. HMAC is used for
the packets with SRH sent from hosts within SRv6 domain. validating the packets with SRH sent from hosts within SRv6 domain.
Since the SRH is mutable in computing the Integrity Check Value (ICV)
of AH [I-D.ietf-6man-segment-routing-header], so AH can not be
directly applicable to SRv6 packets. HMAC TLV in SRH is used for
making sure that the SRH fields like SIDs are not changed along the
path. While the intra SRv6 domain is trustworthy, so HMAC will be
processed at the ingress nodes only, and could be ignore at the other
nodes inside the trusted domain.
7. Security Considerations 7. Security Considerations
TBA TBA
8. Acknowledgements 8. Acknowledgements
TBA Manty thanks to Charles Perkins and Stefano Previdi's valuable
comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing- Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-20 (work in progress), June 2019. header-21 (work in progress), June 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>. <https://www.rfc-editor.org/info/rfc5095>.
skipping to change at page 9, line 51 skipping to change at page 11, line 22
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing- Policy Architecture", draft-ietf-spring-segment-routing-
policy-03 (work in progress), May 2019. policy-03 (work in progress), May 2019.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-ietf-spring-srv6-network- Network Programming", draft-ietf-spring-srv6-network-
programming-00 (work in progress), April 2019. programming-01 (work in progress), July 2019.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, Internet Protocol", RFC 2401, DOI 10.17487/RFC2401,
November 1998, <https://www.rfc-editor.org/info/rfc2401>. November 1998, <https://www.rfc-editor.org/info/rfc2401>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
 End of changes. 50 change blocks. 
161 lines changed or deleted 229 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/