Internet DRAFT - draft-li-spring-srv6-security-consideration
draft-li-spring-srv6-security-consideration
Spring C. Li
Internet-Draft N. Geng
Intended status: Informational Huawei
Expires: 25 January 2024 C. Xie
China Telecom
H. Tian
CAICT
T. Tong
China Unicom
Z. Li
J. Mao
Huawei
24 July 2023
Security Considerations for SRv6 Networks
draft-li-spring-srv6-security-consideration-11
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.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 25 January 2024 [Page 1]
Internet-Draft SRv6 Security Considerations July 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Security Implications in SRv6 Networks . . . . . . . . . . . 3
2.1. Vulnerabilities of SIDs/SRH . . . . . . . . . . . . . . . 4
2.2. Vulnerabilities Inherited from IPv6 . . . . . . . . . . . 4
2.3. Implications on Security Devices . . . . . . . . . . . . 5
3. Security Advice on SRv6 Networks . . . . . . . . . . . . . . 5
3.1. Basic Traffic Filtering . . . . . . . . . . . . . . . . . 6
3.1.1. ACL-based Filtering for External Interfaces . . . . . 7
3.1.2. ACL-based Filtering for Internal Interfaces . . . . . 7
3.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 7
3.1.4. Operational Considerations of Basic Traffic
Filtering . . . . . . . . . . . . . . . . . . . . . . 8
3.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Source Address Validation . . . . . . . . . . . . . . . . 8
3.4. Control Plane Security Operations . . . . . . . . . . . . 9
3.5. ICMPv6 Rate-Limiting . . . . . . . . . . . . . . . . . . 9
3.6. IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Operations Related to Security Devices . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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.
Li, et al. Expires 25 January 2024 [Page 2]
Internet-Draft SRv6 Security Considerations July 2023
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.
* SRv6 makes use of the SRH which is a new type of Routing Extension
Header. Therefore, the security properties of the Routing
Extension Header are addressed by the SRH. See [RFC5095] and
[RFC8754] for details.
* SRv6 consists of using the SRH on the IPv6 dataplane which
security properties can be understood based on previous work
[RFC4301], [RFC4302], [RFC4303] and [RFC4942].
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
Li, et al. Expires 25 January 2024 [Page 3]
Internet-Draft SRv6 Security Considerations July 2023
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
Li, et al. Expires 25 January 2024 [Page 4]
Internet-Draft SRv6 Security Considerations July 2023
* 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.
Li, et al. Expires 25 January 2024 [Page 5]
Internet-Draft SRv6 Security Considerations July 2023
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.
Li, et al. Expires 25 January 2024 [Page 6]
Internet-Draft SRv6 Security Considerations July 2023
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.
Li, et al. Expires 25 January 2024 [Page 7]
Internet-Draft SRv6 Security Considerations July 2023
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].
Li, et al. Expires 25 January 2024 [Page 8]
Internet-Draft SRv6 Security Considerations July 2023
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.
3.7. Operations Related to Security Devices
When computing segment lists for normal forwarding or path
protection, make sure that the SRv6 path does not bypass the required
security devices like firewall [I-D.li-rtgwg-enhanced-ti-lfa].
Li, et al. Expires 25 January 2024 [Page 9]
Internet-Draft SRv6 Security Considerations July 2023
In some cases, stateful security devices (e.g., stateful firewall)
are difficult to learn the accurate traffic state due to asymmetric
address or hidden destination address (see Section 2.3). To cope
with the issues, operators SHOULD intentionally configure symmetric
addresses on routers, e.g., a source address in a outbound packet is
set to the destination address in the inbound packet. Besides, the
stateful security devices SHOULD be able to figure out the real
destination address of SRv6 flow, so that the recorded state can
accurately detect the returned flow.
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, 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>.
[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>.
Li, et al. Expires 25 January 2024 [Page 10]
Internet-Draft SRv6 Security Considerations July 2023
[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, March 2020,
<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, July 2017,
<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,
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>.
[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>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<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, March 2006,
<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, March
2004, <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, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
Li, et al. Expires 25 January 2024 [Page 11]
Internet-Draft SRv6 Security Considerations July 2023
[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, February 2021,
<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, August 2021,
<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, December 2020,
<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, 10 July 2023,
<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, 6 April 2023,
<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, 4 May 2023, <https://datatracker.ietf.org/doc/html/
draft-li-rtgwg-enhanced-ti-lfa-08>.
[manrs-antispoofing]
"MANRS Implementation Guide", January 2023,
<https://www.manrs.org/netops/guide/antispoofing>.
Authors' Addresses
Cheng Li
Huawei
Beijing
China
Li, et al. Expires 25 January 2024 [Page 12]
Internet-Draft SRv6 Security Considerations July 2023
Email: c.l@huawei.com
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Chongfeng Xie
China Telecom
Beijing
China
Email: xiechf@chinatelecom.cn
Hui Tian
CAICT
Beijing
China
Email: tianhui@caict.ac.cn
Tian Tong
China Unicom
Beijing
China
Email: tongt5@chinaunicom.cn
Zhenbin Li
Huawei
Beijing
China
Email: lizhenbin@huawei.com
Jianwei Mao
Huawei
Beijing
China
Email: MaoJianwei@huawei.com
Li, et al. Expires 25 January 2024 [Page 13]
