idnits 2.17.00 (12 Aug 2021) /tmp/idnits4015/draft-li-spring-srv6-security-consideration-08.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.) ** There is 1 instance of too long lines in the document, the longest one being 25 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (22 April 2022) is 22 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC7855' is defined on line 515, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Informational Huawei 5 Expires: 24 October 2022 C. Xie 6 China Telecom 7 H. Tian 8 CAICT 9 J. Mao 10 Huawei 11 22 April 2022 13 Security Considerations for SRv6 Networks 14 draft-li-spring-srv6-security-consideration-08 16 Abstract 18 SRv6 inherits potential security vulnerabilities from Source Routing 19 in general, and also from IPv6. This document describes various 20 threats and security concerns related to SRv6 networks and existing 21 approaches to solve these threats. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 24 October 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 3. Security Principles of SRv6 Networking . . . . . . . . . . . 4 60 4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4 61 4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4 62 4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5 63 4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 7 64 4.4. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 7 65 4.5. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 8 66 4.6. Malicious Packet Data in SRv6 Networks . . . . . . . . . 8 67 5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 8 68 6. Security Policy Design . . . . . . . . . . . . . . . . . . . 8 69 6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 9 70 6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 9 71 6.1.2. ACL for Internal Interfaces . . . . . . . . . . . . . 9 72 6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 10 73 6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 10 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 9.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Segment Routing (SR) [RFC8402] is a source routing paradigm that 84 explicitly indicates the forwarding path for packets at the source 85 node by inserting an ordered list of instructions, called segments. 86 A segment can represent a topological or service-based instruction. 88 When segment routing is deployed on IPv6 [RFC8200] dataplane, called 89 SRv6 [RFC8754], a segment is a 128 bit value, and can the IPv6 90 address of a local interface but it does not have to. For supporting 91 SR, a new type of Routing Extension Header is defined and called the 92 Segment Routing Header (SRH). The SRH contains a list of SIDs and 93 other information such as Segments Left. The SRH is defined in 94 [RFC8754]. By using the SRH, an ingress router can steer SRv6 95 packets into an explicit forwarding path so that many use cases like 96 Traffic Engineering, Service Function Chaining can be deployed easily 97 by SRv6. 99 However, SRv6 also brings some new security concerns. This document 100 describes various threats to networks deploying SRv6. SRv6 inherits 101 potential security vulnerabilities from source routing in general, 102 and also from IPv6. 104 * SRv6 makes use of the SRH which is a new type of Routing Extension 105 Header. Therefore, the security properties of the Routing 106 Extension Header are addressed by the SRH. See [RFC5095] and 107 [RFC8754] for details. 109 * SRv6 consists of using the SRH on the IPv6 dataplane which 110 security properties can be understood based on previous work 111 [RFC4301], [RFC4302], [RFC4303] and [RFC4942]. 113 In this document, we will consider the dangers from the following 114 kinds of threats: 116 * Wiretapping/eavesdropping 118 * Packet Falsification 120 * Identity Spoofing 122 * Packet Replay 124 * DOS/DDOS 126 * Malicious Packet Data 128 The rest of this document describes the above security threats in 129 SRv6 networks and existing approaches to mitigate and avoid the 130 threats. 132 2. Terminology 134 This document uses the terminology defined in [RFC5095] and 135 [RFC8754]. 137 2.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. Security Principles of SRv6 Networking 147 As with other similar source-routing architectures, an attacker may 148 manipulate the traffic path by modifying the packet header. SPRING 149 architecture [RFC8402] allows clear trust domain boundaries so that 150 source-routing information is only usable within the trusted domain 151 and never exposed to the outside world. It is expected that, by 152 default, explicit routing is only used within the boundaries of the 153 administered domain. Therefore, the data plane does not expose any 154 source-routing information when a packet leaves the trusted domain. 155 Traffic is filtered at the domain boundaries [RFC8402]. 157 Unless otherwise noted, the discussion in this document pertain to SR 158 networks which can be characterized as "trusted domains", i.e., the 159 SR routers in the domain are presumed to be operated by the same 160 administrative entity without malicious intent and also according to 161 specifications of the protocols that they use in the infrastructure. 163 This document assumes that the SR-capable routers and transit IPv6 164 routers within the SRv6 trusted domains are trustworthy. Hence, the 165 SRv6 packets are treated as normal IPv6 packets in transit nodes and 166 the SRH will not bring new security problem. The security 167 considerations of IPv6 networks are out of scope of this document. 169 4. Types of Vulnerabilities in SR Networks 171 This section outlines in details the different types of 172 vulnerabilities listed in Section 1. Then, for each type, an attempt 173 to determine whether or not the vulnerability exists in a trusted 174 domain is made. 176 4.1. Eavesdropping Vulnerabilities in SRv6 Networks 178 As with practically all kinds of networks, traffic in an SRv6 network 179 may be vulnerable to eavesdropping. 181 * Threats: Eavesdropping 182 * Solutions: Encapsulating Security Payload (ESP, [RFC4303]) can be 183 used in order to prevent Eavesdropping. The ESP header is either 184 inserted between the IP header and the next layer(transport) 185 protocol header, or before an encapsulated IP header (tunnel 186 mode). ESP can be used in order to provide confidentiality, data 187 origin authentication, connectionless integrity, an anti-replay 188 service (a form of partial sequence integrity), and (limited) 189 traffic flow confidentiality. The set of services provided 190 depends on the selected options at the time of the Security 191 Association (SA) establishment and on the location of the 192 implementation in a network topology.(add reference to the 193 different points explained in this paragraph). 195 * Conclusion: In tunnel mode of ESP, packets are encrypted and can 196 not be eavesdropped in a trusted SRv6 domain. In transport mode 197 of ESP, the payload of packets are encrypted and cannot be 198 eavesdropped in a trusted SRv6 domain, even if the IPv6 and SRH 199 headers are not encrypted. 201 * Gaps: The IPv6 and SRH headers are not encrypted in transport mode 202 of ESP which may be eavesdropped by attackers. 204 +------------------------------------------------------------------+ 205 |IPv6 Header| SRH | ESP| Payload |ESP Tail| ESP Auth data| 206 +------------------------------------------------------------------+ 207 |----- Encryption Scope -----| 208 |------ Authentication Scope -----| 210 Figure 1: Transport Mode ESP for SRv6 packets 212 +----------------------------------------------------------------------+ 213 |New IPv6 Header|SRH|ESP|IPv6 Header|SRH|Payload|ESP Tail|ESP Auth data| 214 +----------------------------------------------------------------------+ 215 |------ Encryption Scope --------| 216 |------- Authentication Scope -------| 218 Figure 2: Tunnel Mode ESP for SRv6 packets 220 4.2. Packet Falsification in SRv6 Networks 222 As SRv6 domain is a trusted domain, there is no Packet Falsification 223 within the SRv6 domain. 225 As the packets from outside of SRv6 domain cannot be trusted, an 226 Integrity Verification policy is typically deployed at the external 227 interfaces of the ingress SRv6 routers in order to verify the 228 incoming packets (i.e., from outside of SRv6 domain [RFC8986]). 229 Also, the packets with SRH sent form hosts within the SRv6 domain 230 should be verified in order to prevent the falsification between the 231 host and the ingress router. [RFC8986]. 233 * Threats: Packet Falsification 235 * Solutions: The packets from outside can not be trusted, so 236 Integrity Verification policy should be deployed at the external 237 interfaces by using , e.g., IPSec [RFC4301] (AH [RFC4302], ESP 238 [RFC4303] ) or HMAC [RFC2104]. AH [RFC4302], ESP [RFC4303] and 239 HMAC [RFC2104] can provide Integrity Verification for packets, 240 while the ESP can encrypt the payload in order to provide higher 241 security. However, it has been noted that the AH and ESP are not 242 directly applicable in order to reduce the vulnerabilities of SRv6 243 due to the presence of mutable fields in the SRH. In order to 244 solve this problem, [RFC8754] defines a mechanism in order to 245 carry HMAC TLV in the SRH so to verify the integrity of packets 246 including the SRH fields. The HMAC TLV is usually processed based 247 on the local policy, only at the ingress router. Within the SRv6 248 domain, the packets are trusted, so HMAC TLV is typically ignored. 249 In other words, the segment list is mutable within the SRv6 domain 250 but cannot be changed before processing the HMAC TLV. 252 * Conclusions: There is no Packet Falsification within a trusted 253 SRv6 domain. Integrity Verification policy like HMAC processing 254 should be deployed at the external interfaces of the ingress SRv6 255 routers filtering SRH packets from outside the trusted domain and 256 SRH packets from hosts within the SRv6 domain. 258 * Gaps: IPsec cannot provide verification for SRH. 260 +-----------------------------------------------------------------+ 261 |IPv6 Header | SRH | AH| Payload | 262 +-----------------------------------------------------------------+ 264 |--Auth Scope--|HMAC |---------------Auth Scope-------------------| 266 Figure 3: Transport Mode AH and HMAC for SRv6 packets 268 +-----------------------------------------------------------------+ 269 |New IPv6 Header|SRH | AH |IPv6 Header|SRH|Payload | 270 +-----------------------------------------------------------------+ 271 |--Auth Scope---|HMAC|---------------Auth Scope-------------------| 272 Figure 4: Tunnel Mode AH and HMAC for SRv6 packets 274 4.3. Identity Spoofing in SRv6 Networks 276 The same as for Packet Falsification, there is no Identity Spoofing 277 possible within the boundaries of a SRv6 trusted domain where all 278 nodes are under control of the same administrative organization. 280 Authentication policy should be deployed at the external interfaces 281 of the ingress SRv6 routers in order to validate the packets from 282 outside of SRv6 domain [RFC8986]. Also, the packets with SRH sent 283 form hosts inside the SRv6 domain should be validated in order to 284 prevent the Identity Spoofing [RFC8986]. 286 * Threats: Identity Spoofing 288 * Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC 289 [RFC2104] can be used for Authentication. AH, ESP and HMAC can 290 provide Authentication of source node, while the ESP can encrypt 291 the payload in order to provide higher security. Same as section 292 3.2. 294 * Conclusion: There is no Identity Spoofing within a trusted SRv6 295 domain. Identity Spoofing policy should be deployed on the 296 external interfaces of the ingress SRv6 routers for the packets 297 from outside and the packets with SRH from hosts within the SRv6 298 domain. 300 * Gaps: TBA 302 4.4. Packet Replay in SRv6 Networks 304 There are no new Packet Replay threat brought by SRH. ESP can be 305 applied to SRv6 in order to prevent Packet replay attacks. 307 * Threats: Packet Replay 309 * Solutions: ESP [RFC4303] can be used to prevent Replay Attacks. 311 * Conclusion: There are no new Packet Replay threat brought by SRH. 312 ESP can be applied to SRv6 in order to prevent Packet replay 313 attacks. 315 * Gaps: TBD 317 4.5. DOS/DDOS in SRv6 Networks 319 The generation of ICMPv6 error messages may be used in order to 320 attempt DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) 321 attacks by sending an error-causing destination address or SRH in 322 back-to-back packets [RFC8754]. An implementation that correctly 323 follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 324 rate-limiting mechanism also in the case of packets with an SRH. 326 * Threats: DOS/DDOS 328 * Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443] 330 * Conclusions: There are no DOS/DDOS threats within SRv6 domain, the 331 threats come from outside of the domain, and can be prevented by 332 ICMPv6 rate-limiting mechanism. 334 * Gaps: TBD 336 4.6. Malicious Packet Data in SRv6 Networks 338 TBA 340 5. Effects of the above on SRv6 Use Cases 342 This section describes the effects of the above-mentioned 343 vulnerabilities in terms of applicability statement and the use cases 344 given in citation. 346 TBA. 348 6. Security Policy Design 350 The basic security for intra-domain deployment is described in 351 [RFC8986] and the enhanced security mechanism is defined in 352 [RFC8754]. 354 In [RFC8986], additional basic security mechanisms are defined. For 355 easier understanding, a easy example is shown in Figure 5. 357 *************************** ***** 358 * (3) h2 * * * SRv6 domain 359 * \ | * ***** 360 h1-----A-----B-----C-----D-------E-------F 361 / * (2) (2) (2) * \ 362 (1,2,3) * * (1,2) 363 * * 364 *************************** 365 Figure 5: SRv6 Security Policy Design 367 * A-E: SRv6 Routers inside the SRv6 domain, A and E are the edge 368 router, can be called Ingress router instead. 370 * F: Router F outside the SRv6 domain. 372 * h1: A host outside the SRv6 domain connects to router Router A. 374 * h2: A host within SRv6 domain, which connects to the Router D. 376 * (1): Security policy 1: ACL for External Interface. 378 * (2): Security policy 2: ACL for Internal Interfaces. 380 * (3): Security policy 3: Policy for processing HMAC, should be 381 deployed at the ingress nodes. 383 6.1. Basic Security Design 385 6.1.1. ACL for External Interfaces 387 Typically, in any trusted domain, ingress routers are configured with 388 Access Control Lists (ACL) filtering out any packet externally 389 received with SA/DA having a domain internal address. An SRv6 router 390 typically comply with the same rule. 392 A provider would generally do this for its internal address space in 393 order to prevent access to internal addresses and in order to prevent 394 spoofing. The technique is extended to the local SID space. 395 However, in some use cases, Binding SID can be leaked outside of SRv6 396 domain. Detailed ACL should be then configured in order to consider 397 the externally advertised Binding SID. 399 6.1.2. ACL for Internal Interfaces 401 An SRv6 router MUST support an ACL with the following behavior: 403 1. IF (DA == LocalSID) && (SA != internal address or SID space) : 404 2. drop 406 This prevents access to locally instantiated SIDs from outside the 407 operator's infrastructure. Note that this ACL may not be enabled in 408 all cases. For example, specific SIDs can be used to provide 409 resources to devices that are outside of the operator's 410 infrastructure. 412 6.1.3. SID Instantiation 414 As per the End definition [RFC8986], an SRv6 router MUST only 415 implement the End behavior on a local IPv6 address if that address 416 has been explicitly enabled as an SRv6 SID. 418 Packets received with destination address representing a local 419 interface that has not been enabled as an SRv6 SID MUST be dropped. 421 6.2. Enhanced Security Design 423 HMAC [RFC2104] is the enhanced security mechanism for SRv6 as defined 424 in [RFC8754]. HMAC is used for validating the packets with SRH sent 425 from hosts within SRv6 domain. 427 Since the SRH is mutable in computing the Integrity Check Value (ICV) 428 of AH [RFC8754], so AH can not be directly applicable to SRv6 429 packets. HMAC TLV in SRH is used for making sure that the SRH fields 430 like SIDs are not changed along the path. While the intra SRv6 431 domain is trustworthy, so HMAC will be processed at the ingress nodes 432 only, and could be ignore at the other nodes inside the trusted 433 domain. 435 7. Security Considerations 437 TBA 439 8. Acknowledgements 441 Manty thanks to Charles Perkins and Stefano Previdi's valuable 442 comments. 444 9. References 446 9.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, 450 DOI 10.17487/RFC2119, March 1997, 451 . 453 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 454 of Type 0 Routing Headers in IPv6", RFC 5095, 455 DOI 10.17487/RFC5095, December 2007, 456 . 458 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 459 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 460 May 2017, . 462 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 463 (IPv6) Specification", STD 86, RFC 8200, 464 DOI 10.17487/RFC8200, July 2017, 465 . 467 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 468 Decraene, B., Litkowski, S., and R. Shakir, "Segment 469 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 470 July 2018, . 472 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 473 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 474 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 475 . 477 9.2. Informative References 479 [I-D.ietf-spring-segment-routing-policy] 480 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 481 P. Mattes, "Segment Routing Policy Architecture", Work in 482 Progress, Internet-Draft, draft-ietf-spring-segment- 483 routing-policy-22, 22 March 2022, 484 . 487 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 488 Hashing for Message Authentication", RFC 2104, 489 DOI 10.17487/RFC2104, February 1997, 490 . 492 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 493 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 494 December 2005, . 496 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 497 DOI 10.17487/RFC4302, December 2005, 498 . 500 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 501 RFC 4303, DOI 10.17487/RFC4303, December 2005, 502 . 504 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 505 Control Message Protocol (ICMPv6) for the Internet 506 Protocol Version 6 (IPv6) Specification", STD 89, 507 RFC 4443, DOI 10.17487/RFC4443, March 2006, 508 . 510 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 511 Co-existence Security Considerations", RFC 4942, 512 DOI 10.17487/RFC4942, September 2007, 513 . 515 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 516 Litkowski, S., Horneffer, M., and R. Shakir, "Source 517 Packet Routing in Networking (SPRING) Problem Statement 518 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 519 2016, . 521 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 522 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 523 (SRv6) Network Programming", RFC 8986, 524 DOI 10.17487/RFC8986, February 2021, 525 . 527 Authors' Addresses 529 Cheng Li 530 Huawei 531 China 532 Email: c.l@huawei.com 534 Zhenbin Li 535 Huawei 536 China 537 Email: lizhenbin@huawei.com 539 Chongfeng Xie 540 China Telecom 541 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 542 Beijing 543 China 544 Email: xiechf@chinatelecom.cn 545 Hui Tian 546 CAICT 547 Beijing 548 China 549 Email: tianhui@caict.ac.cn 551 Jianwei Mao 552 Huawei 553 China 554 Email: MaoJianwei@huawei.com