idnits 2.17.1 draft-li-spring-srv6-security-consideration-04.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 (May 9, 2020) is 1442 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 485, but no explicit reference was found in the text == Unused Reference: 'RFC7855' is defined on line 525, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 Summary: 2 errors (**), 0 flaws (~~), 5 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: November 10, 2020 C. Xie 6 China Telecom 7 H. Tian 8 CAICT 9 J. Mao 10 Huawei 11 May 9, 2020 13 Security Considerations for SRv6 Networks 14 draft-li-spring-srv6-security-consideration-04 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 November 10, 2020. 40 Copyright Notice 42 Copyright (c) 2020 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 231 [I-D.ietf-spring-srv6-network-programming]). Also, the packets with 232 SRH sent form hosts within the SRv6 domain should be verified in 233 order to prevent the falsification between the host and the ingress 234 router. [I-D.ietf-spring-srv6-network-programming]. 236 o Threats: Packet Falsification 238 o Solutions: The packets from outside can not be trusted, so 239 Integrity Verification policy should be deployed at the external 240 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 [I-D.ietf-spring-srv6-network-programming]. 287 Also, the packets with SRH sent form hosts inside the SRv6 domain 288 should be validated in order to prevent the Identity Spoofing 289 [I-D.ietf-spring-srv6-network-programming]. 291 o Threats: Identity Spoofing 293 o Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC 294 [RFC2104] can be used for Authentication. AH, ESP and HMAC can 295 provide Authentication of source node, while the ESP can encrypt 296 the payload in order to provide higher security. Same as section 297 3.2. 299 o Conclusion: There is no Identity Spoofing within a trusted SRv6 300 domain. Identity Spoofing policy should be deployed on the 301 external interfaces of the ingress SRv6 routers for the packets 302 from outside and the packets with SRH from hosts within the SRv6 303 domain. 305 o Gaps: TBA 307 4.4. Packet Replay in SRv6 Networks 309 There are no new Packet Replay threat brought by SRH. ESP can be 310 applied to SRv6 in order to prevent Packet replay attacks. 312 o Threats: Packet Replay 314 o Solutions: ESP [RFC4303] can be used to prevent Replay Attacks. 316 o Conclusion: There are no new Packet Replay threat brought by SRH. 317 ESP can be applied to SRv6 in order to prevent Packet replay 318 attacks. 320 o Gaps: TBD 322 4.5. DOS/DDOS in SRv6 Networks 324 The generation of ICMPv6 error messages may be used in order to 325 attempt DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) 326 attacks by sending an error-causing destination address or SRH in 327 back-to-back packets [RFC8754]. An implementation that correctly 328 follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 329 rate-limiting mechanism also in the case of packets with an SRH. 331 o Threats: DOS/DDOS 333 o Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443] 334 o Conclusions: There are no DOS/DDOS threats within SRv6 domain, the 335 threats come from outside of the domain, and can be prevented by 336 ICMPv6 rate-limiting mechanism. 338 o Gaps: TBD 340 4.6. Malicious Packet Data in SRv6 Networks 342 TBA 344 5. Effects of the above on SRv6 Use Cases 346 This section describes the effects of the above-mentioned 347 vulnerabilities in terms of applicability statement and the use cases 348 given in citation. 350 TBA. 352 6. Security Policy Design 354 The basic security for intra-domain deployment is described in 355 [I-D.ietf-spring-srv6-network-programming] and the enhanced security 356 mechanism is defined in [RFC8754]. 358 In [I-D.ietf-spring-srv6-network-programming], additional basic 359 security mechanisms are defined. For easier understanding, a easy 360 example is shown in Figure 5. 362 *************************** ***** 363 * (3) h2 * * * SRv6 domain 364 * \ | * ***** 365 h1-----A-----B-----C-----D-------E-------F 366 / * (2) (2) (2) * \ 367 (1,2,3) * * (1,2) 368 * * 369 *************************** 371 Figure 5: SRv6 Security Policy Design 373 o A-E: SRv6 Routers inside the SRv6 domain, A and E are the edge 374 router, can be called Ingress router instead. 376 o F: Router F outside the SRv6 domain. 378 o h1: A host outside the SRv6 domain connects to router Router A. 380 o h2: A host within SRv6 domain, which connects to the Router D. 382 o (1): Security policy 1: ACL for External Interface. 384 o (2): Security policy 2: ACL for Internal Interfaces. 386 o (3): Security policy 3: Policy for processing HMAC, should be 387 deployed at the ingress nodes. 389 6.1. Basic Security Design 391 6.1.1. ACL for External Interfaces 393 Typically, in any trusted domain, ingress routers are configured with 394 Access Control Lists (ACL) filtering out any packet externally 395 received with SA/DA having a domain internal address. An SRv6 router 396 typically comply with the same rule. 398 A provider would generally do this for its internal address space in 399 order to prevent access to internal addresses and in order to prevent 400 spoofing. The technique is extended to the local SID space. 401 However, in some use cases, Binding SID can be leaked outside of SRv6 402 domain. Detailed ACL should be then configured in order to consider 403 the externally advertised Binding SID. 405 6.1.2. ACL for Internal Interfaces 407 An SRv6 router MUST support an ACL with the following behavior: 409 1. IF (DA == LocalSID) && (SA != internal address or SID space) : 410 2. drop 412 This prevents access to locally instantiated SIDs from outside the 413 operator's infrastructure. Note that this ACL may not be enabled in 414 all cases. For example, specific SIDs can be used to provide 415 resources to devices that are outside of the operator's 416 infrastructure. 418 6.1.3. SID Instantiation 420 As per the End definition [I-D.ietf-spring-srv6-network-programming], 421 an SRv6 router MUST only implement the End behavior on a local IPv6 422 address if that address has been explicitly enabled as an SRv6 SID. 424 Packets received with destination address representing a local 425 interface that has not been enabled as an SRv6 SID MUST be dropped. 427 6.2. Enhanced Security Design 429 HMAC [RFC2104] is the enhanced security mechanism for SRv6 as defined 430 in [RFC8754]. HMAC is used for validating the packets with SRH sent 431 from hosts within SRv6 domain. 433 Since the SRH is mutable in computing the Integrity Check Value (ICV) 434 of AH [RFC8754], so AH can not be directly applicable to SRv6 435 packets. HMAC TLV in SRH is used for making sure that the SRH fields 436 like SIDs are not changed along the path. While the intra SRv6 437 domain is trustworthy, so HMAC will be processed at the ingress nodes 438 only, and could be ignore at the other nodes inside the trusted 439 domain. 441 7. Security Considerations 443 TBA 445 8. Acknowledgements 447 Manty thanks to Charles Perkins and Stefano Previdi's valuable 448 comments. 450 9. References 452 9.1. Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, 456 DOI 10.17487/RFC2119, March 1997, 457 . 459 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 460 of Type 0 Routing Headers in IPv6", RFC 5095, 461 DOI 10.17487/RFC5095, December 2007, 462 . 464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 466 May 2017, . 468 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 469 (IPv6) Specification", STD 86, RFC 8200, 470 DOI 10.17487/RFC8200, July 2017, 471 . 473 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 474 Decraene, B., Litkowski, S., and R. Shakir, "Segment 475 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 476 July 2018, . 478 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 479 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 480 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 481 . 483 9.2. Informative References 485 [I-D.ietf-spring-segment-routing-policy] 486 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 487 P. Mattes, "Segment Routing Policy Architecture", draft- 488 ietf-spring-segment-routing-policy-07 (work in progress), 489 May 2020. 491 [I-D.ietf-spring-srv6-network-programming] 492 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 493 Matsushima, S., and Z. Li, "SRv6 Network Programming", 494 draft-ietf-spring-srv6-network-programming-15 (work in 495 progress), March 2020. 497 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 498 Hashing for Message Authentication", RFC 2104, 499 DOI 10.17487/RFC2104, February 1997, 500 . 502 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 503 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 504 December 2005, . 506 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 507 DOI 10.17487/RFC4302, December 2005, 508 . 510 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 511 RFC 4303, DOI 10.17487/RFC4303, December 2005, 512 . 514 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 515 Control Message Protocol (ICMPv6) for the Internet 516 Protocol Version 6 (IPv6) Specification", STD 89, 517 RFC 4443, DOI 10.17487/RFC4443, March 2006, 518 . 520 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 521 Co-existence Security Considerations", RFC 4942, 522 DOI 10.17487/RFC4942, September 2007, 523 . 525 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 526 Litkowski, S., Horneffer, M., and R. Shakir, "Source 527 Packet Routing in Networking (SPRING) Problem Statement 528 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 529 2016, . 531 Authors' Addresses 533 Cheng Li 534 Huawei 535 China 537 Email: ChengLi13@huawei.com 539 Zhenbin Li 540 Huawei 541 China 543 Email: lizhenbin@huawei.com 545 Chongfeng Xie 546 China Telecom 547 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 548 Beijing 549 China 551 Email: xiechf.bri@chinatelecom.cn 553 Hui Tian 554 CAICT 555 Beijing 556 China 558 Email: tianhui@caict.ac.cn 559 Jianwei Mao 560 Huawei 561 China 563 Email: MaoJianwei@huawei.com