idnits 2.17.1 draft-farrelll-mpls-opportunistic-encrypt-05.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 (June 16, 2015) is 3208 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Farrel 2 Internet-Draft Juniper Networks 3 Intended status: Experimental S. Farrell 4 Expires: December 16, 2015 Trinity College, Dublin 5 June 16, 2015 7 Opportunistic Security in MPLS Networks 8 draft-farrelll-mpls-opportunistic-encrypt-05.txt 10 Abstract 12 This document describes a way to apply opportunistic security 13 between adjacent nodes on an MPLS Label Switched Path (LSP) or 14 between end points of an LSP. It explains how keys may be agreed 15 to enable encryption, and how key identifiers are exchanged in 16 encrypted MPLS packets. Finally, this document describes the 17 applicability of this approach to opportunistic security in MPLS 18 networks with an indication of the level of improved security as 19 well as the continued vulnerabilities. 21 This document does not describe security for MPLS control plane 22 protocols. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Notation 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 Table of Contents 62 1. Introduction ................................................... 3 63 1.1. Experimental Status .......................................... 4 64 1.2. Existing Security Tools for MPLS Data ........................ 5 65 2. Principles of Opportunistic Security ........................... 5 66 2.1. Why Do We Need Opportunistic Security? ....................... 5 67 2.2. Opportunistic Security at 10,000ft ........................... 7 68 2.3. What about a Man-in-the-Middle? .............................. 8 69 2.4. OS in MPLS Overview .......................................... 9 70 3. MPLS Packet Encryption ........................................ 11 71 3.1. MPLS Encryption Label ....................................... 14 72 3.2. Control Word ................................................ 14 73 3.3. Considerations for ECMP ..................................... 15 74 3.4. Backward Compatibility ...................................... 16 75 3.5. MTU Considerations .......................................... 17 76 3.6. Recursive Encryption ........................................ 17 77 4. Key Exchange For Opportunistic Security in MPLS ............... 17 78 4.1. Initiating MPLS-OS .......................................... 18 79 4.2. MPLS G-ACh Advertisement Protocol for Key Exchange .......... 19 80 4.3. Key Exchange Protocol ....................................... 19 81 4.4. Indicating the Return Path .................................. 24 82 4.5. Protecting the Key Exchange Protocol Messages ............... 25 83 5. Applicability of MPLS Opportunistic Security ................. 25 84 5.1. Tunnel MPLS Packets ......................................... 27 85 5.2. Penultimate Hop Popping ..................................... 28 86 6. Security Considerations ....................................... 29 87 6.1. Security Improvements ....................................... 29 88 6.2. Applicability ............................................... 29 89 6.3. Continued Vulnerabilities ................................... 29 90 6.4. New Security Considerations ................................. 29 91 7. Manageability Considerations .................................. 30 92 7.1. MITM Detection .............................................. 30 93 8. IANA Considerations .......................................... 30 94 8.1. GAP Key Exchange TLV ........................................ 30 95 8.2. Key Derivation Functions and Symmetric Algorithms ........... 31 96 9. Acknowledgements ............................................. 31 97 10. References .................................................. 31 98 10.1. Normative References ...................................... 31 99 10.2. Informative References .................................... 32 100 Authors' Addresses ............................................... 34 102 1. Introduction 104 MPLS is an established data plane protocol in the Internet. It is 105 found in the majority of core service provider networks and most end- 106 to-end traffic in the Internet will be carried over MPLS at some 107 point in its path. The MPLS data plane is defined by [RFC3031] and 108 [RFC3032]. 110 Data security (e.g., confidentiality) in MPLS has previously relied 111 on just two features: 113 - Physical isolation of MPLS networks has been used to ensure that 114 interception of MPLS traffic was not possible. 116 - Higher-layer protocol security (such as IPsec [RFC4302], [RFC4303]) 117 has been used whenever a particular flow has determined that 118 security was desirable. 120 These features have a number of significant vulnerabilities: 122 - Networks are increasingly easily compromised physically such that 123 "taps" may be inserted in links between routers [RFC7258]. 125 - Routers may be compromised either in their entirety or through 126 the management/control plane (or misconfiguration). This may 127 result in packets being diverted to transit inspection points on 128 their way to their destination. 130 - The increased support for point-to-multipoint (P2MP) MPLS means 131 that routers can easily be configured (or misconfigured) to make a 132 copy of data and to send it to an additional destination. 134 - End-to-end payload security may be hard to manage and operate and 135 is not turned on by default by many users. While this form of 136 security is desirable, the network should also improve the security 137 of data transfer that it offers. 139 The concept of Opportunistic Security (OS) is introduced in 140 [RFC7435]. This document describes an OS design pattern for the MPLS 141 data plane. It shows what part of an MPLS packet may be encrypted 142 and provides a way to indicate that the packet is encrypted as well 143 as to carry a key identifier with each packet. 145 MPLS opportunistic security can be achieved between adjacent Label 146 Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and 147 also between end points of an LSP. 149 This document also provides a mechanism for keys to be exchanged to 150 facilitate encryption. Finally, this document describes the 151 applicability of OS in MPLS networks with an indication of the level 152 of improved security as well as the continued vulnerabilities. 154 This document does not describe security for MPLS control plane 155 protocols. 157 Please note that a discussion of the applicability of MPLS 158 opportunistic security is provided in Section 5. 160 1.1. Experimental Status 162 This document is presented as experimental. Before advancing this 163 work on the IETF's Standards Track, it is important to get experience 164 of the practicality of the mechanisms described. In particular 165 whether it is practical to achieve these mechanisms in existing 166 hardware, and whether the imposition of additional MPLS labels is 167 acceptable in the MPLS data plane. Additionally, the consequences 168 of the reduced MTU caused by inserting the additional MPLS label and 169 control word as well as the fact that the encrypted packet will be 170 larger than the unencrypted packet need to be investigated. 172 It is currently believed that MPLS OS can be deployed progressively 173 without the need to negotiate capabilities outside the key exchange 174 mechanisms described here. This means that no specific walled garden 175 needs to be described in this document. 177 Experimentation and further investigation of the security aspects of 178 these mechanisms are encouraged especially with regard to mitigation 179 of man-in-the-middle attacks. Consideration of the impact of MPLS OS 180 on MPLS Operations, Administration, and Management (OAM) and other 181 MPLS management techniques also needs further exploration. 183 The key functions of MPLS OS described in Section 2.4 are based on 184 an initial set of choices that may be adequate for MPLS OS. However, 185 security knowledge is evolving and it may be advisable to "upgrade" 186 for example to Elliptic Curve Diffie-Hellman (ECDH) [RFC6239], using 187 NIST curves or new curves (such as 25519). Furthermore, alternative 188 key derivation functions could be chosen, or symmetric cipher mode 189 could be used. Note that changing to a symmetric cipher that is 190 faster in software, but less likely to be available in hardware would 191 not be a good change. 193 Section 2.4 also describes the frequency with which keys should be 194 changed. The values described here should be subject to more 195 research and experimentation since key change is fundamental to the 196 actual security of the encryption. 198 Section 4.3.3 defines the input parameters to the key derivation 199 function and includes the LSP identifier. This identifier is only 200 needed if the scope of the key is per LSP. This document is written 201 on that assumption because of the need to rotate the key after a 202 certain number of packets have been transmitted. However, this could 203 be the subject of some investigation since dropping the LSP 204 identifier would simplify the TLV and the computation. It would also 205 address the issue of identifying the LSP in the case of LDP. 207 Section 4.3.3 also specifies that the alt is not used. Further 208 investigation is needed to see whether this input parameter would add 209 value. 211 Note that this experiment uses a special-purpose MPLS label. Since 212 this document is experimental it makes use of an extended special- 213 purpose label from the experimental range. If this work is moved to 214 be published on the standards track, it will be possible to achieve 215 the same function using a simple special-purpose label rather than an 216 extended special-purpose label. 218 1.2. Existing Security Tools for MPLS Data 220 This section is a placeholder for text that needs to be added to 221 describe existing security tools for securing MPLS Data. The text 222 needs to describe the use of IPsec used for the payload of MPLS LSPs, 223 and should also cover the use of link layer security (such as 224 MACsec). 226 >>> TBD 228 2. Principles of Opportunistic Security 230 This section provides an overview of opportunistic security in the 231 context of MPLS. Readers are advised to familiarize themselves with 232 some of the attack vectors discussed in [RFC7258] and with the more 233 general description of opportunistic security as described in 234 [RFC7435]. The text here is intended for the consumption of MPLS 235 experts who may not have a background in security: it is, therefore, 236 tutorial and simplistic in nature. 238 2.1. Why Do We Need Opportunistic Security? 240 To introduce this discussion we start from a basic view of how 241 encryption is typically used in IETF protocols. 243 Say we have two protocol entities, Alice and Bob, and they would like 244 some message "M" sent from Alice to Bob to have confidentiality. 245 Alice needs to send M encrypted with algorithm "E" under some 246 symmetric (e.g., AES) key, "k". Thus Alice wants to send Bob 247 "E(k,M)", but for Bob to be able to understand (i.e., decrypt) the 248 message Alice and Bob both need to agree on the key that will be 249 used: this is called their shared secret. 251 In many IETF protocols, such as the common usage of Transport Layer 252 Security (TLS) S/MIME Cryptographic Message Syntax (CMS) or Pretty 253 Good Privacy (PGP), Alice simply invents a random key "k" and then 254 encrypts that under Bob's public key "Pub-b" and sends Bob both 255 E(Pub-b,k) and E(k,M). (There are lots of other details and other 256 options for how this can be handled, but we ignore those for now.) 257 In such cases, before Alice can send "E(k,M)", she needs to acquire 258 Bob's public key and she needs to be certain that it really is Bob's 259 public key and not Charlie's. That knowledge requires some long-term 260 key management, which is often done using a Public Key Infrastructure 261 (PKI) so that Alice actually stores the public key (Pub-ca) of a 262 Certification Authority (CA), and Bob gets his public key (Pub-b) 263 "certified" by the CA, which means the CA creates a digitally signed 264 data structure "Cert(Pub-ca,Pub-b)". The crucial thing is that 265 Alice, Bob, and a CA need to co-ordinate before Alice and Bob can 266 agree on a key "k", and that process imposes a key-management burden. 268 Doing such key management is clearly quite possible, since TLS and 269 IPsec and other well-deployed technologies depend on it. But, in 270 the case of HTTP/TLS on the public web, we see that only roughly 30% 271 of web sites actually take on this burden, even though the software 272 required is ubiquitous and, at least for 2nd level DNS domains in 273 .com for example, there are CAs who offer free domain-validated 274 certificates. While some of the 70% who don't set up certificates 275 might not actually want confidentiality, there are certainly some who 276 would and arguably many that would benefit from confidentiality, if 277 it just happened out of the box, without an administrator having to 278 do anything. And there are also arguably many other protocols where 279 the same is true. 281 An alternative to the PKI is manual configuration of keys at Alice 282 and Bob. Manual configuration is used in a large number of cases in 283 deployments, however it has a set of issues that make it problematic. 284 These issues include: 285 - the scale of configuration that is needed for a full set of 286 Security Associations (SAs) between all communicating parties 287 - the likelihood of configuration errors 288 - the security vulnerabilities associated with manual keying and 289 unsecured exchange of keys. 291 Opportunistic Security (OS) is a protocol design pattern to achieve 292 encryption between Alice and Bob without requiring key-management 293 through CAs and without relying on manual configuration of keys. 295 2.2. Opportunistic Security at 10,000ft 297 Instead of the "key transport" mechanisms described in Section 2.1, 298 OS aims to use "key agreement". With key management, Alice invents 299 "k" and safely transports it to Bob encrypted with Bob's public key 300 as "E(Pub-b,k)". With key agreement, both Alice and Bob contribute 301 to calculating "k" as follows. 303 Assume that Alice and Bob are using some protocol where they can 304 exchange a few messages in order to agree on the key "k" to use. 305 With a Diffie-Hellman key agreement ("D-H") both Alice and Bob have 306 public and private values, where the private value can be randomly 307 generated, perhaps even once per message "M". They swap the public 308 values, and can then, thanks to the "magic" of Diffie-Hellman, derive 309 a key "k" that nobody else can know. 311 In this way Alice sends Bob "Pub-a" and Bob sends Alice "Pub-b" and 312 at that point both of them can safely calculate a shared secret "k" 313 from those values. And after that Alice can send Bob "E(k,M)". 315 From here on, we change the terminology slightly and refer to Alice 316 as the initiator, with private key "i" and Bob as the recipient, with 317 private key "r" so that our notation is closer to that used in 318 IPsec's Internet Key Exchange Protocol (IKE) on which we model our 319 use of OS. 321 D-H works as follows: Let "p" be well-known large prime number that 322 we use for all modular arithmetic (meaning that "a^b" is actually 323 "(a^b) mod p"), and let "g" be another well-known value (called a 324 generator for the group determined by "p"). Also let Alice and Bob's 325 private values be "i" and "r" respectively. Now, if Alice sends Bob 326 "g^i" as her public value, and Bob similarly sends Alice "g^r" then 327 both of them can easily calculate "g^(i*r)" or "g^ir" but nobody else 328 can, since calculating "x" when only given "g^x" is a computationally 329 hard problem for any "x". Once both Alice and Bob have the value 330 "g^ir" in hand, they can easily derive a value "k" from that using 331 any of a number of well-known key derivation functions (KDFs) such 332 that k = f(g^ir) for a KDF "f". 334 As you can see from the above, Alice and Bob do not need to pre- 335 arrange anything other than "g", "p" and "f", and those can be public 336 information that is used by everyone everywhere (or at least by all 337 participants in a particular deployment). Yet, Alice and Bob have 338 managed to derive a common and private value for a key "k" that they 339 can use to encrypt (and decrypt) "M". 341 This method of using the OS pattern provides strong confidentiality 342 and can be built into any protocol that allows Alice and Bob to 343 occasionally exchange public values. 345 There are also additional advantages to key agreement when compared 346 to key transport. The most important of those is that with key 347 agreement we can easily ensure that k has a property called Perfect 348 Forward Secrecy (PFS). That means that an attacker has to separately 349 attack each key k. In contrast, if we use the key transport 350 approach, then an attacker who somehow accesses Bob's private key 351 "Priv-b" can record lots of traffic and later go back and decrypt all 352 the "E(Pub-b,k)" values that all Alices have ever sent to Bob. With 353 key agreement as described, since both Alice and Bob contribute to 354 the value k, and since Alice and Bob will typically periodically 355 generate new private values i and r (perhaps even for every single 356 M), compromise of one party is far less catastrophic, and an attacker 357 who gets access to one private value gets far less benefit. 359 2.3. What about a Man-in-the-Middle? 361 OS as described so far is vulnerable to Man-in-the-Middle (MITM) 362 attacks. The problem is that Alice does not know that it was 363 really Bob's public value that she received; it could have been 364 Charlie's public value sent by Charlie. And Charlie could also 365 send Bob his public value pretending to be Alice. Now Charlie 366 can share a key with Alice and a key with Bob so that Charlie 367 can sit between Alice and Bob decrypting what he gets from Alice 368 and then re-encrypting it to send to Bob. Neither Alice nor 369 Bob can tell that Charlie is present as a "Man-in-the-Middle" 370 and both Alice and Bob think they are safely exchanging encrypted 371 messages. 373 A MITM attack like that is bad and making a protocol proof against 374 such attacks comes at the cost of the key-management burden described 375 in Section 2.1. Most IETF protocols to date require that such MITM 376 attacks not be feasible. 378 However, despite its potential vulnerability to MITM attacks, OS 379 still has value. This value arises because of the difficulty of 380 inserting a MITM actor, and the cost of processing for the MITM 381 in the case of a very large number of relationships. In 382 particular, where the choice is between no encryption (as has been 383 the case for MPLS to date) and OS, it is clear that using OS offers 384 better (although not the best) security. 386 Consider the case where an attacker taps a link on the path between 387 Alice and Bob. In this case, the attacker can capture every packet 388 between the two parties, and if there is no encryption, can read 389 every message. Furthermore, consider that the attacker could tap a 390 fiber in the core of the network and so capture every packet between 391 a large number of Alices and their corresponding Bobs. In these 392 cases, Charlie can operate as a "passive MITM" since all he has to do 393 is watch the packets. 395 With OS in use, Charlie is forced to be an "active MITM". That is he 396 must engage in the D-H exchange between each pair of Alices and Bobs, 397 and he must must decrypt and encrypt each packet he wants to inspect. 398 This imposes a higher cost and is especially burdensome if he is 399 attempting to do it in parallel for lots of Alice/Bob pairs using 400 lots of different keys and communication sessions. 402 Furthermore, when D-H is in use for OS, management tools can be used 403 to detect the presence of Charlie as a MITM. This is because 404 Charlie has to agree one key "kA" with Alice, and a different key 405 "kB" with Bob. As far as we know, Charlie cannot arrange that kA 406 equals kB because both sides contribute to the key value in the D-H 407 key agreement. That means that if Alice and Bob can check with each 408 other what value of "k" they are using and the values do not match, 409 then they know that Charlie is present. What is more, Alice and Bob 410 can make this check on the value of "k" for any of the "E(k,M)" they 411 ever exchanged. 413 Thus, in the case of a fiber tap where many Alice/Bob pairs are 414 being monitored, it only takes one Alice and Bob to detect the MITM 415 attack for all Alice/Bob pairs to be alerted to the problem. In 416 such cases the cost of detection for Charlie may be even greater than 417 the cost of performing the MITM attack. 419 Hence we conclude that OS can have considerable value when used in 420 MPLS networks. 422 2.4. OS in MPLS Overview 424 The basic requirement for MPLS-OS is that we want to provide a way 425 for two MPLS nodes to do a key exchange and to derive a session key 426 from that to use in MPLS packet encryption. 428 To do that we use a Diffie-Hellman key exchange as outlined in 429 Section 2.2. We model this on IKE [RFC7296] using essentially the 430 same parameters. We feed the shared Diffie-Hellman value, which is 431 g^ir, into a standard KDF that also takes as input an LSP identifier 432 (LSP ID) together with the sending and receiving LSR IDs - where the 433 sending LSR is the point of encryption and the receiving LSR is the 434 point of decryption such that the pair of LSRs define the SA. These 435 additional inputs are used to ensure that we end up with different 436 keys on an LSP even if the same g^i and g^r values are re-used, 437 however it is RECOMMENDED that fresh values of i and r are used each 438 time [RFC4086]. The KDF to be used here is as defined in [RFC5869]. 440 The D-H values used MUST be of at least 2048-bits. Implementations 441 MUST support the 2048-bit modular exponentiation (MODP) group from 442 Section 3 of [RFC3526] and SHOULD support the larger MODP groups from 443 [RFC3526]. 445 This document also defines the mechanism used to derive an identifier 446 for a key (the key-id) from the shared Diffie-Hellman value, which 447 is also based on the KDF output. The key will be used with a 448 symmetric encryption algorithm, such as AEAD_AES_GCM_128 (the 449 default, following [RFC5116]). 451 As with any symmetric block cipher, one should not use the same key 452 for too long. The nonce defined for these keys is derived using 453 a 96 bit counter incremented by one for each encrypted packet. 454 It is critical for security that nonce values MUST NOT be re-used 455 with a given key. (This is an inherent issue with how AES-GCM or any 456 counter mode achieves high performance.) 458 Accordingly, implementations MUST support mechanisms for key change. 460 To support key change, this document defines a way for two LSRs using 461 a key on an LSP to agree a new key and to switch over to using that 462 key when desired. That means that implementations MUST be able to 463 handle at least two keys (old and new) for a given LSP. Once a new 464 key has been agreed then it should be used for sending packets; once 465 encrypted data packets protected with the new key have been 466 successfully received, the old key SHOULD be discarded. Section 4 467 describes how two LSRs agree keys: to agree a new key two LSRs simply 468 run the same key agreement exchange, but this time protected with the 469 old session key as described in Section 4.5. This process can, of 470 course, be repeated any number of times for the same LSP. It is 471 RECOMMENDED that the key on an LSP be changed at least once every 472 day or every 10^6 packets whichever is sooner, and MUST change keys 473 before encrypting 2^64 packets. For an LSP running over a fully- 474 busy 100Gbe interface, we might assume that means roughly 160 475 million packets per second, or roughly 2^44 packets per day. The 476 2^64 limit therefore means changing keys daily in the busiest cases 477 of some of the largest current links capacities. 479 In the event of a key agreement exchange or decryption failure, an 480 alarm MUST be raised to the operator. Default (i.e., node-wide) and 481 per-LSP behavior SHOULD be configurable in this case: actions may 482 include reverting to non-encrypted traffic, re-attempting key 483 exchange, or tearing down the LSP. Note that a simple attack on OS 484 is to tamper with key agreement exchange messages or encrypted 485 packets so that OS fails. Such attacks may be intended to cause the 486 LSP to operate without encryption, so an operator should consider 487 this when setting the behavior in this case. 489 Section 7.1 also discusses a mechanism that allows a pair of LSRs 490 using OS on an LSP to detect that a MITM attack has happened. For 491 this, we simply define a function of the shared secret, which can be 492 logged and later compared. Note that logging a sample of these 493 "witness" values will likely be sufficient to detect pervasive MITM 494 attacks [RFC7258]. As with the key-id, we base this on the same 495 KDF output. 497 We might want to consider deriving the witness value from a separate 498 invocation of the KDF that does not depend on the LSP-specific 499 inputs. The benefit from that would be that the same MITM-detection 500 infrastructure could be used for many protocols. However, that would 501 require standardizing a generic D-H MITM-detection protocol, or at 502 least formats, in order to be useful. We also need to consider what 503 additional information needs to be logged with the witness value so 504 that comparisons can easily be made at scale but without creating new 505 privacy-invasive meta-data. That last is not much of an issue for 506 MPLS-OS, but could be elsewhere. At present we do not intend to go 507 for the generic MITM-detection approach, but it is worth considering. 509 An additional discussion of the applicability of MPLS-OS is found in 510 Section 5. 512 3. MPLS Packet Encryption 514 MPLS packets are encrypted according to the mechanisms described in 515 this section. 517 When an MPLS packet is encrypted, this is indicated by the insertion 518 of a new extended special-purpose label [RFC7274] in the label stack. 519 This is referred to as the MPLS Encryption Label (MEL). The format 520 of the MEL is described in Section 3.1. 522 The MEL MUST have the bottom of stack bit (the S bit) set and MUST be 523 followed by a pseudowire control word [RFC4385]. The format of the 524 control word is described in Section 3.2. 526 The remainder of the MPLS packet is encrypted and cannot be parsed 527 without decryption. It needs to be understood, therefore, that the 528 phrase "bottom of stack" refers to the parsable label stack (i.e., 529 those label stack entries that have not been encrypted) and does not 530 indicate the full label stack of the unencrypted packet. Figures 1 531 and 2 should make this point clear. 533 Implementations MUST support the AEAD_AES_GCM_128 encryption 534 algorithm, as specified in Section 5.1 of [RFC5116], which is the 535 default algorithm as described in Section 4.3 of this document. 537 Note that it is critical that a new nonce is used for every 538 encryption. The nonce is an implicit packet counter. The initial 539 nonce value is derived from the HMAC-based Key Derivation Function 540 (HKDF) output (see Section 4.3.2) at key agreement time and the 541 counter is incremented by one for each packet encrypted on the 542 sending side and by one for each packet successfully decrypted on the 543 receiver side. 545 Although the nonce is not transmitted with the packets, a 16-bit 546 counter carried in the control Word indicates the nonce value modulo 547 65536. This feature allows a receiving node to quickly spot that a 548 packet has been dropped and resynch its own counter in order to be 549 able to continue to decrypt received packets. In the event that the 550 counter cannot be resynchronized or that more than 65536 packet are 551 lost in one batch the receiver will encounter a decryption error. In 552 this case the receiver may report a general decryption error or may 553 attempt to resynchronize by advancing its own counter in units of 554 65536 according to the modulo value in the received packet. Note 555 that incrementing the counter in order to test for decryption failure 556 does generate a potential DoS if, e.g., an attacker decrements the 557 nonce-mod-65536 value. Implementations that do such tests SHOULD 558 maintain a small maximum window size beyond which they will cease 559 attempting to decrypt. It could be that throwing an error might be 560 the more effective response if the packet loss rates are expected to 561 be low enough. 563 It should also be noted that the output from encryption will be 16 564 octets longer than the input. 566 The bottom of stack bit is set in the MEL to stop implementations 567 continuing to search down the label stack (which is encrypted) and 568 attempting to use the data as though it was a valid label stack. The 569 control word is needed because many implementations that find the 570 bottom of stack expect the next bytes to be a control word or 571 protocol indicator. 573 The position of the MEL and control word depend on whether hop-by-hop 574 or end-to-end encryption is being applied. 576 Figure 1 illustrates the format of an example MPLS packet before and 577 after hop-by-hop encryption. The left hand part of the 578 figure shows a normal MPLS packet with a label stack and payload. 579 The bottom label in the stack has the S bit set. The payload is the 580 data carried by the MPLS packet (such as IP) and may be prefixed by a 581 control word. 583 The right hand part of Figure 1 shows the same packet after it has 584 been encrypted. The top of stack is a label with value 15 that 585 indicates that an extended special-purpose label follows. Next comes 586 the MEL with the S bit set. The label value of the MEL is from the 587 experimental range 240-255 and is selected according to the scope of 588 the MPLS OS experiment being run. The MEL is followed by a control 589 word. Everything that follows the control word is the entire 590 original MPLS packet encrypted. 592 ----------- . ----------- 593 | Top Label | . | Label 15 | 594 +-----------+ . +-----------+ 595 | Label | . | MEL S=1 | 596 +-----------+ . +-----------+ 597 | Label S=1 | .| Ctrl Word | 598 +-----------+ +-----------+ 599 | | | | 600 ~ Payload ~ ~ Encrypted ~ 601 | | | | 602 -----------........----------- 604 Figure 1 : The Use of the MEL for Hop-by-Hop Encryption 606 Figure 2 illustrates the format of an example MPLS packet before and 607 after end-to-end encryption. The left hand part of the figure shows 608 a normal MPLS packet with a label stack and payload. The bottom 609 label in the stack has the S bit set and the payload may be prefixed 610 by a control word. The right hand part of the figure shows how the 611 top two labels (or however many labels are needed for end-to-end 612 delivery) remain at the top of the label stack. Then follows label 613 15 to indicate that an extended special-purpose label follows, then 615 ----------- ----------- 616 | Top Label | | Top Label | 617 +-----------+ +-----------+ 618 | Label | | Label | 619 +-----------+. +-----------+ 620 | Label | . | Label 15 | 621 +-----------+ . +-----------+ 622 | Label | . | MEL S=1 | 623 +-----------+ . +-----------+ 624 | Label S=1 | .| Ctrl Word | 625 +-----------+ +-----------+ 626 | | | | 627 ~ Payload ~ ~ Encrypted ~ 628 | | | | 629 -----------........----------- 631 Figure 2 : The Use of the MEL for End-to-End Encryption 633 comes the MEL with S bit set, and a control word. The remainder of 634 the packet is encrypted and contains the rest of the label stack and 635 the payload. 637 3.1. MPLS Encryption Label 639 The MPLS Encryption Label (MEL) is a normal label stack entry 640 carrying an extended special-purpose label with a value from the 641 experimental range 240-255. The format of the label stack entry is 642 defined in [RFC3032] and shown in Figure 3. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Label | TC |S| TTL | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Figure 3 : Format of the MEL Label Stack Entry 652 Label: The value of MEL for this experiment 653 TC: For end-to-end encryption, the value of the TC field SHOULD 654 be set to the value of the unencrypted label stack entry that 655 immediately precedes the MEL. In the case of hop-by-hop 656 encryption, the value of the TC SHOULD be copied from the TC 657 of the first encrypted label if there is a label stack 658 present. Otherwise this field SHOULD be set to all zero 659 (0b000). 660 S: MUST be set to one. 661 TTL: SHOULD be set to two to prevent encrypted packets being 662 accidentally forwarded too far beyond the point of intended 663 decryption. Note that setting to zero might cause a 664 receiver to discard the packet when the MEL becomes top of 665 stack, and setting to one might cause the packet to be sent 666 to the slow path when the MEL becomes the top of the stack 667 even though decryption should be a fast-path function. 669 The sending LSR MAY choose different values for the TTL and TC fields 670 if it is known that label 15 or the MEL will not be exposed as the 671 top label at any point along the LSP (for example, by penultimate hop 672 popping - but see Section 5 for a discussion of MPLS tunnels and 673 penultimate hop popping). 675 3.2. Control Word 677 The control word is inserted after the MEL as described in Section 3. 678 The S bit set to one in the MEL and the presence of the control word 679 helps protect against transit nodes that may perform hashing or 680 inspection of the label stack and payload packet headers when 681 forwarding MPLS packets (for example, to enable ECMP). The control 682 word indicates that the payload is not a protocol that can be 683 meaningfully hashed or inspected. 685 The format of the control word is defined in [RFC4385] and shown in 686 Figure 4. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |0 0 0 0| Flags |FRG| Length | Sequence Number | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Figure 4: Control Word for Encrypted MPLS 696 Flags: The Flags field is treated as a four-bit number. It 697 contains the key-id that identifies the algorithm 698 and key as established through configuration or 699 dynamic key exchange as described in Section 4. 700 FRG: Must be sent as 0, and ignored on receipt. 701 Fragmentation is not used. 702 Length: MUST be sent as 0, and ignored on receipt. 703 Sequence Number: This field contains the packet counter (nonce) for 704 the encryption algorithm and key currently in use 705 modulo 65536. It can be used by a receiver to 706 quickly check that the value of the nonce being used 707 for decryption is likely to be correct as described 708 in Section 3. 710 3.3. Considerations for ECMP 712 As previously stated, the S bit set in the MEL and the presence of 713 the control word prevent implementations from attempting to use the 714 encrypted MPLS packet and its payload to determine a hash value for 715 uses such as ECMP. However, the resultant label stack shown in 716 Figure 2 will probably not provide sufficient entropy for ECMP 717 purposes. 719 In order to increase the entropy, an implementation that inserts an 720 MEL and MEL MAY also insert an Entropy Label Indicator (ELI) and 721 Entropy Label (EL) as defined in [RFC6790] ELI and EL are positioned 722 in the label stack before the MEL as shown in Figure 5. The setting 723 of the fields in the ELI and EL label stack entries are as described 724 in [RFC6790]. 726 The ELI and EL will normally occur immediately before the label 15 727 and MEL pair, but they MAY be placed higher up the label stack. 729 ----------- 730 | Top Label | 731 +-----------+ 732 | Label | 733 ----------- +-----------+ 734 | Top Label | | ELI | 735 +-----------+ +-----------+ 736 | Label | | EL | 737 +-----------+. +-----------+ 738 | Label | . | Label 15 | 739 +-----------+ . +-----------+ 740 | Label | . | MEL S=1 | 741 +-----------+ . +-----------+ 742 | Label S=1 | .| Ctrl Word | 743 +-----------+ +-----------+ 744 | | | | 745 ~ Payload ~ ~ Encrypted ~ 746 | | | | 747 -----------........----------- 749 Figure 5 : The Use of ELI and EL with MEL 751 3.4. Backward Compatibility 753 Keys and encryption algorithms may be configured manually or 754 exchanged dynamically as described in Section 4. These mechanisms 755 provide a preliminary way to protect against a sender encrypting data 756 that the receiver cannot decrypt, however, misconfiguration may lead 757 to a sender using the MEL when the receiver does not support 758 encryption. 760 When a node finds an unknown label at the top of the label stack it 761 must discard the packet as described in [RFC3031]. Therefore, when a 762 receiver discovers label 15 and does not support extended special- 763 purpose labels it will discard the packet. Similarly when a receiver 764 that supports extended special-purpose labels, but does not support 765 the MEL (i.e., does not support encryption) it will discard the 766 packet. (Note that care must be taken if multiple experiments are 767 being carried out in the same network since a different extended 768 special-purpose label must be used for each experiment.) The net 769 result is that when a sender uses encryption in error, all packets 770 that it sends on the LSP will be discarded by the receiver. Note 771 that in this discussion, "the receiver" may be the next hop if single 772 hop encryption is used, or may be the end of the LSP if end-to-end 773 encryption is used. 775 Transit nodes that are not actively participating in the encryption 776 will not inspect the MEL except potentially as part of an ECMP hash, 777 and it should be noted that the use of Special Purpose Labels in 778 hashing is strongly discouraged (see Section 2.4.5.1 of [RFC7325]). 779 This means that transit nodes will not encounter the MEL during 780 normal packet processing and will not discard packets. 782 3.5. MTU Considerations 784 Adding label 15, the MEL, and the Control Word as described above 785 will reduce the available data size by 12 octets. Furthermore, as 786 described in Section 3, the output of the encryption algorithm is 787 at least 16 octets longer than the input. Therefore, the use of 788 encryption reduces the available MTU by at least 28 octets. Other 789 encryption algorithms may result in even greater reductions in the 790 available MTU. 792 When end-to-end encryption is in use this can be considered by the 793 ingress LSR, however, when single-hop encryption is in use the 794 participating LSRs need to advertise this reduction in link MTU 795 so that the packets do not overflow. MPLS packets MUST NOT be 796 fragmented as a result of encryption. 798 3.6. Recursive Encryption 800 The use of MEL and control word described in Section 3 may be applied 801 recursively. That is, the payload of an encrypted MPLS packet may, 802 itself be an encrypted MPLS packet. This may be particularly useful 803 in the case where an MPLS VPN has native MPLS traffic. 805 There are no special considerations except to note that encryption 806 and decryption processing may be burdensome if an LSP and its payload 807 LSP have encryption applied at the same LSR. Additionally, it 808 should be noted that, as described in Section 3.6, each recursive 809 encryption reduces the MTU by 28 octets. 811 4. Key Exchange For Opportunistic Security in MPLS 813 For encryption to be useful both ends of an encrypted session must 814 know which algorithm is in use and which key to use. The mechanism 815 described in Section 3 provides a way to indicate an index into a 816 table of algorithms and keys that can be used to decrypt an encrypted 817 MPLS packet. 819 It is possible that this table has been manually configured or set up 820 using a key exchange protocol such as Internet Key Exchange version 2 821 (IKEv2) [RFC7296]. However, such a process implies a stable security 822 association between encrypter and decrypter of MPLS packets. While 823 such a stable association is entirely consistent with the concept of 824 OS, OS nonetheless calls for a more dynamic key agreement method. 826 This section provides a mechanism for adjacent MPLS LSRs, or for a 827 pair of LSRs at opposite ends of an MPLS LSP, to dynamically 828 exchange keys and algorithm identifiers so that encryption may be 829 applied opportunistically. 831 The mechanism uses message exchanges in the MPLS Generic Associated 832 Channel (G-ACh) [RFC5586] as part of the MPLS Generic Associated 833 Channel (G-ACh) Advertisement Protocol (GAP) [RFC7212]. This channel 834 is in-band with an LSP and may be used to carry messages between 835 neighbors or between the end points of the LSP. A type field within 836 the common message header, the Associated Channel Header (ACH), is 837 used to indicate the type of message carried. 839 Nodes that receive G-ACh messages and do not understand them, or 840 nodes that understand the G-ACh but do not recognize the ACH message 841 type drop the packets as described in [RFC5586]. 843 Note that this mechanism may benefit from encryption that is already 844 in use on an LSP. Thus key changes using this mechanism can be made 845 using encrypted messages. 847 4.1. Initiating MPLS-OS 849 This document assumes that the use of MPLS-OS is initiated by the 850 upstream of a pair of LSRs (either a pair of adjacent LSRs on an LSP, 851 or a pair of LSP end points). That is, the upstream LSR send the 852 first G-ACh that initiates key exchange. The key that is generated 853 after the exchange is then used to encrypt traffic travelling in the 854 direction between initiating and responding LSRs: that is, from 855 upstream to downstream LSR. 857 In the case of a bidirectional LSP, each direction is treated 858 separately. That is, "upstream" refers to the direction of traffic 859 flow, and not to any signaling that is used to establish the LSP. 860 Thus, it is possible that a bidirectional LSP uses MPLS-OS on none, 861 either one, or both of the directions of traffic flow for the LSP. 862 But it is important to note that the keys used are different in each 863 direction, each being generated and exchanged through a separate 864 instance of the procedures described in this document. Note that the 865 input parameters for key derivation listed in Section 4.3.3 show LSP 866 identifier, initiator LSR identifier, and responder LSR identifier as 867 three of the ordered list of pieces of information used by the key 868 derivation function. In the case of a bidirectional LSP, the LSP 869 identifier will be the same in each direction, and the two LSR 870 identifiers will be the same, but the LSR identifiers will be used in 871 the reverse order at the two end points of the MPLS-OS exchange and 872 this will reduce the chance of the same key being used in each 873 direction. 875 Note also that in the case of a pair of unidirectional LSPs in 876 reverse directions between a pair of LSRs there should be no 877 relationship between the keys used on each LSP even if there is a 878 tight coupling between the LSPs such as might be the case for 879 associated bidirectional LSPs [RFC7551]. The key derivation function 880 will use different LSP identifiers as well as using the LSR 881 identifiers in a different order. 883 4.2. MPLS G-ACh Advertisement Protocol for Key Exchange 885 GAP defines messages exchanged in G-ACh on a common Associated 886 Channel Type code point (0x0059) [RFC7212]. The application for 887 which the messages are exchanged is defined by the Application ID 888 field carried in the Applications Data Block (ADB). MPLS OS 889 capability notification and key exchange uses the GAP Application ID 890 (0x0000) defined by [RFC7212] and a new ADB TLV for MPLS OS. 892 Implementations that do not support GAP will discard received packets 893 with this Associated Channel Type as described in [RFC5586]. 894 Implementations that support GAP but that do not support key exchange 895 will discard received packets with this ADB TLV as described in 896 [RFC7212]. Either of these discards will result in no dynamic key 897 exchange, but other key definitions are still supported (such as 898 manual configuration) and may be used to construct a table of 899 algorithms and keys that can be used to achieve MPLS encryption using 900 the mechanisms described in Section 3. 902 4.3. Key Exchange Protocol 904 4.3.1. Communication Channels 906 The key exchange protocol described in this document uses a D-H 907 exchange that assumes a bidirectional communication channel. GAP is 908 designed to run over a unidirectional channel and uses normal IP 909 forwarding for return path messages with an optimization to use the 910 return path of a bidirectional LSP. However, LSPs in packet networks 911 are usually unidirectional. That means that, while the key exchange 912 messages can be sent on the LSP in one direction, a channel needs to 913 be established for the return messages. 915 This document uses a process similar to that defined for MPLS LSP 916 Ping [RFC4379] and [RFC7110], and that described to indicate a return 917 path for MPLS performance measurement in 918 [I-D.ietf-mpls-pm-udp-return]. That is, the forward message is sent 919 on the LSP and includes the identity of the return path communication 920 channel. The return path may be indicated as a UDP communication 921 over IP, as an LSP running in the opposite direction, or as the 922 reverse direction of a bidirectional LSP. 924 Note that the GAP messages defined in [RFC7212] include a TLV that 925 enables authentication. This feature SHOULD be used if possible, but 926 it is in the nature of opportunistic security that the necessary 927 security association might not exist. In this case the ability to 928 tamper with the instructions that select a return path may provide a 929 mechanism that makes MITM attacks easier. An implementation that 930 initiates key exchange for MPLS Opportunistic Security MUST verify 931 that the response messages are received on the expected return path 932 channel and SHOULD raise an operator alert if the channel is 933 unexpected. 935 4.3.2. Key Exchange Messages 937 The format of a GAP message is described in [RFC7212]. When used for 938 key exchange the GAP message includes an ADB with the fields set as 939 follows. 941 Application ID is set to 0x0000. 943 Element Length is set to the total length in octets of this ADB 944 including the Application ID and this field. 946 Lifetime field SHOULD be set to zero and MUST be ignored. 948 A key exchange ADB MUST include a Key Exchange TLV as shown in 949 Section 4.3.3. The ADB and MAY also include an Authentication TLV as 950 described in [RFC7212] to provide authentication and integrity 951 validation for a GAP message (see Section 4.5). Additionally, the 952 ADB MAY include a Source TLV as described in [RFC7212] and discussed 953 in Section 4.4. 955 4.3.3. Key Exchange TLV 957 A session key is to be established between an initiator (Alice) and 958 a recipient (Bob). The D-H public value for Alice is g^i and for 959 Bob, g^r. The shared Diffie-Hellman value is g^ir. g^ir is 960 represented as a string of octets in big endian order padded with 961 zeros if necessary to make it the length of the modulus. Both g^i 962 and g^r will be 2048 bits long, if the Diffie-Hellman modulus is 2048 963 bits long. 965 The Key Exchange TLV is modelled on that from Section 3.4 of 966 [RFC7296] with the addition of information to identify the LSP and 967 its return path, and is encoded as shown in Figure 6. 969 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Type | Reserved | Length | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 |D|Rsvd | Return| Path Identifier | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | LSP-ID | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Algorithm | Group Num | | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 980 | | 981 ~ D-H Public Value ~ 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 Figure 6 - Key Exchange Message TLV 987 Type is set to TBD1 to indicate that this is a Key Exchange TLV 989 The Reserved and Length fields are defined in [RFC7212]. 991 The flag D denotes the direction of the message, '0' indicates a 992 message from initiator (Alice) to recipient. '1' indicates the 993 reverse direction. 995 The Rsvd bits are reserved. They SHOULD be set to zero and ignored 996 on receipt. 998 The Return field is used on a message from the initiator to indicate 999 the type of return path to be used for messages from the responder. 1000 The Path Identifier field is interpreted in this context. Possible 1001 values are as follows: 1003 0 The reverse path of a bidirectional LSP is to be used for the 1004 response. Used on a message from an initiator. 1005 1 The reverse path messages are to be sent encapsulated in UDP. 1006 Used on a message from an initiator. 1007 2 Any LSP between the recipient and the initiator may be used. 1008 3 Any LSP between the recipient and the initiator that is already 1009 using MPLS-OS may be used. 1010 4 The reverse path messages are to be sent on a specific LSP. 1012 All other values are undefined and MUST be processed as an 1013 encoding error as described in Section 4.3.4. Similarly, if the 1014 value zero is used on a unidirectional LSP then it MUST be handled 1015 as an encoding error. 1017 The Path Identifier is interpreted in the context of the Return 1018 field. The field only has meaning on messages from the initiator and 1019 SHOULD be ignored on responses. If the Return is set to the 1020 following values, the Path Identifier has the following meaning: 1022 0 In this case the Path Identifier field has no meaning and SHOULD 1023 be ignored. 1024 1 The Path Identifier field contains a UDP port number from the 1025 dynamic port range that the initiator will listen on for a 1026 response. 1027 2 In this case the Path Identifier field has no meaning and SHOULD 1028 be ignored. 1029 3 In this case the Path Identifier field has no meaning and SHOULD 1030 be ignored. 1031 4 The Path Identifier field contains an LSP-ID that must be used 1032 for reverse path messages. 1034 See Section 4.4 for more discussion of return paths. 1036 The LSP-ID parameter indicates the LSP to which this key exchange 1037 applies. On messages from initiator to recipient this field MUST be 1038 set to the LSP on which the message flows and any mismatch MUST be 1039 treated as an encoding error (Section 4.3.4). On messages from 1040 recipient to initiator, this value MUST be copied from the received 1041 message and an initiator that cannot match the message and LSP-ID to 1042 a message that it previously sent MUST treat the situation as an 1043 encoding error. 1045 The Algorithm field is a one octet field that specifies both the KDF 1046 to use and the symmetric algorithm to be used for data packet 1047 encryption. A registry for values of this field is defined in 1048 Section 8.2. The value 0 is used to indicate the default KDF and 1049 symmetric encryption mode. An implementation receiving a value for 1050 an Algorithm it does not support MUST treat the case as an encoding 1051 error as described in Section 4.3.4. All implementations MUST 1052 support the default KDF. Note that since implementation of 1053 encryption and decryption is likely to be implemented in hardware for 1054 reasons of data throughput performance, the introduction of new 1055 algorithms may be bound by firmware or even hardware upgrades. 1057 The Diffie-Hellman Group Num is from [RFC3526], so the group number 1058 for 2048 MODP is decimal 14. Note that this is a one octet field, 1059 but is two octets in the [RFC7296] equivalent. This is not an issue 1060 because there are only 30 MODP groups defined at present and new 1061 groups are not added frequently. 1063 The D-H public value will contain g^i or g^r depending on the 1064 direction (i.e., the setting of the D flag) and is in big endian 1065 order. 1067 The length of the Diffie-Hellman public value for MODP groups MUST be 1068 equal to the length of the prime modulus over which the 1069 exponentiation was performed, prepending zero bits to the value if 1070 necessary. 1072 Once both sides have derived g^ir they need to feed that and the 1073 other inputs described in Section 2.4 into the KDF indicated by the 1074 algorithm field. With the default algorithm (value zero), the KDF to 1075 be used is HKDF as specified in [RFC5869]. 1077 The parameters for the use of HKDF are: 1079 Hash: SHA-256 1081 Salt: Not used 1083 Skip: Do not skip 1085 Info: The catenation of a fixed string indicating use of MPLS-OS, 1086 with the value "MPLS-OS", the first 32 bits of the key 1087 exchange message, with the D flag set to 0, plus the LSP 1088 ID and the sender and receiver LSR IDs in that order. That 1089 is: 1091 MPLS-OS||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID 1093 L: The output length in bits is 272. 1095 The fixed string "MPLS-OS" is used as an input here to prevent 1096 potential cross-protocol attacks. Those might otherwise be 1097 possible if this mechanism were to be copied in other protocols. 1098 (If copying this mechanism for any reason, then a different 1099 fixed string value should be used.) 1101 LSP-ID is a unique identifier shared between the initiator and 1102 receiver (Alice and Bob) that uniquely identifies the LSP. 1104 [[If RSVP-TE is used for signaling, the LSP-ID is known along the LSP 1105 and at the two end points. Similarly, the LSP-ID is known if the 1106 LSP is manually configured. It is not so clear how the LSP-ID is 1107 known for LSPs established using LDP, although possibly we could use 1108 the FEC as defined for RFC 4379 and its extensions.]] 1110 i-LSR-ID and r-LSR-ID are the LSR-IDs of the initiator and receiver 1111 respectively (Alice and Bob), where an LSR-ID is the 32 bit, globally 1112 unique identifier of the LSR as described in [RFC5036] and [RFC4990]. 1114 superior security. 1116 The default encryption algorithm, AEAD_AES_GCM_128, specified in 1117 Section 3, requires a 128 bit session key. 1119 The 272-bit HKDF output is the catenation of the session key, the 1120 key-id, the witness value and the high-order 16 bits of the initial 1121 nonce value in that order. That is the session key is the leftmost 1122 128 bits of the HKDF output. The key-id is the next 4 bits, the 1123 witness value is the next 124 bits and the last 16 bits are the 16 1124 most significant bits of the initial nonce value. The low order 64 1125 bits of the initial nonce value are set to zero before the first 1126 call to the AES-GCM encryption function. The key-id is carried in 1127 encrypted packets as described in Section 3.2. 1129 Note that a 4 bit key-id is adequate in a system where, for any one 1130 LSP there is one active key and one new or replaced key. There might 1131 also be more than one algorithm, and it is possible that new keys 1132 need to be pipelined if roll-over is frequent. In the case that a 1133 newly-generated key-id is already in use, the key-id value is 1134 repeatedly incremented (modulo 16) until an unused value is found. 1135 If all 16 values are already in use, the key derivation function 1136 should not be executed. 1138 4.3.4. Encoding Errors 1140 Unknown values in received key Exchange TLVs MUST be treated as 1141 encoding errors. All messages that constitute encoding errors MUST 1142 be silently discarded. That is, such errors MUST NOT cause response 1143 messages to be sent since those messages could be used as part of an 1144 attack to determine the capabilities of an LSR. 1146 An LSR SHOULD log such errors and notify the operator. However, care 1147 is needed even in these actions since they may be externally visible. 1149 4.4. Indicating the Return Path 1151 The key exchange for MPLS-OS requires a two-way exchange of messages. 1152 The Return field of the Key Exchange TLV indicates the reverse path 1153 to use for key exchange messages relevant to a particular LSP. 1155 Whenever the LSP being secured is bidirectional, the same LSP SHOULD 1156 be used for reverse path messages. Otherwise, the initiator selects 1157 the communication channel as described in Section 4.3.3. 1159 If UDP is being used and it may be unclear to what address the 1160 messages should be sent, the initiator MUST include a Source Address 1161 TLV [RFC7212] to provide this information. 1163 Operators should consider the security implications of the return 1164 path. The use of an already-secured LSP (Return type 3) may provide 1166 Implementations MUST make the choice of return path request sent by 1167 an initiator available as a configuration option. As noted in 1168 Section 4.3.1, the fact that the the initial GAP messages might not 1169 be protected means that there is the potential to tamper with the 1170 instructions that select a return path. This could be used as a 1171 vector for MITM attacks. To protect against this, an implementation 1172 that initiates key exchange for MPLS Opportunistic Security MUST 1173 verify that the response messages are received on the expected return 1174 path channel and SHOULD raise an operator alert if the channel is 1175 unexpected. In these circumstances an implementation MAY be 1176 configured to abort establishment of MPLS-OS although, since that in 1177 itself is an attack vector, it is RECOMMENDED that implementations 1178 continue toward the use of MPLS-OS while notifying the operator. 1180 4.5. Protecting the Key Exchange Protocol Messages 1182 GAP includes an Authentication TLV that can be used to protect GAP 1183 messages as described in [RFC7212]. If there is already an SA 1184 between the initiator and recipient this TLV SHOULD be used. 1185 However, it is probable with MPLS-OS that no such SA exists and the 1186 point of the mechanisms described in this document is to exchange 1187 keys in that case, therefore, it is quite likely that the 1188 Authentication TLV cannot be used on the first GAP exchanges. 1190 As described in Section 2.4, once one key exchange has been 1191 successfully completed, further key exchanges should be protected 1192 using a previous key. This is simply achieved since key exchange 1193 messages are, themselves, carried in MPLS packets on the LSP and may 1194 be subject to encryption exactly as any other packet. 1196 Furthermore, once keys have been established, they may also be used 1197 in the GAP Authentication TLV. 1199 5. Applicability of MPLS Opportunistic Security 1201 MPLS-OS provides another tool in the security and privacy toolkit. 1202 It is not a panacea and does not solve (nor is it intended to solve) 1203 all security or privacy problems. In particular, the use of MPLS-OS 1204 does not protect user-data end-to-end that might be better secured 1205 using encryption at the IP layer or at higher layers. 1207 As noted throughout this document, the intention of OS in MPLS is to 1208 allow one LSR to enable encryption between itself and its neighbor, 1209 or between itself and the other end of an LSP, in a dynamic and un- 1210 planned way. This can have benefits in a number of scenarios where 1211 the network that generates MPLS traffic transmits it over another 1212 network (for example, carrier's carrier, or some deployments of 1213 enterprise network). Additionally, the use of MPLS-OS might allow a 1214 service provider to offer a secure edge-to-edge service for a variety 1215 of applications ranging from VPNs through pseudowires and where the 1216 payload traffic might not always be IP. Lastly, in some non- 1217 traditional carriers the user data belongs to the operator or is the 1218 direct responsibility of the operator (for example, in data centers, 1219 or in large-scale private networks). 1221 As with all security mechanisms, there is a trade-off between a 1222 number of factors. On one side is the completeness of the security 1223 of the user-data, and on the other side is the complexity of 1224 configuring and managing the necessary security associations. 1225 Furthermore, while mechanisms closer to the end-user than MPLS-OS 1226 (for example, TLS and IPsec in tunnel mode) provide better security 1227 for user-data by virtue of not transmitting the data across any 1228 network hops without it being encrypted, such mechanisms often 1229 expose more metadata for inspection by snoopers within the network. 1231 Additionally, while a variety of per-link encryption mechanisms exist 1232 and could be used to guard against attacks such as fiber taps, those 1233 approaches do not protect against subverted nodes (i.e., routers) on 1234 the path since, by definition, per-link encryption does not protect 1235 packets once they come off the link. MPLS-OS in the end-to-end LSP 1236 mode protects packets on the links and as they cross transit routers. 1238 Nevertheless, it is not the purpose of this document to recommend the 1239 use of MPLS-OS to the exclusion of all other encryption techniques. 1240 As already mentioned, MPLS-OS is offered as another tool in the tool 1241 kit and users as well as network operators are strongly advised to 1242 consider using a variety of tools to achieve the level of security 1243 and privacy that they desire. 1245 Note that, in order that OS can be used, one end of a peering 1246 (neighbor or LSP end) must decide to attempt OS and the other end 1247 must support it. This can be determined by the message exchanges 1248 described in Section 4.3 since if one peer does not send a key 1249 exchange message then encryption will not be used, and if the other 1250 peer does not respond then it is unwilling or unable to decrypt 1251 messages. 1253 MPLS-OS should be applicable to all forms of MPLS. That is, it should 1254 be possible to use it in RSVP-TE systems, in LDP systems, and in 1255 MPLS-TP systems (by which we mean those that have manually configured 1256 LSPs). Equally, it should work for point-to-point (P2P) and 1257 multipoint-to-point (MP2P) uses of MPLS because there is a simple 1258 relationship between the sender (encrypter) and the receiver 1259 (decrypter) in both cases. In the MP2P case, the sender's identity 1260 can be extracted from the key identifier and there are considered to 1261 be enough key identifiers to allow an arbitrary number of senders on 1262 the LSP. There will, however, be the need for the receiver to hold OE 1263 state (keys, packet counters) for each sender which may be a 1264 significant amount of data for an MP2P LSP (although no more than if 1265 the same LSP were replaced by multiple P2P LSPs). Additionally, it 1266 should be noted that not only will each sender on an MP2P LSP have a 1267 different key, but each may separately decide whether to encrypt data 1268 or not. 1270 At this time it is not certain whether MPLS-OS can be applied to a 1271 point-to-multipoint (P2MP) or a multipoint-to-multipoint LSP in its 1272 entirety because packet replication cannot handle the necessary key 1273 conversions for each receiver. However, MPLS-OS can certainly be 1274 applied to individual hops on these LSPs. Further work is needed to 1275 determine whether non-branching multi-hop segments of P2MP and MP2P 1276 LSPs can also be protected using MPLS-OS. 1278 5.1. Tunnel MPLS Packets 1280 Note that in the case of tunneling of MPLS packets in another 1281 technology (such as MPLS-in-UDP [RFC7510]) there are two approaches 1282 that are viable: 1284 - The payload of the encapsulation (i.e., the entire MPLS packet) can 1285 be encypted using the mechanisms described in this document without 1286 any changes. Any payload identifier in the encapsulation header 1287 can remain set to "MPLS" since the encrypted packet is always just 1288 an MPLS packet. 1290 - The encryption mechanisms present in the encapsulating technology 1291 can be used without any need to use the mechanisms described in 1292 this document. 1294 In some cases that processing of one label on the label stack depends 1295 on the values contained in the previous label stack entry. For 1296 example, in the "Pipe Model" [RFC3270], the Diff-Serv treatment of 1297 the packet that is forwarded beyond the end of the tunnel depends on 1298 the setting of the TC field in the previous label stack entry. This 1299 requires that when a label is popped, the value of the TC field in 1300 the label stack entry is cached for use while forwarding. In the 1301 case that the next label on the stack is the MEL, decryption of the 1302 rest of the packet is required, and this caching would be a little 1303 more complicated to implement. This situation is mitigated by 1304 setting the TC field of the label stack entry that contains the MEL 1305 to the value from the preceding label stack entry as described in 1306 Section 3.1. 1308 The "Short Pipe Model" [RFC3270] can be handled using a combination 1309 of the above technique and the procedures described in the next 1310 section. 1312 5.2. Penultimate Hop Popping 1314 In penultimate hop popping (PHP) a label is removed from the label 1315 stack of a packet one hop before the end of the LSP. The packet is 1316 forwarded as though it was still carried on the LSP, but the label 1317 stack entry for the LSP is removed. Sometimes we say that packet uses 1318 the "implicit null label". 1320 When there are additional subsequent labels on the label stack, this 1321 has no impact on the use of the mechanisms described in this 1322 document. It is possible that after PHP the MEL will become the top 1323 label in the stack meaning that the received packet may encounter the 1324 MEL as te top label. This has implications for the setting of the TC 1325 and TTL fields in the MEL label stack entry as described in Section 1326 3.1. 1328 However, in some cases of PHP the popped label is the bottom of the 1329 label stack and the packet after the popped label is some non-MPLS 1330 payload protocol (such as IPv6). PHP is used specifically because 1331 the receiving interface does not have MPLS capabilities in the 1332 forwarding plane. In this situation the packet is identified within 1333 the link encapsulation on the final hop by its payload protocol type 1334 (such as IPv6). If MPLS-OS is used this situation will change 1335 because even when the final label is stripped using PHP there will 1336 remain a MEL entry in the label stack. Therefore the packet will 1337 need to be identified as "MPLS" in the link encapsulation on the 1338 final hop, yet the receiver might not be capable of handling MPLS 1339 packets. 1341 This problem can be approached in two ways: 1343 - The penultimate hop may note the presence of the MEL during PHP 1344 and attempt to remove the MEL as well. This is unlikely to be 1345 successful as the encryption negotiation has been conducted 1346 between the end points of the LSP and the penultimate hop is not 1347 aware of the keys or algorithms needed for decryption. 1349 Furthermore, this approach would leave the packet unencrypted on 1350 its final hop which may be counter to the intent of the LSP end 1351 points. 1353 - The end point of the LSP should recognize that it cannot have both 1354 MPLS-OS and PHP. Indeed, in agreeing to the use of MPLS-OS the end 1355 point is making a statement about its ability to handle the MEL and 1356 so it can choose: 1358 - to request PHP and allow the penultimate hop to set the payload 1359 indicator of the link encapsulation header to "MPLS"; or 1361 - to not request PHP. 1363 6. Security Considerations 1365 6.1. Security Improvements 1367 See Section 2.1. 1369 6.2. Applicability 1371 See Section 5. 1373 6.3. Continued Vulnerabilities 1375 The mechanisms described in this document do not provide protection 1376 against certain types of MITM attacks. For example, the key exchange 1377 protocol in Section 4.3 will not detect if key exchange messages or 1378 their responses are intercepted and discarded such that the 1379 initiating peer believes that encryption is not supported. 1380 Similarly, those messages may be tampered with such that a receiver 1381 cannot determine the correct mapping of table index to algorithm and 1382 key when an encrypted packet is received. Furthermore, the MEL in an 1383 MPLS packet is not protected and may be overwritten such that a 1384 receiver is unable to decrypt the packet. 1386 See Section 7.1 for a discussion of how active MITM attacks can be 1387 detected. 1389 6.4. New Security Considerations 1391 If a pair of LSRs do not do the key exchange before sending any data 1392 packets on the LSP then those first packets will not be protected by 1393 OS and hence will be available to a monitor. 1395 If a MITM can prevent the OS key exchange from completing, e.g. 1396 via deleting messages or changing bits in messages, and if the LSRs 1397 continue to send data regardless then those data packets will be 1398 available to a monitor. That is, in simple terms, a MITM attacker is 1399 able to prevent OS from being used through a very simple attack, and 1400 the only options for the end points in this situation are to send no 1401 data or to send data in the clear. Again, it should be pointed out 1402 that this occurrence is not worse than not running OS at all, but has 1403 the benefit of being detectable by end points. See Section 2.4 and 1404 Section 7.1 for a description of how alarms should be raised in these 1405 circumstances. Furthermore, Section 4.3.1 and Section 4 describe how 1406 the return path for key exchange messages might be hijacked to better 1407 facilitate MITM attacks and indicates how the initiator of MPLS-OS 1408 can detect this and what actions it should take. 1410 Thus, as been previously noted, OS is not a cure for all ills or a 1411 prevention against all attacks, but it does offer a way to increase 1412 security in some circumstances. 1414 7. Manageability Considerations 1416 As described in Section 2.4 node-wide and per-LSP behavior SHOULD be 1417 configurable to describe the action where key agreement exchange or 1418 packet decryption fails. In any case, such events MUST trigger 1419 alarms to the operator. 1421 7.1. MITM Detection 1423 Section 2.4 introduces the concept of a function of the shared 1424 secret that can be compared by two LSRs that are using OS to see 1425 whether they are victims of an active MITM attack. 1427 Section 4.3 describes how a witness value is derived for the 1428 default KDF, HKDF. 1430 The participating LSRs can simply log this value plus the LSP 1431 and LSR IDs from time to time and a management application can 1432 compare the values. If they are different for the same LSP ID, 1433 then an active MITM attack has taken place. 1435 It needs to be carefully noted that the management channel used to 1436 log or otherwise compare the witness values from the two LSRs MUST be 1437 secure. It is likely that routers use relatively high security 1438 management channels for configuration and other management 1439 operations. 1441 8. IANA Considerations 1443 8.1. GAP Key Exchange TLV 1445 IANA maintains a registry called "Generic Associated Channel (G-ACh) 1446 Parameters" with a sub-registry called "G-ACh Advertisement Protocol 1447 Application Registry" from which new assignments may be made through 1448 the "IETF review" allocation policy [RFC5226]. IANA is requested to 1449 make a new allocation as follows: 1451 Value | Description | Reference 1452 ------+-------------------------------------------------+----------- 1453 TBD1 | Opportunistic Key Exchange Protocol for MPLS | [This.ID] 1455 8.2. Key Derivation Functions and Symmetric Algorithms 1457 IANA maintains a registry called "Generic Associated Channel (G-ACh) 1458 Parameters". IANA is requested to create a new sub-registry called 1459 "G-ACh Advertisement Protocol: MPLS Encryption Algorithms Registry" 1460 with new values to be assigned through "IETF Review" as defined in 1461 [RFC5226]. 1463 The available range is 0 - 255. 1465 IANA is requested to record the following information and create an 1466 initial entry as follows: 1468 Value | Key Derivation Function | Symmetric Algorithm | Reference 1469 ------+-------------------------+---------------------+----------- 1470 0 | HKDF | AEAD_AES_GCM_128 | [This.I-D] 1471 1-255 | Unassigned | | 1473 9. Acknowledgements 1475 Many thanks to Alia Atlas for detailed discussion of the implications 1476 and mechanisms of MPLS opportunistic security. Thanks also to Ron 1477 Bonica for encouraging this work, to Sean Turner and Stewart Bryant 1478 for early review, and to Jeff Haas, Eric Rosen, and Ross Callon for 1479 discussions. Thanks for MPLS Review Team comments from Mach Chen and 1480 Lizhong Jin, and to Charlie Kaufman for review comments. 1482 Additional thanks to Andy Malis and Danny McPherson for advice about 1483 the use of the Control Word. 1485 10. References 1487 10.1. Normative References 1489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1490 Requirement Levels", BCP 14, RFC 2119, March 1997. 1492 [RFC3526] Kivinen, T., and M. Kojo, "More Modular Exponential (MODP) 1493 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1494 RFC 3526, May 2003. 1496 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1497 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1498 Use over an MPLS PSN", RFC 4385, February 2006. 1500 [RFC5116] D. McGrew, "An Interface and Algorithms for Authenticated 1501 Encryption", RFC 5116, January 2008. 1503 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1504 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1505 May 2008. 1507 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1508 Associated Channel", RFC 5586, June 2009. 1510 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1511 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1513 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1514 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1515 RFC 6790, November 2012. 1517 [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 1518 Associated Channel (G-ACh) Advertisement Protocol", RFC 1519 7212, June 2014. 1521 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 1522 and Retiring Special-Purpose MPLS Labels" RFC 7274, 1523 June 2014. 1525 10.2. Informative References 1527 [I-D.ietf-mpls-pm-udp-return] 1528 Bryant, S., Sivabalan, S., and S. Soni, "MPLS Performance 1529 Measurement UDP Return Path", draft-ietf-mpls-pm-udp- 1530 return, work in progress. 1532 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1533 Label Switching Architecture", RFC 3031, January 2001. 1535 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1536 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1537 Encoding", RFC 3032, January 2001. 1539 [RFC3270] Le Faucheur, F. (Ed), "Multi-Protocol Label Switching 1540 (MPLS) Support of Differentiated Services", RFC 3207, May 1541 2002. 1543 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1544 Requirements for Security", BCP 106, RFC 4086, June 2005. 1546 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 1547 2005. 1549 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1550 RFC 4303, December 2005. 1552 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1553 Label Switched (MPLS) Data Plane Failures" RFC 4379, 1554 February 2006. 1556 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 1557 Addresses in Generalized Multiprotocol Label Switching 1558 (GMPLS) Networks", RFC 4990, September 2007. 1560 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1561 Specification", RFC 5036, October 2007. 1563 [RFC6239] K. Igoe, "Suite B Cryptographic Suites for Secure Shell 1564 (SSH)", RFC 6239, May 2011. 1566 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and Delord, S., 1567 "Return Path Specified Label Switched Path (LSP) Ping", 1568 RFC 7110, January 2014. 1570 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring 1571 Is an Attack", BCP 188, RFC 7258, May 2014. 1573 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and 1574 T. Kivinen, "Internet Key Exchange Protocol Version 2 1575 (IKEv2)", STD 79, RFC 7296, October 2014. 1577 [RFC7325] C. Villamizar, Ed., "MPLS Forwarding Compliance and 1578 Performance Requirements", RFC 7325, August 2014. 1580 [RFC7435] V. Dukhovni, "Opportunistic Security: Some Protection Most 1581 of the Time", RFC 7435, December 2014. 1583 [RFC7510] X. Xu et al., "Encapsulating MPLS in UDP", RFC 7510, April 1584 2015. 1586 [RFC7551] Zhang, F., Jing, R., and R. Gandhi, "RSVP-TE Extensions 1587 for Associated Bidirectional Label Switched Paths (LSPs)", 1588 RFC 7551, May 2015. 1590 Authors' Addresses 1592 Adrian Farrel 1593 Juniper Networks 1595 EMail: adrian@olddog.co.uk 1597 Stephen Farrell 1598 Trinity College Dublin 1599 Dublin, 2 1600 Ireland 1602 Phone: +353-1-896-2354 1603 Email: stephen.farrell@cs.tcd.ie