idnits 2.17.1 draft-li-spring-srv6-security-consideration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2019) is 1780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 412, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-20 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-00 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Spring C. Li 3 Internet-Draft Z. Li 4 Intended status: Standards Track Huawei 5 Expires: December 13, 2019 June 11, 2019 7 Security Considerations for SRv6 Networks 8 draft-li-spring-srv6-security-consideration-00 10 Abstract 12 SRv6 inherits potential security vulnerabilities from Source Routing 13 in general, and also from IPv6. This document describes various 14 threats to SRv6 networks and existing approaches to solve these 15 threats. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 13, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Security Principles of SRv6 Networking . . . . . . . . . . . 3 54 4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4 55 4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4 56 4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5 57 4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 6 58 4.4. Repudiation in SRv6 Networks . . . . . . . . . . . . . . 6 59 4.5. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 6 60 4.6. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 7 61 4.7. Malicious Packet Data in SRv6 Networks . . . . . . . . . 7 62 5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 7 63 6. Security Policy Design . . . . . . . . . . . . . . . . . . . 7 64 6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 7 65 6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 7 66 6.1.2. ACL for Internal Interface . . . . . . . . . . . . . 8 67 6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 8 68 6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 9.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 Segment routing (SR) [RFC8402] is a source routing paradigm that 79 explicitly indicates the forwarding path for packets at the source 80 node by inserting an ordered list of instructions, called segments. 81 A segment can represent a topological or service-based instruction. 83 When segment routing is deployed on IPv6 [RFC8200] dataplane, called 84 SRv6 [I-D.ietf-6man-segment-routing-header], a segment is a 128 bit 85 value, and it can be an IPv6 address of a local interface but it does 86 not have to. For supporting SR, an extended header called Segment 87 Routing Header (SRH), which contains a list of SIDs and several 88 needed information such as Segments Left, has been defined in 89 [I-D.ietf-6man-segment-routing-header]. By using SRH, an Ingress 90 router can steer SRv6 pakcets into an explicit forwarding path so 91 that many use cases like Traffic engineering, Service Function 92 Chaining can be deployed easily by SRv6. 94 However, SRv6 also bring some new security problems. This document 95 describes various threats to networks employing SRv6. SRv6 inherits 96 potential security vulnerabilities from source routing in general, 97 and also from IPv6. 99 o SRv6 is a descendent of IPv6 routing header, and its security 100 properties can be understood based on previous work [RFC5095]. 102 o SRv6 is a descendent of IPv6, and its security properties can be 103 understood based on previous work [RFC4301], [RFC4302], [RFC4303] 104 and [RFC4942]. 106 In this document, we will consider the dangers from the following 107 kinds of threats: 109 o Wiretapping/eavesdropping 111 o Packet Falsification 113 o Identity Spoofing 115 o Repudiation 117 o Packet Replay 119 o DDOS 121 o Malicious packet data 123 The rest of this document will describe the above security threats in 124 SRv6 networks and existing approaches to guarding against the 125 threats. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 [RFC2119] and [RFC8174]. 134 This document uses the terminology defined in [RFC5095] and 135 [I-D.ietf-6man-segment-routing-header]. 137 3. Security Principles of SRv6 Networking 139 As with other similar source-routing architecture, an attacker may 140 manipulate the traffic path by modifying the packet header. SPRING 141 architecture MUST provide clear trust domain boundaries so that 142 source-routing information is only usable within the trusted domain 143 and never exposed to the outside world [RFC7855]. It is expected 144 that, by default, the explicit routing information is not leaked 145 through the boundaries of the administered domain. Therefore, the 146 data plane MUST NOT expose any source-routing information when a 147 packet leaves the trusted domain. 149 By default, SR operates within a trusted domain. Traffic MUST be 150 filtered at the domain boundaries [RFC8402]. 152 Unless otherwise noted, the discussion in this document pertain to SR 153 networks which can be characterized as "trusted domains" -- i.e., the 154 SR routers in the domain are presumed to be operating without 155 malicious intent and also to conform to specification for the 156 protocols that they use. 158 This document assumes that the SR-capable routers and transit IPv6 159 routers within SRv6 trusted domains are trustworthy, since the SRv6 160 packets are treated as normal IPv6 packets in transit nodes, SRH will 161 not bring new security problem. The security consideration of IPv6 162 networks is out of scope of this document. 164 4. Types of Vulnerabilities in SR Networks 166 In this section we will make a fuller explanation about the types of 167 vulnerabilities as listed in Section 1. Then for each type we will 168 explain whether or not the vulnerability exists in a trusted domain. 170 4.1. Eavesdropping Vulnerabilities in SRv6 Networks 172 As with practically all kinds of networks, traffic in an SRv6 network 173 may be vulnerable to eavesdropping. 175 o Threats: Eavesdropping 177 o Solutions: ESP [RFC4303] can be used to prevent Eavesdropping. 178 The ESP header is inserted after the IP header and before the next 179 layer protocol header (transport mode) or before an encapsulated 180 IP header (tunnel mode). ESP can be used to provide 181 confidentiality, data origin authentication, connectionless 182 integrity, an anti-replay service (a form of partial sequence 183 integrity), and (limited) traffic flow confidentiality. The set 184 of services provided depends on options selected at the time of 185 Security Association (SA) establishment and on the location of the 186 implementation in a network topology. 188 o Conclusions: In tunnel mode of ESP, packets are encrypted and can 189 not be eavesdropped in a trusted SRv6 domain. In transport mode 190 of ESP, the payload of packets are encrypted and can not be 191 eavesdropped in a trusted SRv6 domain, while the IPv6 header and 192 SRH is not encrypted. 194 o Gaps: The IPv6 header and SRH are not encrypted in transport mode 195 of ESP, since they are out of scope of ESP encryption, which may 196 be eavesdropped by attackers. 198 4.2. Packet Falsification in SRv6 Networks 200 As SRv6 domain is a trusted domain, there is no Packet Falsification 201 within the SRv6 domain. 203 As the packets from outside of SRv6 domain can not be trusted, so 204 Integrity Verification policy should be deployed at the external 205 interfaces of the ingress SRv6 routers to verify the packets from 206 outside of SRv6 domain [I-D.ietf-spring-srv6-network-programming]. 207 Also, the packets with SRH sent form hosts within the SRv6 domain 208 should be verified to prevent the falsification between the host and 209 the ingress router. [I-D.ietf-spring-srv6-network-programming]. 211 o Threats: Packet Falsification 213 o Solutions: The packets from outside can not be trusted, so 214 Integrity Verification policy should be deployed at the external 215 interfaces by using IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) 216 or HMAC [RFC2401]. AH, ESP and HMAC can provide Integrity 217 Verification for pakcets, while the ESP can encrypt the payload to 218 provide higher security. However, it has been noted that AH and 219 ESP are not directly applicable to reducing the vulnerabilities of 220 SRv6, due to the presence of mutalble fields in the SRH. To solve 221 this problem, [I-D.ietf-6man-segment-routing-header] defines the 222 mechanism to carry HMAC TLV in SRH to verify the integrity of 223 packets including the SRH fields. The HMAC TLV will be processed 224 based on Local policy, normally, only the ingress routers will 225 process the HMAC TLV. Within the SRv6 domain, the packets are 226 trusted, so HMAC TLV SHOULD be ignore. In another word, the SID 227 list are mutable within the SRv6 domain but can not be changed 228 before processing the HMAC TLV. 230 o Conclusions: There is no Packet Falsification within the SRv6 231 domain. Integrity Verification policy like HMAC processing should 232 be deployed at the external interfaces of the ingress SRv6 routers 233 for the packets from outside and the packets with SRH from hosts 234 within the SRv6 domain. 236 o Gaps: IPsec can not provide verification for SRH. 238 4.3. Identity Spoofing in SRv6 Networks 240 The same as Packet Falsification, there is no Identity Spoofing 241 within the SRv6 domain since it is a trusted domain. 243 Authentication policy policy should be deployed at the external 244 interfaces of the ingress SRv6 routers to validate the packets from 245 outside of SRv6 domain [I-D.ietf-spring-srv6-network-programming]. 246 Also, the packets with SRH sent form hosts within the SRv6 domain 247 should be validated to prevent the Identity Spoofing 248 [I-D.ietf-spring-srv6-network-programming]. 250 o Threats: Identity Spoofing 252 o Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC 253 [RFC2401] can be used for Authentication. AH, ESP and HMAC can 254 provide Authentication of source node, while the ESP can encrypt 255 the payload to provide higher security. Same as section 3.2. 257 o Conclusions: There is no Identity Spoofing within the SRv6 domain. 258 Identity Spoofing policy should be deployed at the external 259 interfaces of the ingress SRv6 routers for the packets from 260 outside and the packets with SRH from hosts within the SRv6 261 domain. 263 o Gaps: TBA 265 4.4. Repudiation in SRv6 Networks 267 TBA 269 4.5. Packet Replay in SRv6 Networks 271 There are no new Packet Replay threat brought by SRH. ESP can be 272 applied to SRv6 to prevent Packet replay attacks. 274 o Threats: Packet Replay 276 o Solutions: ESP [RFC4303] ) can be used to prevent Replay Attacks. 278 o Conclusions: There are no new Packet Replay threat brought by SRH. 279 ESP can be applied to SRv6 to prevent Packet replay attacks. 281 o Gaps: TBD 283 4.6. DOS/DDOS in SRv6 Networks 285 The generation of ICMPv6 error messages may be used to attempt 286 DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) attacks by 287 sending an error-causing destination address or SRH in back-to-back 288 packets [I-D.ietf-6man-segment-routing-header]. An implementation 289 that correctly follows Section 2.4 of [RFC4443] would be protected by 290 the ICMPv6 rate-limiting mechanism. 292 o Threats: DOS/DDOS 294 o Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443] 296 o Conclusions: There are no DOS/DDOS threats within SRv6 domain, the 297 threats come from outside of the domain, and can be prevented by 298 ICMPv6 rate-limiting mechanism. 300 o Gaps: TBD 302 4.7. Malicious Packet Data in SRv6 Networks 304 TBA 306 5. Effects of the above on SRv6 Use Cases 308 This section describeS the effects of the above-mentioned 309 vulnerabilities in terms of applicability statement and the use cases 310 given in citation. 312 TBA. 314 6. Security Policy Design 316 The basic security for intra-domain deployment is described in 317 [I-D.ietf-spring-srv6-network-programming] and the enhanced security 318 machanism is defined in [I-D.ietf-6man-segment-routing-header]. 320 In [I-D.ietf-spring-srv6-network-programming], it defines three basic 321 security manchanisms. 323 6.1. Basic Security Design 325 6.1.1. ACL for External Interfaces 327 An SRv6 router MUST support an ACL on the external interface that 328 drops any traffic with SA or DA in the internal SID space. 330 A provider would generally do this for its internal address space to 331 prevent access to internal addresses and in order to prevent 332 spoofing. The technique is extended to the local SID space.But in 333 some use cases, Binding SID can be leaked to outside of SRv6 domain. 334 Detailed ACL should be configured for Binding SID. 336 The typical counters of an ACL are expected. 338 6.1.2. ACL for Internal Interface 340 An SRv6 router MUST support an ACL with the following behavior: 342 1. IF (DA == LocalSID) && (SA != internal address or SID space) : 343 2. drop 345 This prevents access to locally instantiated SIDs from outside the 346 operator's infrastructure. Note that this ACL may not be enabled in 347 all cases. For example, specific SIDs can be used to provide 348 resources to devices that are outside of the operator's 349 infrastructure. 351 The typical counters of an ACL are expected. 353 6.1.3. SID Instantiation 355 As per the End definition, an SRv6 router MUST only implement the End 356 behavior on a local IPv6 address if that address has been explicitly 357 enabled as an SRv6 SID. 359 Packets received with destination address representing a local 360 interface that has not been enabled as an SRv6 SID MUST be dropped. 362 6.2. Enhanced Security Design 364 HMAC is the enhanced security machanism for SRv6 as defined in 365 [I-D.ietf-6man-segment-routing-header]. HMAC is used for validating 366 the packets with SRH sent from hosts within SRv6 domain. 368 7. Security Considerations 370 TBA 372 8. Acknowledgements 374 TBA 376 9. References 378 9.1. Normative References 380 [I-D.ietf-6man-segment-routing-header] 381 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 382 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 383 Routing Header (SRH)", draft-ietf-6man-segment-routing- 384 header-20 (work in progress), June 2019. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 392 of Type 0 Routing Headers in IPv6", RFC 5095, 393 DOI 10.17487/RFC5095, December 2007, 394 . 396 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 397 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 398 May 2017, . 400 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 401 (IPv6) Specification", STD 86, RFC 8200, 402 DOI 10.17487/RFC8200, July 2017, 403 . 405 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 406 Decraene, B., Litkowski, S., and R. Shakir, "Segment 407 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 408 July 2018, . 410 9.2. Informative References 412 [I-D.ietf-spring-segment-routing-policy] 413 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 414 bogdanov@google.com, b., and P. Mattes, "Segment Routing 415 Policy Architecture", draft-ietf-spring-segment-routing- 416 policy-03 (work in progress), May 2019. 418 [I-D.ietf-spring-srv6-network-programming] 419 Filsfils, C., Camarillo, P., Leddy, J., 420 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 421 Network Programming", draft-ietf-spring-srv6-network- 422 programming-00 (work in progress), April 2019. 424 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 425 Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, 426 November 1998, . 428 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 429 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 430 December 2005, . 432 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 433 DOI 10.17487/RFC4302, December 2005, 434 . 436 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 437 RFC 4303, DOI 10.17487/RFC4303, December 2005, 438 . 440 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 441 Control Message Protocol (ICMPv6) for the Internet 442 Protocol Version 6 (IPv6) Specification", STD 89, 443 RFC 4443, DOI 10.17487/RFC4443, March 2006, 444 . 446 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 447 Co-existence Security Considerations", RFC 4942, 448 DOI 10.17487/RFC4942, September 2007, 449 . 451 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 452 Litkowski, S., Horneffer, M., and R. Shakir, "Source 453 Packet Routing in Networking (SPRING) Problem Statement 454 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 455 2016, . 457 Authors' Addresses 459 Cheng Li 460 Huawei 461 China 463 Email: ChengLi13@huawei.com 465 Zhenbin Li 466 Huawei 467 China 469 Email: lizhenbin@huawei.com