idnits 2.17.1 draft-ietf-mpls-opportunistic-encrypt-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2017) is 2584 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5869 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track S. Farrell 5 Expires: September 29, 2017 Trinity College Dublin 6 March 28, 2017 8 Opportunistic Security in MPLS Networks 9 draft-ietf-mpls-opportunistic-encrypt-03 11 Abstract 13 This document describes a way to apply opportunistic security between 14 adjacent nodes on an MPLS Label Switched Path (LSP) or between end 15 points of an LSP. It explains how keys may be agreed to enable 16 encryption, and how key identifiers are exchanged in encrypted MPLS 17 packets. Finally, this document describes the applicability of this 18 approach to opportunistic security in MPLS networks with an 19 indication of the level of improved security as well as the continued 20 vulnerabilities. 22 This document does not describe security for MPLS control plane 23 protocols. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 29, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Experimental Status . . . . . . . . . . . . . . . . . . . 4 61 1.2. Existing Security Tools for MPLS Data . . . . . . . . . . 5 62 1.2.1. Payload Encryption . . . . . . . . . . . . . . . . . 6 63 1.2.2. Link Layer Security . . . . . . . . . . . . . . . . . 6 64 1.2.3. Encryption on Pseudowires . . . . . . . . . . . . . . 7 65 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2. Principles of Opportunistic Security . . . . . . . . . . . . 7 67 2.1. Why Do We Need Opportunistic Security? . . . . . . . . . 7 68 2.2. Opportunistic Security at 10,000ft . . . . . . . . . . . 9 69 2.3. What about a Man-in-the-Middle? . . . . . . . . . . . . . 10 70 2.4. OS in MPLS Overview . . . . . . . . . . . . . . . . . . . 11 71 3. MPLS Packet Encryption . . . . . . . . . . . . . . . . . . . 13 72 3.1. MPLS Encryption Label . . . . . . . . . . . . . . . . . . 16 73 3.2. Control Word . . . . . . . . . . . . . . . . . . . . . . 17 74 3.3. Considerations for ECMP . . . . . . . . . . . . . . . . . 18 75 3.4. Backward Compatibility . . . . . . . . . . . . . . . . . 19 76 3.5. MTU Considerations . . . . . . . . . . . . . . . . . . . 19 77 3.6. Recursive Encryption . . . . . . . . . . . . . . . . . . 20 78 4. Key Exchange For Opportunistic Security in MPLS . . . . . . . 20 79 4.1. Initiating MPLS-OS . . . . . . . . . . . . . . . . . . . 21 80 4.2. MPLS G-ACh Advertisement Protocol for Key Exchange . . . 21 81 4.3. Key Exchange Protocol . . . . . . . . . . . . . . . . . . 22 82 4.3.1. Communication Channels . . . . . . . . . . . . . . . 22 83 4.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 22 84 4.3.3. Key Exchange TLV . . . . . . . . . . . . . . . . . . 23 85 4.3.4. Encoding Errors . . . . . . . . . . . . . . . . . . . 27 86 4.4. Indicating the Return Path . . . . . . . . . . . . . . . 27 87 4.5. Protecting the Key Exchange Protocol Messages . . . . . . 28 88 5. Applicability of MPLS Opportunistic Security . . . . . . . . 28 89 5.1. Tunnel MPLS Packets . . . . . . . . . . . . . . . . . . . 30 90 5.2. Penultimate Hop Popping . . . . . . . . . . . . . . . . . 31 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 92 6.1. Security Improvements . . . . . . . . . . . . . . . . . . 32 93 6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 32 94 6.3. Continued Vulnerabilities . . . . . . . . . . . . . . . . 32 95 6.4. New Security Considerations . . . . . . . . . . . . . . . 32 96 7. Manageability Considerations . . . . . . . . . . . . . . . . 33 97 7.1. MITM Detection . . . . . . . . . . . . . . . . . . . . . 33 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 99 8.1. GAP Key Exchange TLV . . . . . . . . . . . . . . . . . . 34 100 8.2. Key Derivation Functions and Symmetric Algorithms . . . . 34 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 104 10.2. Informative References . . . . . . . . . . . . . . . . . 36 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 107 1. Introduction 109 MPLS is an established data plane protocol in the Internet. It is 110 found in the majority of core service provider networks and most end- 111 to-end traffic in the Internet will be carried over MPLS at some 112 point in its path. The MPLS data plane is defined by [RFC3031] and 113 [RFC3032]. 115 Data security (e.g., confidentiality) in MPLS has previously relied 116 on just two features: 118 o Physical isolation of MPLS networks has been used to ensure that 119 interception of MPLS traffic was not possible. 121 o Higher-layer protocol security (such as IPsec [RFC4302], 122 [RFC4303]) has been used whenever a particular flow has determined 123 that security was desirable. 125 These features have a number of significant vulnerabilities: 127 o Networks are increasingly easily compromised physically such that 128 "taps" may be inserted in links between routers [RFC7258]. 130 o Routers may be compromised either in their entirety or through the 131 management/control plane (or misconfiguration). This may result 132 in packets being diverted to transit inspection points on their 133 way to their destination. 135 o The increased support for point-to-multipoint (P2MP) MPLS means 136 that routers can easily be configured (or misconfigured) to make a 137 copy of data and to send it to an additional destination. 139 o End-to-end payload security may be hard to manage and operate and 140 is not turned on by default by many users. While this form of 141 security is desirable, the network should also improve the 142 security of data transfer that it offers. 144 The concept of Opportunistic Security (OS) is introduced in 145 [RFC7435]. This document describes an OS design pattern for the MPLS 146 data plane. It shows what part of an MPLS packet may be encrypted 147 and provides a way to indicate that the packet is encrypted as well 148 as a way to carry a key identifier with each packet. 150 MPLS opportunistic security can be achieved between adjacent Label 151 Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and 152 also between end points of an LSP. 154 This document also provides a mechanism for keys to be exchanged to 155 facilitate encryption. Finally, this document describes the improved 156 security level achieved with OS in MPLS networks and lists the 157 continued vulnerabilities. 159 This document does not describe security for MPLS control plane 160 protocols. 162 Please note that a discussion of the applicability of MPLS 163 opportunistic security is provided in Section 5. 165 1.1. Experimental Status 167 This document is presented as experimental. Before advancing this 168 work on the IETF's Standards Track, it is important to get experience 169 of the practicality of the mechanisms described. In particular 170 whether it is practical to achieve these mechanisms in existing 171 hardware, and whether the imposition of additional MPLS labels is 172 acceptable in the MPLS data plane. Additionally, the consequences of 173 the reduced MTU caused by inserting the additional MPLS label and 174 control word as well as the fact that the encrypted packet will be 175 larger than the unencrypted packet need to be investigated. 177 It is currently believed that MPLS-OS can be deployed progressively 178 without the need to negotiate capabilities outside the key exchange 179 mechanisms described here. This means that no specific walled garden 180 needs to be described in this document. 182 Experimentation and further investigation of the security aspects of 183 these mechanisms are encouraged especially with regard to mitigation 184 of man-in-the-middle attacks. Consideration of the impact of MPLS-OS 185 on MPLS Operations, Administration, and Management (OAM) and other 186 MPLS management techniques also needs further exploration. 188 The key functions of MPLS-OS described in Section 2.4 are based on an 189 initial set of choices that may be adequate for MPLS-OS. However, 190 security knowledge is evolving and it may be advisable to "upgrade", 191 for example to Elliptic Curve Diffie-Hellman (ECDH) [RFC6239], using 192 NIST curves or new curves (such as 25519). Furthermore, alternative 193 key derivation functions could be chosen, or symmetric cipher mode 194 could be used. Note that changing to a symmetric cipher that is 195 faster in software, but less likely to be available in hardware would 196 not be a good change. 198 Section 2.4 also describes the frequency with which keys should be 199 changed. The values described here should be subject to more 200 research and experimentation since key change is fundamental to the 201 actual security of the encryption. 203 Section 4.3.3 defines the input parameters to the key derivation 204 function and includes the LSP identifier. This identifier is only 205 needed if the scope of the key is per LSP. This document is written 206 on that assumption because of the need to rotate the key after a 207 certain number of packets have been transmitted. However, this could 208 be the subject of some investigation since dropping the LSP 209 identifier would simplify the TLV and the computation. It would also 210 address the issue of identifying the LSP in the case of LDP. 212 Section 4.3.3 also specifies that the salt is not used. Further 213 investigation is needed to see whether this input parameter would add 214 value for MPLS-OS. 216 Note that this experiment uses a special-purpose MPLS label 217 [RFC7274]. Because this document is experimental it makes use of an 218 extended special- purpose label from the experimental range. If this 219 work is moved to be published on the standards track, it will be 220 possible to achieve the same function using a simple special-purpose 221 label rather than an extended special-purpose label. 223 1.2. Existing Security Tools for MPLS Data 225 Several tools already exist for securing data exchanged over an MPLS 226 data plane. These mechansisms do not provide identical function to 227 MPLS-OS, but part of the decission about the value of MPLS-OS must 228 include an analysis of these other approaches to determine whether 229 they are good enough and whether the cost and complexity of MPLS-OS 230 is justified. 232 As will be seen from the following sections, the existing tools and 233 techniques provide a powerful set of encryption mechanisms that can 234 be very effective in specfic environments. Each has its plusses and 235 minusses, and some need further development to achieve a lower level 236 of configuration. The biggest consideration, however, is whether the 237 encryption offered can be achieved to the same level for all payloads 238 and for all link types. 240 1.2.1. Payload Encryption 242 One way to secure data sent over an MPLS network is to encrypt it 243 before it is passed to the MPLS layer. 245 Applications can take responsibility for encrypting their own data 246 using techniques such as Transport Layer Security (TLS) [RFC5246], 247 and this is the ideal solution for the protection of user data. 248 However, many applications and many users do not take these 249 precautions. Furthermore, solutions like TLS leave some metadata 250 (such as the destination IP address) exposed as the packets transit 251 the IP network. 253 IPsec [RFC4302], [RFC4303]) can be applied end-to-end (between host 254 systems) or edge-to-edge (between routers). Applied end-to-end, 255 IPsec exhibits many of the same properties as TLS. Applied edge-to- 256 edge it allows a network operator to encrypt a stream of IP packets 257 before they are handed off to the MPLS network. However, not every 258 packet carried by an MPLS network is an IP packet: an MPLS LSP may 259 carry other traffic as well, such as in the case of a pseudowire. 260 Furthermore, IPsec has historically placed a heavy "full-mesh" 261 configuration burden on implmenetations although this is now ease 262 with the introduction of the NULL Authentication Method in the 263 Internet Key Exchange Protocol Version 2 [RFC7619] allows for 264 opportunistic key exchange to support IPsec. 266 1.2.2. Link Layer Security 268 Another approach to securing data sent over an MPLS network is to 269 encrypt it as it passes over the lower layer links. That is, each 270 router along the LSP uses layer two encryption on the link between it 271 and its next hop neighbour. 273 MACsec [IEEE-802.1AE] provides a mechanism to encrypt Ethernet frames 274 travelling over individual Ethernet segments or across Ethernet 275 networks. As such it is a valuable solution to protecting MPLS 276 packets flowiing between routers that are connected by Ethernet. 278 Where MPLS routers are connected by other link layer types, or 279 directly over layer one, a possible approach is to encpsulate each 280 packet in an Ethernet frame and apply MACsec before transmission. 282 An argument against link layer security is that it is hop-by-hop. 283 The MPLS data plane is not able to verify end-to-end encryption and 284 there is a chain of trust (that could also use the control plane) 285 that packets are forwarded encrypted and that routers have not 286 intercpted packets that must necessarily be decrypted at each hop. 288 Furthermore there s currently no standard for opportunistic security 289 with MACsec meaning that keys must be configured or exchanged by some 290 other means. 292 1.2.3. Encryption on Pseudowires 294 Some traffic sent over an MPLS network will be in the form of a 295 pseudowire [RFC3985]. This a "layer inversion" where lower layer 296 traffic is encoded in an MPLS packet to be carried over an MPLS 297 network. 299 A large amount of traffic carried over MPLS pseudowires is Ethernet. 300 In this case, the pseudowire provides a virtual Ethernet segment 301 between two Ethernet switches that can consider themselves directly 302 attached in the Ethernet network, and that means they can run MACsec 303 over the adjacency (i.e., over the pseudowire). However (of course), 304 this approach is only valid for Ethernet connectivity and does not 305 hold for pseudowires that carry other data types such as Time 306 Division Multiplexing (TDM). 308 1.3. Notation 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 312 document are to be interpreted as described in RFC 2119 [RFC2119]. 314 2. Principles of Opportunistic Security 316 This section provides an overview of opportunistic security in the 317 context of MPLS. Readers are advised to familiarize themselves with 318 some of the attack vectors discussed in [RFC7258] and with the more 319 general description of opportunistic security as described in 320 [RFC7435]. The text here is intended for the consumption of MPLS 321 experts who may not have a background in security: it is, therefore, 322 tutorial and simplistic in nature. 324 2.1. Why Do We Need Opportunistic Security? 326 To introduce this discussion we start from a basic view of how 327 encryption is typically used in IETF protocols. 329 Say we have two protocol entities, Alice and Bob, and they would like 330 some message "M" sent from Alice to Bob to have confidentiality. 331 Alice needs to send M encrypted with algorithm "E" under some 332 symmetric (e.g., AES) key, "k". Thus Alice wants to send Bob 333 "E(k,M)", but for Bob to be able to understand (i.e., decrypt) the 334 message Alice and Bob both need to agree on the key that will be 335 used: this is called their shared secret. 337 In many IETF protocols, such as the common usage of Transport Layer 338 Security (TLS), S/MIME Cryptographic Message Syntax (CMS), or Pretty 339 Good Privacy (PGP), Alice simply invents a random key "k" and then 340 encrypts that under Bob's public key "Pub-b" and sends Bob both 341 E(Pub-b,k) and E(k,M). (There are lots of other details and other 342 options for how this can be handled, but we ignore those for now.) 343 In such cases, before Alice can send "E(k,M)", she needs to acquire 344 Bob's public key and she needs to be certain that it really is Bob's 345 public key and not Charlie's. That knowledge requires some long-term 346 key management, which is often done using a Public Key Infrastructure 347 (PKI) so that Alice actually stores the public key (Pub-ca) of a 348 Certification Authority (CA), and Bob gets his public key (Pub-b) 349 "certified" by the CA, which means the CA creates a digitally signed 350 data structure "Cert(Pub-ca,Pub-b)". The crucial thing is that 351 Alice, Bob, and a CA need to co-ordinate before Alice and Bob can 352 agree on a key "k", and that process imposes a key-management burden. 354 Doing such key management is clearly quite possible, since TLS and 355 IPsec and other well-deployed technologies depend on it. But, in the 356 case of HTTP/TLS on the public web, we see that only roughly 30% of 357 web sites actually take on this burden, even though the software 358 required is ubiquitous and, at least for 2nd level DNS domains in 359 .com for example, there are CAs who offer free domain-validated 360 certificates. While some of the 70% who don't set up certificates 361 might not actually want confidentiality, there are certainly some who 362 would and arguably many that would benefit from confidentiality, if 363 it just happened out of the box, without an administrator having to 364 do anything. And there are also arguably many other protocols where 365 the same is true. 367 An alternative to the PKI is manual configuration of keys at Alice 368 and Bob. Manual configuration is used in a large number of cases in 369 deployments, however it has a set of issues that make it problematic. 370 These issues include: 372 o the scale of configuration that is needed for a full set of 373 Security Associations (SAs) between all communicating parties 375 o the likelihood of configuration errors 377 o the security vulnerabilities associated with manual keying and 378 unsecured exchange of keys. 380 Opportunistic Security (OS) is a protocol design pattern to achieve 381 encryption between Alice and Bob without requiring key-management 382 through CAs, and without relying on manual configuration of keys. 384 2.2. Opportunistic Security at 10,000ft 386 Instead of the "key transport" mechanisms described in Section 2.1, 387 OS aims to use "key agreement". With key transport, Alice invents 388 "k" and safely transports it to Bob encrypted with Bob's public key 389 as "E(Pub-b,k)". With key agreement, both Alice and Bob contribute 390 to calculating "k" as follows. 392 Assume that Alice and Bob are using some protocol where they can 393 exchange a few messages in order to agree on the key "k" to use. 394 With a Diffie-Hellman key agreement ("D-H") both Alice and Bob have 395 public and private values, where the private value can be randomly 396 generated, perhaps even once per message "M". They swap the public 397 values, and can then, thanks to the "magic" of Diffie-Hellman, derive 398 a key "k" that nobody else can know. 400 In this way Alice sends Bob "Pub-a" and Bob sends Alice "Pub-b" and 401 at that point both of them can safely calculate a shared secret "k" 402 from those values. And after that Alice can send Bob "E(k,M)". 404 From here on, we change the terminology slightly and refer to Alice 405 as the initiator, with private key "i" and Bob as the recipient, with 406 private key "r" so that our notation is closer to that used in 407 IPsec's Internet Key Exchange Protocol (IKE) on which we model our 408 use of OS. 410 D-H works as follows: Let "p" be well-known large prime number that 411 we use for all modular arithmetic (meaning that "a^b" is actually 412 "(a^b) mod p"), and let "g" be another well-known value (called a 413 generator for the group determined by "p"). Also let Alice and Bob's 414 private values be "i" and "r" respectively. Now, if Alice sends Bob 415 "g^i" as her public value, and Bob similarly sends Alice "g^r" then 416 both of them can easily calculate "g^(i*r)" or "g^ir" but nobody else 417 can, since calculating "x" when only given "g^x" is a computationally 418 hard problem for any "x". Once both Alice and Bob have the value 419 "g^ir" in hand, they can easily derive a value "k" from that using 420 any of a number of well-known key derivation functions (KDFs) such 421 that k = f(g^ir) for a KDF "f". 423 As you can see from the above, Alice and Bob do not need to pre- 424 arrange anything other than "g", "p" and "f", and those can be public 425 information that is used by everyone everywhere (or at least by all 426 participants in a particular deployment). Yet, Alice and Bob have 427 managed to derive a common and private value for a key "k" that they 428 can use to encrypt (and decrypt) "M". 430 This method of using the OS pattern provides strong confidentiality 431 and can be built into any protocol that allows Alice and Bob to 432 occasionally exchange public values. 434 There are also additional advantages to key agreement when compared 435 to key transport. The most important of those is that with key 436 agreement we can easily ensure that k has a property called Perfect 437 Forward Secrecy (PFS). That means that an attacker has to separately 438 attack each key k. In contrast, if we use the key transport 439 approach, then an attacker who somehow accesses Bob's private key 440 "Priv-b" can record lots of traffic and later go back and decrypt all 441 the "E(Pub-b,k)" values that all Alices have ever sent to Bob. With 442 key agreement as described, since both Alice and Bob contribute to 443 the value k, and since Alice and Bob will typically periodically 444 generate new private values i and r (perhaps even for every single 445 M), compromise of one party is far less catastrophic, and an attacker 446 who gets access to one private value gets far less benefit. 448 2.3. What about a Man-in-the-Middle? 450 OS as described so far is vulnerable to Man-in-the-Middle (MITM) 451 attacks. The problem is that Alice does not know that it was really 452 Bob's public value that she received; it could have been Charlie's 453 public value sent by Charlie. And Charlie could also send Bob his 454 public value pretending to be Alice. Now Charlie can share a key 455 with Alice and a key with Bob so that Charlie can sit between Alice 456 and Bob decrypting what he gets from Alice and then re-encrypting it 457 to send to Bob. Neither Alice nor Bob can tell that Charlie is 458 present as a "Man-in-the-Middle" and both Alice and Bob think they 459 are safely exchanging encrypted messages. 461 A MITM attack like that is bad and making a protocol proof against 462 such attacks comes at the cost of the key-management burden described 463 in Section 2.1. Most IETF protocols to date require that such MITM 464 attacks not be feasible. 466 However, despite its potential vulnerability to MITM attacks, OS 467 still has value. This value arises because of the difficulty of 468 inserting a MITM actor, and the cost of processing for the MITM in 469 the case of a very large number of relationships. In particular, 470 where the choice is between no encryption (as has been the case for 471 MPLS to date) and OS, it is clear that using OS offers better 472 (although not the best) security. 474 Consider the case where an attacker taps a link on the path between 475 Alice and Bob. In this case, the attacker can capture every packet 476 between the two parties, and if there is no encryption, can read 477 every message. Furthermore, consider that the attacker could tap a 478 fiber in the core of the network and so capture every packet between 479 a large number of Alices and their corresponding Bobs. In these 480 cases, Charlie can operate as a "passive MITM" since all he has to do 481 is watch the packets. 483 With OS in use, Charlie is forced to be an "active MITM". That is, 484 he must engage in the D-H exchange between each pair of Alices and 485 Bobs, and he must must decrypt and encrypt each packet he wants to 486 inspect. This imposes a higher cost and is especially burdensome if 487 he is attempting to do it in parallel for lots of Alice/Bob pairs 488 using lots of different keys and communication sessions. 490 Furthermore, when D-H is in use for OS, management tools can be used 491 to detect the presence of Charlie as a MITM. This is because Charlie 492 has to agree one key "kA" with Alice, and a different key "kB" with 493 Bob. As far as we know, Charlie cannot arrange that kA equals kB 494 because both sides contribute to the key value in the D-H key 495 agreement. That means that if Alice and Bob can check with each 496 other what value of "k" they are using and the values do not match, 497 then they know that Charlie is present. What is more, Alice and Bob 498 can make this check on the value of "k" for any of the "E(k,M)" they 499 ever exchanged. 501 Thus, in the case of a fiber tap where many Alice/Bob pairs are being 502 monitored, it only takes one Alice and Bob to detect the MITM attack 503 for all Alice/Bob pairs to be alerted to the problem. In such cases 504 the cost of detection for Charlie may be even greater than the cost 505 of performing the MITM attack. 507 Hence we conclude that OS can have considerable value when used in 508 MPLS networks. 510 2.4. OS in MPLS Overview 512 The basic requirement for MPLS-OS is that we want to provide a way 513 for two MPLS nodes to do a key exchange and to derive a session key 514 from that exchange to use in MPLS packet encryption. 516 To do that we use a Diffie-Hellman key exchange as outlined in 517 Section 2.2. We model this on IKE [RFC7296] using essentially the 518 same parameters. We feed the shared Diffie-Hellman value, which is 519 g^ir, into a standard KDF that also takes as input an LSP identifier 520 (LSP ID) together with the sending and receiving LSR IDs - where the 521 sending LSR is the point of encryption and the receiving LSR is the 522 point of decryption such that the pair of LSRs define the SA. These 523 additional inputs are used to ensure that we end up with different 524 keys on an LSP even if the same g^i and g^r values are re-used, 525 however it is RECOMMENDED that fresh values of i and r are used each 526 time an LSP is instantiated and for each new LSP [RFC4086]. The KDF 527 to be used here is as defined in [RFC5869]. 529 The D-H values used in MPLS-OS MUST be of at least 2048-bits. 530 Implementations MUST support the 2048-bit modular exponentiation 531 (MODP) group from Section 3 of [RFC3526] and SHOULD support the 532 larger MODP groups from [RFC3526]. 534 This document also defines the mechanism used to derive an identifier 535 for a key (the key-id) from the shared Diffie-Hellman value, which is 536 also based on the KDF output. The key will be used with a symmetric 537 encryption algorithm, such as AEAD_AES_GCM_128 (the default, 538 following [RFC5116]). 540 As with any symmetric block cipher, one should not use the same key 541 for too long. The nonce defined for these keys is derived using a 96 542 bit counter incremented by one for each encrypted packet. It is 543 critical for security that nonce values MUST NOT be re-used with a 544 given key. (This is an inherent issue with how AES-GCM or any 545 counter mode achieves high performance.) 547 Accordingly, implementations MUST support mechanisms for key change. 549 To support key change, this document defines a way for two LSRs using 550 a key on an LSP to agree a new key and to switch over to using that 551 key when desired. That means that implementations MUST be able to 552 handle at least two keys (old and new) for a given LSP. Once a new 553 key has been agreed then it should be used for sending packets; once 554 encrypted data packets protected with the new key have been 555 successfully received, the old key SHOULD be discarded. Section 4 556 describes how two LSRs agree keys: to agree a new key two LSRs simply 557 run the same key agreement exchange as s used for initial key 558 exchange, but this time the exchange is protected with the old 559 session key as described in Section 4.5. This process can, of 560 course, be repeated any number of times for the same LSP. It is 561 RECOMMENDED that the key on an LSP be changed at least once every day 562 or every 10^6 packets whichever is sooner, and MUST change keys 563 before encrypting 2^64 packets. 565 In the event of a key agreement exchange or decryption failure, an 566 alarm MUST be raised to the operator. Default (i.e., node-wide) and 567 per-LSP behavior SHOULD be configurable in this case: actions may 568 include reverting to non-encrypted traffic, re-attempting key 569 exchange, or tearing down the LSP. Note that a simple attack on OS 570 is to tamper with key agreement exchange messages or encrypted 571 packets so that OS fails. Such attacks may be intended to cause the 572 LSP to operate without encryption, so an operator should consider 573 this when setting the default behavior for this case. 575 Section 7.1 also discusses a mechanism that allows a pair of LSRs 576 using OS on an LSP to detect that a MITM attack has happened. For 577 this, we simply define a function of the shared secret, which can be 578 logged and later compared. Note that logging a sample of these 579 "witness" values will likely be sufficient to detect pervasive MITM 580 attacks [RFC7258]. As with the key-id, we base this on the same KDF 581 output. 583 We might have considered deriving the witness value from a separate 584 invocation of the KDF that does not depend on the LSP-specific 585 inputs. The benefit from that would be that the same MITM-detection 586 infrastructure could be used for many protocols. However, that would 587 require standardizing a generic D-H MITM-detection protocol, or at 588 least formats, in order to be useful. If such a generic MITM- 589 detection approach was used we would also need to consider what 590 additional information needed to be logged with the witness value so 591 that comparisons could easily be made at scale, but without creating 592 new privacy-invasive meta-data. That last is not much of an issue 593 for MPLS-OS, but could be a concern if the same approach were to be 594 used in some other protocols. The generic MITM-detection approach, 595 is left for future study. 597 An additional discussion of the applicability of MPLS-OS is found in 598 Section 5. 600 3. MPLS Packet Encryption 602 MPLS packets are encrypted according to the mechanisms described in 603 this section. 605 When an MPLS packet is encrypted, this is indicated by the insertion 606 of a new extended special-purpose label [RFC7274] in the label stack. 607 This is referred to as the MPLS Encryption Label (MEL). The format 608 of the MEL is described in Section 3.1. 610 The MEL MUST have the bottom of stack bit (the S bit) set and MUST be 611 followed by a pseudowire control word [RFC4385]. The format of the 612 control word is described in Section 3.2. 614 The remainder of the MPLS packet is encrypted and cannot be parsed 615 without decryption. It needs to be understood, therefore, that the 616 phrase "bottom of stack" refers to the parsable label stack (i.e., 617 those label stack entries that have not been encrypted) and does not 618 indicate the full label stack of the unencrypted packet. Figure 1 619 and Figure 2 should make this point clear. 621 Implementations MUST support the AEAD_AES_GCM_128 encryption 622 algorithm, as specified in Section 5.1 of [RFC5116], which is the 623 default algorithm as described in Section 4.3 of this document. 625 Note that it is critical that a new nonce is used for every 626 encryption. The nonce is an implicit packet counter. The initial 627 nonce value is derived from the HMAC-based Key Derivation Function 628 (HKDF) output (see Section 4.3.3) at key agreement time and the 629 counter is incremented by one for each packet encrypted on the 630 sending side and by one for each packet successfully decrypted on the 631 receiver side. 633 Although the nonce is not transmitted with the packets, a 16-bit 634 counter carried in the control Word indicates the nonce value modulo 635 65536. This feature allows a receiving node to quickly spot that a 636 packet has been dropped and to resynchronize its own counter in order 637 to be able to continue to decrypt received packets. In the event 638 that the counter cannot be resynchronized or that more than 65536 639 packet are lost in one batch the receiver will encounter a decryption 640 error. In this case the receiver may report a general decryption 641 error or may attempt to resynchronize by advancing its own counter in 642 units of 65536 according to the modulo value in the received packet. 643 Note that incrementing the counter in order to test for decryption 644 failure does generate a potential Denial of Service (DoS) if, e.g., 645 an attacker decrements the nonce-mod-65536 value. Implementations 646 that do such tests SHOULD maintain a small maximum window size beyond 647 which they will cease attempting to decrypt. It could be that 648 throwing an error might be the more effective response if the packet 649 loss rates are expected to be low enough. 651 It should also be noted that the output from encryption will be 16 652 octets longer than the input. 654 The bottom of stack bit is set in the MEL to stop implementations 655 continuing to search down the label stack (which is encrypted) and 656 attempting to use the data as though it was a valid label stack. The 657 control word is needed because many implementations that find the 658 bottom of stack expect the next bytes to be a control word or 659 protocol indicator. 661 The position of the MEL and control word depend on whether hop-by-hop 662 or end-to-end encryption is being applied. 664 Figure 1 illustrates the format of an example MPLS packet before and 665 after hop-by-hop encryption. The left hand part of the figure shows 666 a normal MPLS packet with a label stack and payload. The bottom 667 label in the stack has the S bit set. The payload is the data 668 carried by the MPLS packet (such as IP) and may be prefixed by a 669 control word. 671 The right hand part of Figure 1 shows the same packet after it has 672 been encrypted. The top of stack is a label with value 15 that 673 indicates that an extended special-purpose label follows. Next comes 674 the MEL with the S bit set. The label value of the MEL is from the 675 experimental range 240-255 and is selected according to the scope of 676 the MPLS-OS experiment being run. The MEL is followed by a control 677 word. Everything that follows the control word is the entire 678 original MPLS packet encrypted. 680 ----------- . ----------- 681 | Top Label | . | Label 15 | 682 +-----------+ . +-----------+ 683 | Label | . | MEL S=1 | 684 +-----------+ . +-----------+ 685 | Label S=1 | .| Ctrl Word | 686 +-----------+ +-----------+ 687 | | | | 688 ~ Payload ~ ~ Encrypted ~ 689 | | | | 690 -----------........----------- 692 Figure 1: The Use of the MEL for Hop-by-Hop Encryption 694 Figure 2 illustrates the format of an example MPLS packet before and 695 after end-to-end encryption. The left hand part of the figure shows 696 a normal MPLS packet with a label stack and payload. The bottom 697 label in the stack has the S bit set and the payload may be prefixed 698 by a control word. The right hand part of the figure shows how the 699 top two labels (or however many labels are needed for end-to-end 700 delivery) remain at the top of the label stack. Then follows label 701 15 to indicate that an extended special-purpose label follows, then 702 comes the MEL with S bit set, and a control word. The remainder of 703 the packet is encrypted and contains the rest of the label stack and 704 the payload. 706 ----------- ----------- 707 | Top Label | | Top Label | 708 +-----------+ +-----------+ 709 | Label | | Label | 710 +-----------+. +-----------+ 711 | Label | . | Label 15 | 712 +-----------+ . +-----------+ 713 | Label | . | MEL S=1 | 714 +-----------+ . +-----------+ 715 | Label S=1 | .| Ctrl Word | 716 +-----------+ +-----------+ 717 | | | | 718 ~ Payload ~ ~ Encrypted ~ 719 | | | | 720 -----------........----------- 722 Figure 2: The Use of the MEL for End-to-End Encryption 724 3.1. MPLS Encryption Label 726 The MPLS Encryption Label (MEL) is a normal label stack entry 727 carrying an extended special-purpose label with a value from the 728 experimental range 240-255. The format of the label stack entry is 729 defined in [RFC3032] and shown in Figure 3. 731 0 1 2 3 732 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Label | TC |S| TTL | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Figure 3: Format of the MEL Label Stack Entry 739 Label: The value of MEL for this experiment. Note that no special 740 purpose label value is assigned by IANA and implementations 741 participating in this experiment must agree amongst themselves 742 what value to use. The value MUST be selected from the 743 Experimental range (240-255). 745 TC: For end-to-end encryption, the value of the TC field SHOULD be 746 set to the value of the unencrypted label stack entry that 747 immediately precedes the MEL. In the case of hop-by-hop 748 encryption, the value of the TC SHOULD be copied from the TC of 749 the first encrypted label if there is a label stack present. 750 Otherwise this field SHOULD be set to all zero (0b000). 752 S: MUST be set to one. 754 TTL: SHOULD be set to two to prevent encrypted packets being 755 accidentally forwarded too far beyond the point of intended 756 decryption. Note that setting to zero might cause a receiver to 757 discard the packet when the MEL becomes top of stack, and setting 758 to one might cause the packet to be sent to the slow path when the 759 MEL becomes the top of the stack even though decryption should be 760 a fast-path function. 762 The sending LSR MAY choose different values for the TTL and TC 763 fields if it is known that label 15 or the MEL will not be exposed 764 as the top label at any point along the LSP (for example, by 765 penultimate hop popping - but see Section 5 for a discussion of 766 MPLS tunnels and penultimate hop popping). 768 3.2. Control Word 770 The control word is inserted after the MEL as described in Section 3. 771 The S bit set to one in the MEL and the presence of the control word 772 helps protect against transit nodes that may perform hashing or 773 inspection of the label stack and payload packet headers when 774 forwarding MPLS packets (for example, to enable ECMP). The control 775 word indicates that the payload is not a protocol that can be 776 meaningfully hashed or inspected. 778 The format of the control word is defined in [RFC4385] and shown in 779 Figure 4. 781 0 1 2 3 782 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 |0 0 0 0| Flags |FRG| Length | Sequence Number | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Figure 4: Control Word for Encrypted MPLS 789 Flags: The Flags field is treated as a four-bit number. It contains 790 the key-id that identifies the algorithm and key as established 791 through configuration or dynamic key exchange as described in 792 Section 4. 794 FRG: Must be sent as 0, and ignored on receipt. Fragmentation is 795 not used. 797 Length: MUST be sent as 0, and ignored on receipt. 799 Sequence Number: This field contains the packet counter (nonce) for 800 the encryption algorithm and key currently in use modulo 65536. 801 It can be used by a receiver to quickly check that the value of 802 the nonce being used for decryption is likely to be correct as 803 described in Section 3. 805 3.3. Considerations for ECMP 807 As previously stated, the S bit set in the MEL and the presence of 808 the control word prevent implementations from attempting to use the 809 encrypted MPLS packet and its payload to determine a hash value for 810 uses such as ECMP. However, the resultant label stack shown in 811 Figure 2 will probably not provide sufficient entropy for ECMP 812 purposes. 814 In order to increase the entropy, an implementation that inserts an 815 MEL and control word MAY also insert an Entropy Label Indicator (ELI) 816 and Entropy Label (EL) as defined in [RFC6790] ELI and EL are 817 positioned in the label stack before the MEL as shown in Figure 5. 818 The setting of the fields in the ELI and EL label stack entries are 819 as described in [RFC6790]. 821 The ELI and EL will normally occur immediately before the label 15 822 and MEL pair, but they MAY be placed higher up the label stack. 824 .. ----------- 825 . | Top Label | 826 . +-----------+ 827 . | Label | 828 ----------- . ..+-----------+ 829 | Top Label | . | ELI | 830 +-----------+ . +-----------+ 831 | Label | . | EL | 832 +-----------+. +-----------+ 833 | Label | . | Label 15 | 834 +-----------+ . +-----------+ 835 | Label | . | MEL S=1 | 836 +-----------+ . +-----------+ 837 | Label S=1 | .| Ctrl Word | 838 +-----------+ +-----------+ 839 | | | | 840 ~ Payload ~ ~ Encrypted ~ 841 | | | | 842 -----------........----------- 844 Figure 5: The Use of ELI and EL with MEL 846 3.4. Backward Compatibility 848 Keys and encryption algorithms may be configured manually or 849 exchanged dynamically as described in Section 4. These mechanisms 850 provide a preliminary way to protect against a sender encrypting data 851 that the receiver cannot decrypt. However, misconfiguration may lead 852 to a sender using the MEL when the receiver does not support 853 encryption. 855 When a node finds an unknown label at the top of the label stack it 856 must discard the packet as described in [RFC3031]. Therefore, when a 857 receiver discovers label 15 and does not support extended special- 858 purpose labels it will discard the packet. Similarly when a receiver 859 that supports extended special-purpose labels, but does not support 860 the MEL (i.e., does not support encryption) it will discard the 861 packet. (Note that care must be taken if multiple experiments are 862 being carried out in the same network since a different extended 863 special-purpose label must be used for each experiment.) The net 864 result is that when a sender uses encryption in error, all packets 865 that it sends on the LSP will be discarded by the receiver. Note 866 that in this discussion, "the receiver" may be the next hop if single 867 hop encryption is used, or may be the end of the LSP if end-to-end 868 encryption is used. 870 Transit nodes that are not actively participating in the encryption 871 will not inspect the MEL except potentially as part of an ECMP hash, 872 and it should be noted that the use of Special Purpose Labels in 873 hashing is strongly discouraged (see Section 2.4.5.1 of [RFC7325]). 874 This means that transit nodes will not encounter the MEL during 875 normal packet processing and will not discard packets. 877 3.5. MTU Considerations 879 Adding label 15, the MEL, and the Control Word as described above 880 will reduce the available data size by 12 octets. Furthermore, as 881 described in Section 3, the output of the encryption algorithm is at 882 least 16 octets longer than the input. Therefore, the use of 883 encryption reduces the available MTU by at least 28 octets. Other 884 encryption algorithms may result in even greater reductions in the 885 available MTU. 887 When end-to-end encryption is in use this can be considered by the 888 ingress LSR, however, when single-hop encryption might be used the 889 participating LSRs need to advertise this reduced link MTU so that 890 the packets do not overflow. MPLS packets MUST NOT be fragmented as 891 a result of encryption. 893 3.6. Recursive Encryption 895 The use of MEL and control word described in Section 3 may be applied 896 recursively. That is, the payload of an encrypted MPLS packet may, 897 itself be an encrypted MPLS packet. This may be particularly useful 898 in the case where an MPLS VPN has native MPLS traffic. 900 There are no special considerations except to note that encryption 901 and decryption processing may be burdensome if an LSP and its payload 902 LSP have encryption applied at the same LSR. Additionally, it should 903 be noted that, as described in Section 3.5, each recursive encryption 904 reduces the MTU by at least 28 octets. 906 4. Key Exchange For Opportunistic Security in MPLS 908 For encryption to be useful both ends of an encrypted session must 909 know which algorithm is in use and which key to use. The mechanism 910 described in Section 3 provides a way to indicate an index into a 911 table of algorithms and keys that can be used to decrypt an encrypted 912 MPLS packet. 914 It is possible that this table has been manually configured or set up 915 using a key exchange protocol such as Internet Key Exchange version 2 916 (IKEv2) [RFC7296]. However, such a process implies a stable security 917 association between encrypter and decrypter of MPLS packets. While 918 such a stable association is entirely consistent with the concept of 919 OS, OS nonetheless calls for a more dynamic key agreement method. 921 This section provides a mechanism for adjacent MPLS LSRs, or for a 922 pair of LSRs at opposite ends of an MPLS LSP, to dynamically exchange 923 keys and algorithm identifiers so that encryption may be applied 924 opportunistically. 926 The mechanism uses message exchanges in the MPLS Generic Associated 927 Channel (G-ACh) [RFC5586] as part of the MPLS Generic Associated 928 Channel (G-ACh) Advertisement Protocol (GAP) [RFC7212]. This channel 929 is in-band with an LSP and may be used to carry messages between 930 neighbors or between the end points of the LSP. A type field within 931 the common message header, the Associated Channel Header (ACH), is 932 used to indicate the type of message carried. 934 Nodes that receive G-ACh messages and do not understand them, or 935 nodes that understand the G-ACh but do not recognize the ACH message 936 type drop the packets as described in [RFC5586]. 938 Note that this mechanism may benefit from encryption that is already 939 in use on an LSP. Thus, key changes using this mechanism (for 940 example, for key change) can be made using encrypted messages. 942 4.1. Initiating MPLS-OS 944 This document assumes that the use of MPLS-OS is initiated by the 945 upstream of a pair of LSRs (either a pair of adjacent LSRs on an LSP, 946 or a pair of LSP end points). That is, the upstream LSR sends the 947 first G-ACh message that initiates key exchange. The key that is 948 generated after the exchange is used to encrypt traffic travelling in 949 the direction between initiating and responding LSRs: that is, from 950 upstream to downstream LSR. 952 In the case of a bidirectional LSP, each direction is treated 953 separately. That is, "upstream" refers to the direction of traffic 954 flow, and not to any signaling that is used to establish the LSP. 955 Thus, it is possible that a bidirectional LSP uses MPLS-OS on 956 neither, either one, or both of the directions of traffic flow for 957 the LSP. But it is important to note that the keys used are 958 different in each direction, each being generated and exchanged 959 through a separate instance of the procedures described in this 960 document. Note that the input parameters for key derivation listed 961 in Section 4.3.3 show LSP identifier, initiator LSR identifier, and 962 responder LSR identifier as three of the ordered list of pieces of 963 information used by the key derivation function. In the case of a 964 bidirectional LSP, the LSP identifier will be the same in each 965 direction, and the two LSR identifiers will be the same, but the LSR 966 identifiers will be used in the reverse order at the two end points 967 of the MPLS-OS exchange and this will reduce the chance of the same 968 key being used in each direction. 970 Note also that in the case of a pair of unidirectional LSPs in 971 reverse directions between a pair of LSRs there should be no 972 relationship between the keys used on each LSP even if there is a 973 tight coupling between the LSPs such as might be the case for 974 associated bidirectional LSPs [RFC7551]. The key derivation function 975 will use different LSP identifiers as well as using the LSR 976 identifiers in a different order. 978 4.2. MPLS G-ACh Advertisement Protocol for Key Exchange 980 GAP defines messages exchanged in the G-ACh on a common Associated 981 Channel Type code point (0x0059) [RFC7212]. The application for 982 which the messages are exchanged is defined by the Application ID 983 field carried in the Applications Data Block (ADB). MPLS-OS 984 capability notification and key exchange uses the GAP Application ID 985 (0x0000) defined by [RFC7212] and a new ADB TLV for MPLS-OS. 987 Implementations that do not support GAP will discard received packets 988 with this Associated Channel Type as described in [RFC5586]. 989 Implementations that support GAP but that do not support key exchange 990 will discard received packets with this ADB TLV as described in 991 [RFC7212]. Either of these discards will result in no dynamic key 992 exchange, but other key definitions are still supported (such as 993 manual configuration) and may be used to construct a table of 994 algorithms and keys that can be used to achieve MPLS encryption using 995 the mechanisms described in Section 3. 997 4.3. Key Exchange Protocol 999 4.3.1. Communication Channels 1001 The key exchange protocol described in this document uses a D-H 1002 exchange that assumes a bidirectional communication channel. GAP is 1003 designed to run over a unidirectional channel and uses normal IP 1004 forwarding for return path messages with an optimization to use the 1005 return path of a bidirectional LSP. However, LSPs in packet networks 1006 are usually unidirectional. That means that, while the key exchange 1007 messages can be sent on the LSP in one direction, a channel needs to 1008 be established for the return messages. 1010 This document uses a process similar to that defined for MPLS LSP 1011 Ping ([RFC4379] and [RFC7110]), and similar to that used to indicate 1012 a return path for MPLS performance measurement in [RFC7876]. That 1013 is, the forward message is sent on the LSP and includes the identity 1014 of the return path communication channel. The return path may be 1015 indicated as a UDP communication over IP, as an LSP running in the 1016 opposite direction, or as the reverse direction of a bidirectional 1017 LSP. 1019 Note that the GAP messages defined in [RFC7212] include a TLV that 1020 enables authentication. This feature SHOULD be used if possible, but 1021 it is in the nature of opportunistic security that the necessary 1022 security association might not exist. In this case the ability to 1023 tamper with the instructions that select a return path may provide a 1024 mechanism that makes MITM attacks easier. An implementation that 1025 initiates key exchange for MPLS Opportunistic Security MUST verify 1026 that the response messages are received on the expected return path 1027 channel and SHOULD raise an operator alert if the channel is 1028 unexpected. 1030 4.3.2. Key Exchange Messages 1032 The format of a GAP message is described in [RFC7212]. When used for 1033 key exchange the GAP message includes an ADB with the fields set as 1034 follows. 1036 Application ID is set to 0x0000. 1038 Element Length is set to the total length in octets of this ADB 1039 including the Application ID and this field. 1041 Lifetime field SHOULD be set to zero and MUST be ignored. 1043 A key exchange ADB MUST include a Key Exchange TLV as shown in 1044 Section 4.3.3. The ADB MAY also include an Authentication TLV as 1045 described in [RFC7212] to provide authentication and integrity 1046 validation for a GAP message (see Section 4.5). Additionally, the 1047 ADB MAY include a Source TLV as described in [RFC7212] and discussed 1048 in Section 4.4. 1050 4.3.3. Key Exchange TLV 1052 A session key is to be established between an initiator (Alice) and a 1053 recipient (Bob). The D-H public value for Alice is g^i and for Bob, 1054 g^r. The shared Diffie-Hellman value is g^ir. g^ir is represented 1055 as a string of octets in big endian order padded with zeros if 1056 necessary to make it the length of the modulus. Both g^i and g^r 1057 will be 2048 bits long, if the Diffie-Hellman modulus is 2048 bits 1058 long. 1060 The Key Exchange TLV is modelled on that from Section 3.4 of 1061 [RFC7296] with the addition of information to identify the LSP and 1062 its return path, and is encoded as shown in Figure 6. 1064 1 2 3 1065 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Type | Reserved | Length | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 |D|Rsvd | Return| Path Identifier | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | LSP-ID | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Algorithm | Group Num | | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1075 | | 1076 ~ D-H Public Value ~ 1077 | | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 Figure 6: Key Exchange Message TLV 1082 Type is set to TBD1 to indicate that this is a Key Exchange TLV. 1084 The Reserved and Length fields are defined in [RFC7212]. 1086 The flag D denotes the direction of the message, '0' indicates a 1087 message from initiator (Alice) to recipient. '1' indicates the 1088 reverse direction. 1090 The Rsvd bits are reserved. They SHOULD be set to zero and ignored 1091 on receipt. 1093 The Return field is used on a message from the initiator to indicate 1094 the type of return path to be used for messages from the responder. 1095 The Path Identifier field is interpreted in this context. Possible 1096 values are as follows: 1098 0 The reverse path of a bidirectional LSP is to be used for the 1099 response. 1101 1 The reverse path messages are to be sent encapsulated in UDP. 1103 2 Any LSP between the recipient and the initiator may be used. 1105 3 Any LSP between the recipient and the initiator that is already 1106 using MPLS-OS may be used. 1108 4 The reverse path messages are to be sent on a specific LSP. 1110 All other values are undefined and MUST be processed as an encoding 1111 error as described in Section 4.3.4. Similarly, if a value indicates 1112 an unavailable return path (such as a request for the reverse path of 1113 a bidirectional LSP when the LSP is actually unidirectional) then it 1114 MUST be handled as an encoding error. 1116 The Path Identifier is interpreted in the context of the Return 1117 field. The field only has meaning on messages from the initiator and 1118 SHOULD be ignored on responses. If the Return field is set to the 1119 following values, the Path Identifier has the following meaning: 1121 0 In this case the Path Identifier field has no meaning and SHOULD 1122 be ignored. 1124 1 The Path Identifier field contains a UDP port number from the 1125 dynamic port range that the initiator will listen on for a 1126 response. 1128 2 In this case the Path Identifier field has no meaning and SHOULD 1129 be ignored. 1131 3 In this case the Path Identifier field has no meaning and SHOULD 1132 be ignored. 1134 4 The Path Identifier field contains an LSP-ID that must be used for 1135 reverse path messages. 1137 See Section 4.4 for more discussion of return paths. 1139 The LSP-ID parameter indicates the LSP to which this key exchange 1140 applies. On messages from initiator to recipient this field MUST be 1141 set to the LSP on which the message flows and any mismatch MUST be 1142 treated as an encoding error (Section 4.3.4). On messages from 1143 recipient to initiator, this value MUST be copied from the received 1144 message and an initiator that cannot match the message and LSP-ID to 1145 a message that it previously sent MUST treat the situation as an 1146 encoding error. 1148 The Algorithm field is a one octet field that specifies both the KDF 1149 to use and the symmetric algorithm to be used for data packet 1150 encryption. A registry for values of this field is defined in 1151 Section 8.2. The value 0 is used to indicate the default KDF and 1152 symmetric encryption mode. An implementation receiving a value for 1153 an Algorithm it does not support MUST treat the case as an encoding 1154 error as described in Section 4.3.4. All implementations MUST 1155 support the default KDF. Note that since implementation of 1156 encryption and decryption is likely to be supported in hardware for 1157 reasons of data throughput performance, the introduction of new 1158 algorithms may be bound by firmware or even hardware upgrades. 1160 The Diffie-Hellman Group Num is from [RFC3526], so the group number 1161 for 2048 MODP is decimal 14. Note that this is a one octet field but 1162 is two octets in the [RFC7296] equivalent. This is not an issue 1163 because there are only 30 MODP groups defined at present, new groups 1164 are not added frequently, and values are assigned sequentially. 1166 The D-H public value will contain g^i or g^r depending on the 1167 direction (i.e., the setting of the D flag) and is in big endian 1168 order. 1170 The length of the Diffie-Hellman public value for MODP groups MUST be 1171 equal to the length of the prime modulus over which the 1172 exponentiation was performed, prepending zero bits to the value if 1173 necessary. 1175 Once both sides have derived g^ir they need to feed that and the 1176 other inputs described in Section 2.4 into the KDF indicated by the 1177 algorithm field. With the default algorithm (value zero), the KDF to 1178 be used is HKDF as specified in [RFC5869]. 1180 The parameters for the use of HKDF are: 1182 Hash: SHA-256 1184 Salt: Not used 1186 Skip: Do not skip 1188 Info: The catenation of a fixed string indicating use of MPLS-OS 1189 with the value "MPLS-OS", the first 32 bits of the key exchange 1190 message with the D flag set to 0, plus the LSP ID and the sender 1191 and receiver LSR IDs in that order. That is: 1193 MPLS-OS||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID 1195 L: The output length in bits is 272. 1197 The fixed string "MPLS-OS" is used as an input to prevent potential 1198 cross-protocol attacks. Those might otherwise be possible if this 1199 mechanism were to be copied in other protocols. (If copying this 1200 mechanism for any reason, then a different fixed string value should 1201 be used.) 1203 LSP-ID is a unique identifier shared between the initiator and 1204 receiver (Alice and Bob) that uniquely identifies the LSP. 1206 If RSVP-TE is used for signaling, the LSP-ID is known along the LSP 1207 and at the two end points. Similarly, the LSP-ID is known if the LSP 1208 is manually configured. [[It is not so clear how the LSP-ID is known 1209 for LSPs established using LDP, although possibly we could use the 1210 FEC as defined for RFC 4379 and its extensions. Note that LSPs 1211 established using LDP are essentially multpoint-to-point, but the 1212 securiity relationship is one-to-one between a sender and the 1213 receiver.]] 1215 i-LSR-ID and r-LSR-ID are the LSR-IDs of the initiator and receiver 1216 respectively (Alice and Bob), where an LSR-ID is the 32 bit, globally 1217 unique identifier of the LSR as described in [RFC5036] and [RFC4990]. 1219 The default encryption algorithm, AEAD_AES_GCM_128, specified in 1220 Section 3, requires a 128 bit session key. 1222 The 272-bit HKDF output is the catenation of the session key, the 1223 key-id, the witness value, and the high-order 16 bits of the initial 1224 nonce value in that order. That is, the session key is the leftmost 1225 128 bits of the HKDF output. The key-id is the next 4 bits, the 1226 witness value is the next 124 bits, and the last 16 bits are the 16 1227 most significant bits of the initial nonce value. The low order 64 1228 bits of the initial nonce value are set to zero before the first call 1229 to the AES-GCM encryption function. The key-id is carried in 1230 encrypted packets as described in Section 3.2. 1232 Note that a 4 bit key-id is adequate in a system where, for any one 1233 LSP there is one active key and one new or replaced key. There might 1234 also be more than one algorithm, and it is possible that new keys 1235 need to be pipelined if roll-over is frequent. In the case that a 1236 newly-generated key-id is already in use, the key-id value is 1237 repeatedly incremented (modulo 16) until an unused value is found. 1238 If all 16 values are already in use, the key derivation function 1239 SHOULD NOT be executed. 1241 4.3.4. Encoding Errors 1243 Unknown values in received key Exchange TLVs MUST be treated as 1244 encoding errors. All messages that constitute encoding errors MUST 1245 be silently discarded. That is, such errors MUST NOT cause response 1246 messages to be sent since those messages could be used as part of an 1247 attack to determine the capabilities of an LSR. 1249 An LSR SHOULD log such errors and notify the operator because 1250 encoding errors represent a failed attempt to communicate and might 1251 indicate some form of attack. However, care is needed with these 1252 actions since they may be externally visible. Furthermore, such 1253 logging and reporting could consume local resources and might be used 1254 as a way to overload or congest parts of the system. Therefore all 1255 implementations that offer logging and notification of encoding 1256 errors MUST include throttling mechanisms and MUST allow logging and 1257 notification to be disabled through configuration. 1259 4.4. Indicating the Return Path 1261 The key exchange for MPLS-OS requires a two-way exchange of messages. 1262 The Return field of the Key Exchange TLV indicates the reverse path 1263 to use for key exchange messages relevant to a particular LSP. 1265 Whenever the LSP being secured is bidirectional, the same LSP SHOULD 1266 be used for reverse path messages. Otherwise, the initiator selects 1267 the communication channel as described in Section 4.3.3. 1269 If UDP is being used and it may be unclear to what address the 1270 messages should be sent, the initiator MUST include a Source Address 1271 TLV [RFC7212] to provide this information. 1273 Operators should consider the security implications of the return 1274 path. The use of an already-secured LSP (Return type 3) may provide 1275 a preferable path because it will help to secure the GAP messages. 1277 Implementations MUST make the choice of return path request sent by 1278 an initiator available as a configuration option. As noted in 1279 Section 4.3.1, the fact that the the initial GAP messages might not 1280 be protected means that there is the potential to tamper with the 1281 instructions that select a return path. This could be used as a 1282 vector for MITM attacks. To protect against this, an implementation 1283 that initiates key exchange for MPLS Opportunistic Security MUST 1284 verify that the response messages are received on the expected return 1285 path channel and SHOULD raise an operator alert if the channel is 1286 unexpected. In these circumstances an implementation MAY be 1287 configured to abort establishment of MPLS-OS although, since that in 1288 itself is an attack vector, it is RECOMMENDED that implementations 1289 continue toward the use of MPLS-OS while notifying the operator. 1291 4.5. Protecting the Key Exchange Protocol Messages 1293 GAP includes an Authentication TLV that can be used to protect GAP 1294 messages as described in [RFC7212]. If there is already an SA 1295 between the initiator and recipient this TLV SHOULD be used. 1296 However, it is probable with MPLS-OS that no such SA exists and the 1297 point of the mechanisms described in this document is to exchange 1298 keys in that case, therefore, it is quite likely that the 1299 Authentication TLV cannot be used on the first GAP exchanges. 1301 As described in Section 2.4, once one key exchange has been 1302 successfully completed, further key exchanges should be protected 1303 using a previous key. This is simply achieved since key exchange 1304 messages are, themselves, carried in MPLS packets on the LSP and are 1305 subject to encryption exactly as any other packet. 1307 Furthermore, once keys have been established, they may also be used 1308 in the GAP Authentication TLV. 1310 5. Applicability of MPLS Opportunistic Security 1312 MPLS-OS provides another tool in the security and privacy toolkit. 1313 It is not a panacea and does not solve (nor is it intended to solve) 1314 all security or privacy problems. In particular, the use of MPLS-OS 1315 does not protect user-data end-to-end that might be better secured 1316 using encryption at the IP layer or at higher layers. 1318 As noted throughout this document, the intention of OS in MPLS is to 1319 allow one LSR to enable encryption between itself and its neighbor, 1320 or between itself and the other end of an LSP, in a dynamic and un- 1321 planned way. This can have benefits in a number of scenarios where 1322 the network that generates MPLS traffic transmits it over another 1323 network (for example, carrier's carrier, or some deployments of 1324 enterprise networks). Additionally, the use of MPLS-OS might allow a 1325 service provider to offer a secure edge-to-edge service for a variety 1326 of applications ranging from VPNs through pseudowires and where the 1327 payload traffic might not always be IP. Lastly, in some non- 1328 traditional carriers the user data belongs to the operator or is the 1329 direct responsibility of the operator (for example, in data center 1330 interconnect, or in large-scale private networks). 1332 As with all security mechanisms, there is a trade-off between a 1333 number of factors. On one side is the completeness of the security 1334 of the user-data, and on the other side is the complexity of 1335 configuring and managing the necessary security associations. 1336 Furthermore, while mechanisms closer to the end-user than MPLS-OS 1337 (for example, TLS and IPsec in tunnel mode) provide better security 1338 for user-data by virtue of not transmitting the data across any 1339 network hops without it being encrypted, such mechanisms often expose 1340 more metadata for inspection by snoopers within the network. 1342 Additionally, while a variety of per-link encryption mechanisms exist 1343 and could be used to guard against attacks such as fiber taps, those 1344 approaches do not protect against subverted nodes (i.e., routers) on 1345 the path since, by definition, per-link encryption does not protect 1346 packets once they come off the link. MPLS-OS in the end-to-end LSP 1347 mode protects packets on the links and as they cross transit routers. 1349 Nevertheless, it is not the purpose of this document to recommend the 1350 use of MPLS-OS to the exclusion of all other encryption techniques. 1351 As already mentioned, MPLS-OS is offered as another tool in the 1352 toolkit and users as well as network operators are strongly advised 1353 to consider using a variety of tools to achieve the level of security 1354 and privacy that they desire. 1356 Note that, in order that OS can be used, one end of a peering 1357 (neighbor or LSP end) must decide to attempt OS and the other end 1358 must support it. This can be determined by the message exchanges 1359 described in Section 4.3 since if one peer does not send a key 1360 exchange message then encryption will not be used, and if the other 1361 peer does not respond then it is unwilling or unable to decrypt 1362 messages. 1364 MPLS-OS should be applicable to all forms of MPLS. That is, it 1365 should be possible to use it in RSVP-TE systems, in LDP systems, and 1366 in MPLS-TP systems (by which we mean those that have manually 1367 configured LSPs). Equally, it should work for point-to-point (P2P) 1368 and multipoint-to-point (MP2P) uses of MPLS because there is a simple 1369 relationship between the sender (encrypter) and the receiver 1370 (decrypter) in both cases. In the MP2P case, the sender's identity 1371 can be extracted from the key identifier and there are considered to 1372 be enough key identifiers to allow an arbitrary number of senders on 1373 the LSP. There will, however, be the need for the receiver to hold 1374 OS state (keys, packet counters) for each sender which may be a 1375 significant amount of data for an MP2P LSP (although no more than if 1376 the same LSP were replaced by multiple P2P LSPs). Additionally, it 1377 should be noted that not only will each sender on an MP2P LSP have a 1378 different key and nonce, but each may separately decide whether to 1379 encrypt data or not. 1381 At this time it is not certain whether MPLS-OS can be applied to a 1382 point-to-multipoint (P2MP) or to a multipoint-to-multipoint LSP in 1383 its entirety because packet replication cannot handle the necessary 1384 key conversions for each receiver. However, MPLS-OS can certainly be 1385 applied to individual hops on these LSPs. Further work is needed to 1386 determine whether non-branching multi-hop segments of P2MP and MP2P 1387 LSPs can also be protected using MPLS-OS. 1389 5.1. Tunnel MPLS Packets 1391 Note that in the case of tunneling of MPLS packets in another 1392 technology (such as MPLS-in-UDP [RFC7510]) there are two approaches 1393 that are viable: 1395 o The payload of the encapsulation (i.e., the entire MPLS packet) 1396 can be encypted using the mechanisms described in this document 1397 without any changes. Any payload identifier in the encapsulation 1398 header can remain set to "MPLS" since the encrypted packet is 1399 always just an MPLS packet. 1401 o The encryption mechanisms present in the encapsulating technology 1402 can be used without any need to use the mechanisms described in 1403 this document. 1405 In some cases the processing of one label on the label stack depends 1406 on the values contained in the previous label stack entry. For 1407 example, in the "Pipe Model" [RFC3270], the Diff-Serv treatment of 1408 the packet that is forwarded beyond the end of the tunnel depends on 1409 the setting of the TC field in the previous label stack entry. This 1410 requires that when a label is popped, the value of the TC field in 1411 the label stack entry is cached for use while forwarding. In the 1412 case that the next label on the stack is the MEL, decryption of the 1413 rest of the packet is required, and this caching would be a little 1414 more complicated to implement. This situation is mitigated by 1415 setting the TC field of the label stack entry that contains the MEL 1416 to the value from the preceding label stack entry as described in 1417 Section 3.1. 1419 The "Short Pipe Model" [RFC3270] can be handled using a combination 1420 of the above technique and the procedures described in the next 1421 section. 1423 5.2. Penultimate Hop Popping 1425 In penultimate hop popping (PHP) a label is removed from the label 1426 stack of a packet one hop before the end of the LSP. The packet is 1427 forwarded as though it was still carried on the LSP, but the label 1428 stack entry for the LSP is removed. Sometimes we say that packet 1429 uses the "implicit null label" [RFC3032]. 1431 When there are additional subsequent labels on the label stack, this 1432 has no impact on the use of the mechanisms described in this 1433 document. It is possible that after PHP the MEL will become the top 1434 label in the stack meaning that the next hop receiver of the packet 1435 may encounter the MEL as the top label. This has implications for 1436 the setting of the TC and TTL fields in the MEL label stack entry as 1437 described in Section 3.1. 1439 However, in some cases of PHP the popped label is the bottom of the 1440 label stack and the packet after the popped label is some non-MPLS 1441 payload protocol (such as IPv6). PHP is used specifically because 1442 the receiving interface does not have MPLS capabilities in the 1443 forwarding plane. In this situation the packet is identified within 1444 the link encapsulation on the final hop by its payload protocol type 1445 (such as IPv6). If MPLS-OS is used, this situation will change 1446 because even when the final label is stripped using PHP there will 1447 remain a MEL entry in the label stack. Therefore the packet will 1448 need to be identified as "MPLS" in the link encapsulation on the 1449 final hop, yet the receiver might not be capable of handling MPLS 1450 packets. 1452 This problem can be approached in two ways: 1454 o The penultimate hop may note the presence of the MEL during PHP 1455 and attempt to remove the MEL as well. This is unlikely to be 1456 successful as the encryption negotiation has been conducted 1457 between the end points of the LSP and the penultimate hop is not 1458 aware of the keys or algorithms needed for decryption. 1459 Furthermore, this approach would leave the packet unencrypted on 1460 its final hop which may be counter to the intent of the LSP end 1461 points. 1463 o The end point of the LSP should recognize that it cannot have both 1464 MPLS-OS and PHP. Indeed, in agreeing to the use of MPLS-OS the 1465 end point is making a statement about its ability to handle the 1466 MEL and so it can choose: 1468 * to request PHP and allow the penultimate hop to set the payload 1469 indicator of the link encapsulation header to "MPLS"; or 1471 * to not request PHP. 1473 6. Security Considerations 1475 6.1. Security Improvements 1477 See Section 2.1. 1479 6.2. Applicability 1481 See Section 5. 1483 6.3. Continued Vulnerabilities 1485 The mechanisms described in this document do not provide protection 1486 against certain types of MITM attacks. For example, the key exchange 1487 protocol in Section 4.3 will not detect if key exchange messages or 1488 their responses are intercepted and discarded such that the 1489 initiating peer believes that encryption is not supported. 1490 Similarly, those messages may be tampered with such that a receiver 1491 cannot determine the correct mapping of table index to algorithm and 1492 key when an encrypted packet is received. Furthermore, the MEL in an 1493 MPLS packet is not protected and may be overwritten such that a 1494 receiver is unable to decrypt the packet. 1496 See Section 7.1 for a discussion of how active MITM attacks can be 1497 detected. 1499 6.4. New Security Considerations 1501 If a pair of LSRs do not do the key exchange before sending any data 1502 packets on the LSP (for example, if data transmission starts as soon 1503 as the LSP is set up and while OS is being enabled) then those first 1504 packets will not be protected by OS and hence will be available to a 1505 monitor. This is not a new security vulnerability per se since the 1506 situation without OS is that those packets are not protected. 1507 However, the presence of OS (i.e., the configuration to support OS on 1508 the LSP) may give the false impression that all packets are 1509 protected. An implementation might reasonably be designed to not 1510 allow transmission of payload packets on an LSP for which OS is 1511 configured until OS is established and ready for use. 1513 If a MITM can prevent the OS key exchange from completing, e.g. via 1514 deleting messages or changing bits in messages, and if the LSRs 1515 continue to send data regardless, then those data packets will be 1516 available to a monitor. That is, in simple terms, a MITM attacker is 1517 able to prevent OS from being used through a very simple attack, and 1518 the only options for the end points in this situation are to send no 1519 data or to send data in the clear. Again, it should be pointed out 1520 that this occurrence is not worse than running no OS at all, but has 1521 the benefit of being detectable by end points. See Section 2.4 and 1522 Section 7.1 for a description of how alarms should be raised in these 1523 circumstances. Furthermore, Section 4.3.1 and Section 4 describe how 1524 the return path for key exchange messages might be hijacked to better 1525 facilitate MITM attacks, and indicates how the initiator of MPLS-OS 1526 can detect this and what actions it should take. 1528 Thus, as has been previously noted, OS is not a cure for all ills or 1529 a prevention against all attacks, but it does offer a way to increase 1530 security in some circumstances. 1532 7. Manageability Considerations 1534 As described in Section 2.4 node-wide and per-LSP behavior SHOULD be 1535 configurable to describe the action where key agreement exchange or 1536 packet decryption fails. In any case, such events MUST trigger 1537 alarms to the operator. 1539 7.1. MITM Detection 1541 Section 2.4 introduces the concept of a function of the shared secret 1542 that can be compared by two LSRs that are using OS to see whether 1543 they are victims of an active MITM attack. 1545 Section 4.3 describes how a witness value is derived for the default 1546 KDF, HKDF. 1548 The participating LSRs can simply log this value plus the LSP and LSR 1549 IDs from time to time and a management application can compare the 1550 values. If they are different for the same LSP ID, then an active 1551 MITM attack has taken place. 1553 It needs to be carefully noted that the management channel used to 1554 log or otherwise compare the witness values from the two LSRs MUST be 1555 secure. It is likely that routers use relatively high security 1556 management channels for configuration and other management 1557 operations. 1559 8. IANA Considerations 1560 8.1. GAP Key Exchange TLV 1562 IANA maintains a registry called "Generic Associated Channel (G-ACh) 1563 Parameters" with a sub-registry called "G-ACh Advertisement Protocol 1564 Application Registry" from which new assignments may be made through 1565 the "IETF review" allocation policy [RFC5226]. IANA is requested to 1566 make a new allocation as follows: 1568 Value | Description | Reference 1569 ------+-------------------------------------------------+----------- 1570 TBD1 | Opportunistic Key Exchange Protocol for MPLS | [This.ID] 1572 8.2. Key Derivation Functions and Symmetric Algorithms 1574 IANA maintains a registry called "Generic Associated Channel (G-ACh) 1575 Parameters". IANA is requested to create a new sub-registry called 1576 "G-ACh Advertisement Protocol: MPLS Encryption Algorithms Registry" 1577 with new values to be assigned through "IETF Review" as defined in 1578 [RFC5226]. 1580 The available range is 0 - 255. 1582 IANA is requested to record the following information and create an 1583 initial entry as follows: 1585 Value | Key Derivation Function | Symmetric Algorithm | Reference 1586 ------+-------------------------+---------------------+----------- 1587 0 | HKDF | AEAD_AES_GCM_128 | [This.I-D] 1588 1-255 | Unassigned | | 1590 9. Acknowledgements 1592 Many thanks to Alia Atlas for detailed discussion of the implications 1593 and mechanisms of MPLS opportunistic security. Thanks also to Ron 1594 Bonica for encouraging this work, to Sean Turner and Stewart Bryant 1595 for early review, and to Jeff Haas, Eric Rosen, and Ross Callon for 1596 discussions. Thanks for MPLS Review Team comments from Mach Chen and 1597 Lizhong Jin, and to Charlie Kaufman and George Swallow for review 1598 comments. 1600 Additional thanks to Andy Malis and Danny McPherson for advice about 1601 the use of the Control Word. 1603 10. References 1605 10.1. Normative References 1607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1608 Requirement Levels", BCP 14, RFC 2119, 1609 DOI 10.17487/RFC2119, March 1997, 1610 . 1612 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1613 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1614 RFC 3526, DOI 10.17487/RFC3526, May 2003, 1615 . 1617 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1618 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1619 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1620 February 2006, . 1622 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1623 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1624 . 1626 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1627 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1628 DOI 10.17487/RFC5226, May 2008, 1629 . 1631 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1632 "MPLS Generic Associated Channel", RFC 5586, 1633 DOI 10.17487/RFC5586, June 2009, 1634 . 1636 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1637 Key Derivation Function (HKDF)", RFC 5869, 1638 DOI 10.17487/RFC5869, May 2010, 1639 . 1641 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1642 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1643 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1644 . 1646 [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 1647 Associated Channel (G-ACh) Advertisement Protocol", 1648 RFC 7212, DOI 10.17487/RFC7212, June 2014, 1649 . 1651 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 1652 and Retiring Special-Purpose MPLS Labels", RFC 7274, 1653 DOI 10.17487/RFC7274, June 2014, 1654 . 1656 10.2. Informative References 1658 [IEEE-802.1AE] 1659 IEEE Computer Society, "IEEE 802.1AE Media Access Control 1660 (MAC) Security", August 2006. 1662 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1663 Label Switching Architecture", RFC 3031, 1664 DOI 10.17487/RFC3031, January 2001, 1665 . 1667 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1668 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1669 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1670 . 1672 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1673 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1674 Protocol Label Switching (MPLS) Support of Differentiated 1675 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1676 . 1678 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1679 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1680 DOI 10.17487/RFC3985, March 2005, 1681 . 1683 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1684 "Randomness Requirements for Security", BCP 106, RFC 4086, 1685 DOI 10.17487/RFC4086, June 2005, 1686 . 1688 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1689 DOI 10.17487/RFC4302, December 2005, 1690 . 1692 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1693 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1694 . 1696 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1697 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1698 DOI 10.17487/RFC4379, February 2006, 1699 . 1701 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 1702 Addresses in Generalized Multiprotocol Label Switching 1703 (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990, 1704 September 2007, . 1706 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1707 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1708 October 2007, . 1710 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1711 (TLS) Protocol Version 1.2", RFC 5246, 1712 DOI 10.17487/RFC5246, August 2008, 1713 . 1715 [RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell 1716 (SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011, 1717 . 1719 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 1720 "Return Path Specified Label Switched Path (LSP) Ping", 1721 RFC 7110, DOI 10.17487/RFC7110, January 2014, 1722 . 1724 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1725 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1726 2014, . 1728 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1729 Kivinen, "Internet Key Exchange Protocol Version 2 1730 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1731 2014, . 1733 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 1734 and C. Pignataro, "MPLS Forwarding Compliance and 1735 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 1736 August 2014, . 1738 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1739 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1740 December 2014, . 1742 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 1743 "Encapsulating MPLS in UDP", RFC 7510, 1744 DOI 10.17487/RFC7510, April 2015, 1745 . 1747 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1748 Extensions for Associated Bidirectional Label Switched 1749 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1750 . 1752 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 1753 Method in the Internet Key Exchange Protocol Version 2 1754 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 1755 . 1757 [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path 1758 for Packet Loss and Delay Measurement for MPLS Networks", 1759 RFC 7876, DOI 10.17487/RFC7876, July 2016, 1760 . 1762 Authors' Addresses 1764 Adrian Farrel 1765 Juniper Networks 1767 Email: afarrel@juniper.net 1769 Stephen Farrell 1770 Trinity College Dublin 1771 Dublin 2 1772 Ireland 1774 Phone: +353-1-896-2354 1775 Email: stephen.farrell@cs.tcd.ie