idnits 2.17.1 draft-li-spring-srv6-security-consideration-07.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 22 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2021) is 910 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 483, but no explicit reference was found in the text == Unused Reference: 'RFC7855' is defined on line 517, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 Summary: 2 errors (**), 0 flaws (~~), 4 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: April 24, 2022 C. Xie 6 China Telecom 7 H. Tian 8 CAICT 9 J. Mao 10 Huawei 11 October 21, 2021 13 Security Considerations for SRv6 Networks 14 draft-li-spring-srv6-security-consideration-07 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 April 24, 2022. 40 Copyright Notice 42 Copyright (c) 2021 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. Security Principles of SRv6 Networking . . . . . . . . . . . 4 61 4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4 62 4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4 63 4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5 64 4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 6 65 4.4. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 7 66 4.5. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 7 67 4.6. Malicious Packet Data in SRv6 Networks . . . . . . . . . 8 68 5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 8 69 6. Security Policy Design . . . . . . . . . . . . . . . . . . . 8 70 6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 9 71 6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 9 72 6.1.2. ACL for Internal Interfaces . . . . . . . . . . . . . 9 73 6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 9 74 6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 10 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Segment Routing (SR) [RFC8402] is a source routing paradigm that 85 explicitly indicates the forwarding path for packets at the source 86 node by inserting an ordered list of instructions, called segments. 87 A segment can represent a topological or service-based instruction. 89 When segment routing is deployed on IPv6 [RFC8200] dataplane, called 90 SRv6 [RFC8754], a segment is a 128 bit value, and can the IPv6 91 address of a local interface but it does not have to. For supporting 92 SR, a new type of Routing Extension Header is defined and called the 93 Segment Routing Header (SRH). The SRH contains a list of SIDs and 94 other information such as Segments Left. The SRH is defined in 95 [RFC8754]. By using the SRH, an ingress router can steer SRv6 96 packets into an explicit forwarding path so that many use cases like 97 Traffic Engineering, Service Function Chaining can be deployed easily 98 by SRv6. 100 However, SRv6 also brings some new security concerns. This document 101 describes various threats to networks deploying SRv6. SRv6 inherits 102 potential security vulnerabilities from source routing in general, 103 and also from IPv6. 105 o SRv6 makes use of the SRH which is a new type of Routing Extension 106 Header. Therefore, the security properties of the Routing 107 Extension Header are addressed by the SRH. See [RFC5095] and 108 [RFC8754] for details. 110 o SRv6 consists of using the SRH on the IPv6 dataplane which 111 security properties can be understood based on previous work 112 [RFC4301], [RFC4302], [RFC4303] and [RFC4942]. 114 In this document, we will consider the dangers from the following 115 kinds of threats: 117 o Wiretapping/eavesdropping 119 o Packet Falsification 121 o Identity Spoofing 123 o Packet Replay 125 o DOS/DDOS 127 o Malicious Packet Data 129 The rest of this document describes the above security threats in 130 SRv6 networks and existing approaches to mitigate and avoid the 131 threats. 133 2. Terminology 135 This document uses the terminology defined in [RFC5095] and 136 [RFC8754]. 138 2.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. Security Principles of SRv6 Networking 148 As with other similar source-routing architectures, an attacker may 149 manipulate the traffic path by modifying the packet header. SPRING 150 architecture [RFC8402] allows clear trust domain boundaries so that 151 source-routing information is only usable within the trusted domain 152 and never exposed to the outside world. It is expected that, by 153 default, explicit routing is only used within the boundaries of the 154 administered domain. Therefore, the data plane does not expose any 155 source-routing information when a packet leaves the trusted domain. 156 Traffic is filtered at the domain boundaries [RFC8402]. 158 Unless otherwise noted, the discussion in this document pertain to SR 159 networks which can be characterized as "trusted domains", i.e., the 160 SR routers in the domain are presumed to be operated by the same 161 administrative entity without malicious intent and also according to 162 specifications of the protocols that they use in the infrastructure. 164 This document assumes that the SR-capable routers and transit IPv6 165 routers within the SRv6 trusted domains are trustworthy. Hence, the 166 SRv6 packets are treated as normal IPv6 packets in transit nodes and 167 the SRH will not bring new security problem. The security 168 considerations of IPv6 networks are out of scope of this document. 170 4. Types of Vulnerabilities in SR Networks 172 This section outlines in details the different types of 173 vulnerabilities listed in Section 1. Then, for each type, an attempt 174 to determine whether or not the vulnerability exists in a trusted 175 domain is made. 177 4.1. Eavesdropping Vulnerabilities in SRv6 Networks 179 As with practically all kinds of networks, traffic in an SRv6 network 180 may be vulnerable to eavesdropping. 182 o Threats: Eavesdropping 184 o Solutions: Encapsulating Security Payload (ESP, [RFC4303]) can be 185 used in order to prevent Eavesdropping. The ESP header is either 186 inserted between the IP header and the next layer(transport) 187 protocol header, or before an encapsulated IP header (tunnel 188 mode). ESP can be used in order to provide confidentiality, data 189 origin authentication, connectionless integrity, an anti-replay 190 service (a form of partial sequence integrity), and (limited) 191 traffic flow confidentiality. The set of services provided 192 depends on the selected options at the time of the Security 193 Association (SA) establishment and on the location of the 194 implementation in a network topology.(add reference to the 195 different points explained in this paragraph). 197 o Conclusion: In tunnel mode of ESP, packets are encrypted and can 198 not be eavesdropped in a trusted SRv6 domain. In transport mode 199 of ESP, the payload of packets are encrypted and cannot be 200 eavesdropped in a trusted SRv6 domain, even if the IPv6 and SRH 201 headers are not encrypted. 203 o Gaps: The IPv6 and SRH headers are not encrypted in transport mode 204 of ESP which may be eavesdropped by attackers. 206 +------------------------------------------------------------------+ 207 |IPv6 Header| SRH | ESP| Payload |ESP Tail| ESP Auth data| 208 +------------------------------------------------------------------+ 209 |----- Encryption Scope -----| 210 |------ Authentication Scope -----| 212 Figure 1: Transport Mode ESP for SRv6 packets 214 +----------------------------------------------------------------------+ 215 |New IPv6 Header|SRH|ESP|IPv6 Header|SRH|Payload|ESP Tail|ESP Auth data| 216 +----------------------------------------------------------------------+ 217 |------ Encryption Scope --------| 218 |------- Authentication Scope -------| 220 Figure 2: Tunnel Mode ESP for SRv6 packets 222 4.2. Packet Falsification in SRv6 Networks 224 As SRv6 domain is a trusted domain, there is no Packet Falsification 225 within the SRv6 domain. 227 As the packets from outside of SRv6 domain cannot be trusted, an 228 Integrity Verification policy is typically deployed at the external 229 interfaces of the ingress SRv6 routers in order to verify the 230 incoming packets (i.e., from outside of SRv6 domain [RFC8986]). 231 Also, the packets with SRH sent form hosts within the SRv6 domain 232 should be verified in order to prevent the falsification between the 233 host and the ingress router. [RFC8986]. 235 o Threats: Packet Falsification 237 o Solutions: The packets from outside can not be trusted, so 238 Integrity Verification policy should be deployed at the external 239 interfaces by using , e.g., IPSec [RFC4301] (AH [RFC4302], ESP 241 [RFC4303] ) or HMAC [RFC2104]. AH [RFC4302], ESP [RFC4303] and 242 HMAC [RFC2104] can provide Integrity Verification for packets, 243 while the ESP can encrypt the payload in order to provide higher 244 security. However, it has been noted that the AH and ESP are not 245 directly applicable in order to reduce the vulnerabilities of SRv6 246 due to the presence of mutable fields in the SRH. In order to 247 solve this problem, [RFC8754] defines a mechanism in order to 248 carry HMAC TLV in the SRH so to verify the integrity of packets 249 including the SRH fields. The HMAC TLV is usually processed based 250 on the local policy, only at the ingress router. Within the SRv6 251 domain, the packets are trusted, so HMAC TLV is typically ignored. 252 In other words, the segment list is mutable within the SRv6 domain 253 but cannot be changed before processing the HMAC TLV. 255 o Conclusions: There is no Packet Falsification within a trusted 256 SRv6 domain. Integrity Verification policy like HMAC processing 257 should be deployed at the external interfaces of the ingress SRv6 258 routers filtering SRH packets from outside the trusted domain and 259 SRH packets from hosts within the SRv6 domain. 261 o Gaps: IPsec cannot provide verification for SRH. 263 +-----------------------------------------------------------------+ 264 |IPv6 Header | SRH | AH| Payload | 265 +-----------------------------------------------------------------+ 267 |--Auth Scope--|HMAC |---------------Auth Scope-------------------| 269 Figure 3: Transport Mode AH and HMAC for SRv6 packets 271 +-----------------------------------------------------------------+ 272 |New IPv6 Header|SRH | AH |IPv6 Header|SRH|Payload | 273 +-----------------------------------------------------------------+ 274 |--Auth Scope---|HMAC|---------------Auth Scope-------------------| 276 Figure 4: Tunnel Mode AH and HMAC for SRv6 packets 278 4.3. Identity Spoofing in SRv6 Networks 280 The same as for Packet Falsification, there is no Identity Spoofing 281 possible within the boundaries of a SRv6 trusted domain where all 282 nodes are under control of the same administrative organization. 284 Authentication policy should be deployed at the external interfaces 285 of the ingress SRv6 routers in order to validate the packets from 286 outside of SRv6 domain [RFC8986]. Also, the packets with SRH sent 287 form hosts inside the SRv6 domain should be validated in order to 288 prevent the Identity Spoofing [RFC8986]. 290 o Threats: Identity Spoofing 292 o Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC 293 [RFC2104] can be used for Authentication. AH, ESP and HMAC can 294 provide Authentication of source node, while the ESP can encrypt 295 the payload in order to provide higher security. Same as section 296 3.2. 298 o Conclusion: There is no Identity Spoofing within a trusted SRv6 299 domain. Identity Spoofing policy should be deployed on the 300 external interfaces of the ingress SRv6 routers for the packets 301 from outside and the packets with SRH from hosts within the SRv6 302 domain. 304 o Gaps: TBA 306 4.4. Packet Replay in SRv6 Networks 308 There are no new Packet Replay threat brought by SRH. ESP can be 309 applied to SRv6 in order to prevent Packet replay attacks. 311 o Threats: Packet Replay 313 o Solutions: ESP [RFC4303] can be used to prevent Replay Attacks. 315 o Conclusion: There are no new Packet Replay threat brought by SRH. 316 ESP can be applied to SRv6 in order to prevent Packet replay 317 attacks. 319 o Gaps: TBD 321 4.5. DOS/DDOS in SRv6 Networks 323 The generation of ICMPv6 error messages may be used in order to 324 attempt DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) 325 attacks by sending an error-causing destination address or SRH in 326 back-to-back packets [RFC8754]. An implementation that correctly 327 follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 328 rate-limiting mechanism also in the case of packets with an SRH. 330 o Threats: DOS/DDOS 332 o Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443] 333 o Conclusions: There are no DOS/DDOS threats within SRv6 domain, the 334 threats come from outside of the domain, and can be prevented by 335 ICMPv6 rate-limiting mechanism. 337 o Gaps: TBD 339 4.6. Malicious Packet Data in SRv6 Networks 341 TBA 343 5. Effects of the above on SRv6 Use Cases 345 This section describes the effects of the above-mentioned 346 vulnerabilities in terms of applicability statement and the use cases 347 given in citation. 349 TBA. 351 6. Security Policy Design 353 The basic security for intra-domain deployment is described in 354 [RFC8986] and the enhanced security mechanism is defined in 355 [RFC8754]. 357 In [RFC8986], additional basic security mechanisms are defined. For 358 easier understanding, a easy example is shown in Figure 5. 360 *************************** ***** 361 * (3) h2 * * * SRv6 domain 362 * \ | * ***** 363 h1-----A-----B-----C-----D-------E-------F 364 / * (2) (2) (2) * \ 365 (1,2,3) * * (1,2) 366 * * 367 *************************** 369 Figure 5: SRv6 Security Policy Design 371 o A-E: SRv6 Routers inside the SRv6 domain, A and E are the edge 372 router, can be called Ingress router instead. 374 o F: Router F outside the SRv6 domain. 376 o h1: A host outside the SRv6 domain connects to router Router A. 378 o h2: A host within SRv6 domain, which connects to the Router D. 380 o (1): Security policy 1: ACL for External Interface. 382 o (2): Security policy 2: ACL for Internal Interfaces. 384 o (3): Security policy 3: Policy for processing HMAC, should be 385 deployed at the ingress nodes. 387 6.1. Basic Security Design 389 6.1.1. ACL for External Interfaces 391 Typically, in any trusted domain, ingress routers are configured with 392 Access Control Lists (ACL) filtering out any packet externally 393 received with SA/DA having a domain internal address. An SRv6 router 394 typically comply with the same rule. 396 A provider would generally do this for its internal address space in 397 order to prevent access to internal addresses and in order to prevent 398 spoofing. The technique is extended to the local SID space. 399 However, in some use cases, Binding SID can be leaked outside of SRv6 400 domain. Detailed ACL should be then configured in order to consider 401 the externally advertised Binding SID. 403 6.1.2. ACL for Internal Interfaces 405 An SRv6 router MUST support an ACL with the following behavior: 407 1. IF (DA == LocalSID) && (SA != internal address or SID space) : 408 2. drop 410 This prevents access to locally instantiated SIDs from outside the 411 operator's infrastructure. Note that this ACL may not be enabled in 412 all cases. For example, specific SIDs can be used to provide 413 resources to devices that are outside of the operator's 414 infrastructure. 416 6.1.3. SID Instantiation 418 As per the End definition [RFC8986], an SRv6 router MUST only 419 implement the End behavior on a local IPv6 address if that address 420 has been explicitly enabled as an SRv6 SID. 422 Packets received with destination address representing a local 423 interface that has not been enabled as an SRv6 SID MUST be dropped. 425 6.2. Enhanced Security Design 427 HMAC [RFC2104] is the enhanced security mechanism for SRv6 as defined 428 in [RFC8754]. HMAC is used for validating the packets with SRH sent 429 from hosts within SRv6 domain. 431 Since the SRH is mutable in computing the Integrity Check Value (ICV) 432 of AH [RFC8754], so AH can not be directly applicable to SRv6 433 packets. HMAC TLV in SRH is used for making sure that the SRH fields 434 like SIDs are not changed along the path. While the intra SRv6 435 domain is trustworthy, so HMAC will be processed at the ingress nodes 436 only, and could be ignore at the other nodes inside the trusted 437 domain. 439 7. Security Considerations 441 TBA 443 8. Acknowledgements 445 Manty thanks to Charles Perkins and Stefano Previdi's valuable 446 comments. 448 9. References 450 9.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 458 of Type 0 Routing Headers in IPv6", RFC 5095, 459 DOI 10.17487/RFC5095, December 2007, 460 . 462 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 463 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 464 May 2017, . 466 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 467 (IPv6) Specification", STD 86, RFC 8200, 468 DOI 10.17487/RFC8200, July 2017, 469 . 471 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 472 Decraene, B., Litkowski, S., and R. Shakir, "Segment 473 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 474 July 2018, . 476 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 477 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 478 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 479 . 481 9.2. Informative References 483 [I-D.ietf-spring-segment-routing-policy] 484 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 485 P. Mattes, "Segment Routing Policy Architecture", draft- 486 ietf-spring-segment-routing-policy-13 (work in progress), 487 May 2021. 489 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 490 Hashing for Message Authentication", RFC 2104, 491 DOI 10.17487/RFC2104, February 1997, 492 . 494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 495 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 496 December 2005, . 498 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 499 DOI 10.17487/RFC4302, December 2005, 500 . 502 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 503 RFC 4303, DOI 10.17487/RFC4303, December 2005, 504 . 506 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 507 Control Message Protocol (ICMPv6) for the Internet 508 Protocol Version 6 (IPv6) Specification", STD 89, 509 RFC 4443, DOI 10.17487/RFC4443, March 2006, 510 . 512 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 513 Co-existence Security Considerations", RFC 4942, 514 DOI 10.17487/RFC4942, September 2007, 515 . 517 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 518 Litkowski, S., Horneffer, M., and R. Shakir, "Source 519 Packet Routing in Networking (SPRING) Problem Statement 520 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 521 2016, . 523 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 524 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 525 (SRv6) Network Programming", RFC 8986, 526 DOI 10.17487/RFC8986, February 2021, 527 . 529 Authors' Addresses 531 Cheng Li 532 Huawei 533 China 535 Email: c.l@huawei.com 537 Zhenbin Li 538 Huawei 539 China 541 Email: lizhenbin@huawei.com 543 Chongfeng Xie 544 China Telecom 545 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 546 Beijing 547 China 549 Email: xiechf@chinatelecom.cn 551 Hui Tian 552 CAICT 553 Beijing 554 China 556 Email: tianhui@caict.ac.cn 557 Jianwei Mao 558 Huawei 559 China 561 Email: MaoJianwei@huawei.com