idnits 2.17.1 draft-farrelll-mpls-opportunistic-encrypt-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 9, 2014) is 3759 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 5996 (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 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 5 Expires: July 9, 2014 S. Farrell 6 Trinity College, Dublin 7 January 9, 2014 9 Opportunistic Encryption in MPLS Networks 11 draft-farrelll-mpls-opportunistic-encrypt-00.txt 13 Abstract 15 This document describes a way to apply opportunistic encryption 16 between adjacent nodes on an MPLS Label Switched Path (LSP) or 17 between end points of an LSP. It explains how keys may be exchanged 18 to enable the encryption, and indicates how key identifiers are 19 exchanged in encrypted MPLS packets. Finally, this document 20 describes the applicability of opportunistic encryption in MPLS 21 networks with an indication of the level of improved security as well 22 as the continued vulnerabilities. 24 This document does not describe security for MPLS control plane 25 protocols. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 Copyright Notice 44 Copyright (c) 2014 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 Notation 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction ................................................... 3 66 2. Principles of Opportunistic Encryption ......................... 4 67 2.1 Why Do We Need Opportunistic Encryption? ..................... 4 68 2.2 Opportunistic Encryption at 10,000ft ......................... 5 69 2.3 What about a Man-in-the-Middle? .............................. 6 70 2.4 OE in MPLS Overview ........................................... 7 71 3. MPLS Packet Encryption ......................................... 9 72 3.1. Opportunistic Encryption Label Indicator .................... 11 73 3.2. Opportunistic Encryption Label .............................. 11 74 3.3. Control Word ................................................ 12 75 3.4. Considerations for ECMP ..................................... 13 76 3.5. Backward Compatibility ...................................... 13 77 3.6. MTU Considerations .......................................... 14 78 3.7. Recursive OE ................................................ 14 79 4. Key Exchange For Opportunistic Encryption in MPLS ............. 15 80 4.1. Associated Channel for Key Exchange ......................... 15 81 4.2. Key Exchange Protocol ....................................... 16 82 4.3. Protecting the Key Exchange Protocol Messages ............... 18 83 5. Applicability of MPLS Opportunistic Encryption ................ 18 84 6. Security Considerations ....................................... 18 85 6.1. Security Improvements ....................................... 18 86 6.2. Continued Vulnerabilities ................................... 19 87 6.3. New Security Considerations ................................. 19 88 7. Manageability Considerations .................................. 19 89 7.1. MITM Detection .............................................. 19 90 8. IANA Considerations .......................................... 20 91 8.1. Opportunistic Encryption Label Indicator .................... 20 92 8.2. Pseudowire Associated Channel Types ......................... 20 93 8.3. Key Derivation Functions and Symmetric Algorithms ........... 21 94 9. Acknowledgements ............................................. 21 95 10. References .................................................. 21 96 10.1. Normative References ...................................... 21 97 10.2. Informative References .................................... 22 98 Authors' Addresses ............................................... 22 100 1. Introduction 102 MPLS is an established data plane protocol in the Internet. It is 103 found in the majority of core service provider networks and most end- 104 to-end traffic in the Internet will be carried over MPLS at some 105 point in its path. The MPLS data plane is defined by [RFC3031] and 106 [RFC3032]. 108 Data security (i.e., confidentiality) in MPLS has previously relied 109 on just two features: 111 - Physical isolation of MPLS networks has been used to ensure that 112 interception of MPLS traffic was not possible. 114 - Higher-layer protocol security (such as IPsec [RFC4302], [RFC4303]) 115 has been used whenever a particular flow has determined that 116 security was desirable. 118 These features have a number of significant vulnerabilities: 120 - Networks are increasingly easily compromised physically such that 121 "taps" may be inserted in links between routers. 123 - Routers may be compromised either in their entirety or through 124 the management/control plane (or misconfiguration). This may 125 result in packets being diverted to transit inspection points on 126 their way to their destination. 128 - The increased support for point-to-multipoint (P2MP) MPLS means 129 that routers can easily be configured (or misconfigured) to make a 130 copy of data and to send it to an additional destination. 132 - End-to-end payload security may be hard to manage and operate and 133 is not turned on by default by many users. While this form of 134 security is desirable, the network should also improve the security 135 of data transfer that it offers. 137 This document describes a mechanism for opportunistic encryption of 138 the MPLS data plane. It shows what part of an MPLS packet may be 139 encrypted and provides a way to indicate that the packet is encrypted 140 as well as to carry a key identifier with each packet. 142 MPLS opportunistic encryption can be achieved between adjacent Label 143 Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and 144 also between end points of an LSP. 146 This document also provides a mechanism for keys to be exchanged to 147 facilitate encryption. Finally, this document describes the 148 applicability of opportunistic encryption in MPLS networks with an 149 indication of the level of improved security as well as the continued 150 vulnerabilities. 152 This document does not describe security for MPLS control plane 153 protocols. 155 2. Principles of Opportunistic Encryption 157 [[Editor note - the introductory material in Sections 2.1 to 2.3 158 here will likely be mostly or fully replaced with a reference to 159 a more generic OE draft that is in the process of being written. 160 That may lead to some terminology changes, but shouldn't impact 161 on functionality.]] 163 2.1 Why Do We Need Opportunistic Encryption? 165 To introduce this discussion we start from a basic view of how 166 encryption is used in IETF protocols. 168 Say we have two protocol entities, Alice and Bob, and they would like 169 some message "M" sent from Alice to Bob to have confidentiality. 170 Then Alice needs to send M encrypted with algorithm "E" under some 171 some symmetric (e.g., AES) key, "k". Thus Alice wants to send Bob 172 "E(k,M)", but since she and Bob don't yet have such a shared secret 173 they need to agree on the key, "k". 175 In many IETF protocols, such as TLS (as commonly used) or S/MIME 176 (CMS) or PGP, Alice simply invents a random key "k" and then encrypts 177 that under Bob's public key "Pub-b" and sends Bob E(Pub-b,k) and 178 E(k,M) together. (There are lots of other details and other options 179 for how this can be handled, but we ignore those for now.) In such 180 cases, before Alice can send "E(k,M)", she needs to first get Bob's 181 public key and she needs to be certain that it really is Bob's public 182 key and not Charlie's. That knowledge requires some long-term key 183 management, which is often done using a Public Key Infrastructure 184 (PKI) so that Alice actually stores the public key (Pub-ca) of a 185 Certification Authority (CA), and Bob gets his public key (Pub-b) 186 "certified" by the CA, which means the CA creates a digitally signed 187 data structure "Cert(Pub-ca,Pub-b)". The crucial thing is that 188 Alice, Bob, and a CA need to co-ordinate before Alice and Bob can 189 agree on a key "k", and that process imposes a key-management burden. 191 Doing such key management is clearly quite possible, since TLS and 192 IPsec and other well-deployed technologies depend on it. But, in 193 the case of HTTP/TLS on the public web, we see that only roughly 30% 194 of web sites actually take on this burden, even though the software 195 required is ubiquitous and, at least for 2nd level DNS domains in 196 .com for example, there are CAs who offer free domain-validated 197 certificates. While, some of the 70% who don't set up certificates 198 might not actually want confidentiality, there are certainly some who 199 would and arguably many that would benefit from confidentiality, if 200 it just happened out of the box, without an administrator having to 201 do anything. And there are also arguably many other protocols where 202 the same is true. 204 Opportunistic encryption (OE) offers a mechanisms to achieve 205 encryption between Alice and Bob without resorting to key-management 206 through CAs and without relying on manual configuration of keys. 208 2.2 Opportunistic Encryption at 10,000ft 210 Instead of the "key transport" mechanisms described in Section 2.1, 211 opportunistic encryption uses "key agreement". With key agreement, 212 both Alice and Bob contribute to calculating "k" (instead of the 213 the mechanism where Alice invents "k" and safely transports it to 214 Bob encrypted with Bob's public key as "E(Pub-b,k)"). 216 Assume that Alice and Bob are using some protocol where they can 217 exchange a few messages in order to agree on the key "k" to use. 218 With a Diffie-Hellman key agreement ("D-H") both Alice and Bob have 219 public and private values, where the private value can be randomly 220 generated, perhaps even once per message "M". They swap the public 221 values, and can then, thanks to the "magic" of Diffie-Hellman, derive 222 a key "k" that nobody else can know. 224 In this way Alice sends Bob "Pub-a" and Bob sends Alice "Pub-b" and 225 at that point both of them can safely calculate a shared secret "k" 226 from those values. And after that Alice can send Bob "E(k,M)". 228 From here on, we change the terminology slightly and refer to 229 Alice as the initiator, with private key "i" and Bob as the 230 recipient, with private key "r" so that our notation is closer 231 to that used in IPsec's IKE, on which we model our use of OE. 233 The "magic" of D-H works as follows. Let "p" be well-known large 234 prime number that we use for all modular arithmetic (meaning that 235 "a^b" is actually "(a^b) mod p"), and let "g" be another well-known 236 value (called a generator for the group determined by "p"). Also let 237 Alice and Bob's private values be "i" and "r" respectively. 238 Now, if Alice sends Bob "g^i" as her public value, and Bob 239 similarly sends Alice "g^r" then both of them can easily 240 calculate "g^(i*r)" or "g^ir" but nobody else can, since calculating 241 "x" when only given "g^x" is a computationally hard 242 problem for any "x". Once both Alice and Bob have the value "g^ir" 243 in hand, they can easily derive a value "k" from that using any of a 244 number of well-known key derivation functions (KDF). 246 As you can see from the above, Alice and Bob do not need to pre- 247 arrange anything other than "g" and "p", and those can be public 248 values, that are used by everyone everywhere (or at least by all 249 participants in a particular deployment). Yet, Alice and Bob have 250 managed to derive a common value for a key "k" that they can use to 251 encrypt (and decrypt) "M". 253 This kind of opportunistic encryption provides strong 254 confidentiality and can be built into any protocol that allows Alice 255 and Bob to occasionally exchange public values. 257 There are also additional advantages to key agreement when 258 compared to key transport. The most important of those is 259 that with key agreement we can easily ensure that k has a 260 property called Perfect Forward Secrecy (PFS). That means 261 that an attacker has to separately attack each key k. In 262 contrast, if we use the key transport approach, then an 263 attacker who somehow accesses Bob's private key "Priv-b" 264 can record lots of traffic and later go back and decrypt all 265 the "E(Pub-b,k)" values that all Alice's ever sent to Bob. 266 With key agreement as described, since both Alice and Bob 267 contribute to the value k, and since Alice and Bob will 268 typically periodically generate new private values i and r 269 (perhaps even for every single M), compromise of one party 270 is far less catastrophic, and an attacker who gets access to 271 one private value gets far less benefit. 273 2.3 What about a Man-in-the-Middle? 275 But OE is not resilient to Man-in-the-Middle (MITM) attacks. The 276 problem is that Alice does not know that it was really Bob's public 277 value that she received; it could have been Charlie's public value 278 sent by Charlie. And Charlie could also send Bob his public value 279 pretending to be Alice. Now Charlie can share a key with Alice and 280 a key with Bob so that Charlie can sit between Alice and Bob 281 decrypting what he gets from Alice and then re-encrypting it to send 282 to Bob. Neither Alice nor Bob can tell that Charlie is present as a 283 "Man-in-the-Middle" and both Alice and Bob think they are safely 284 exchanging encrypted messages. 286 A MITM attack like that is bad and making a protocol proof against 287 such attacks comes at the cost of the key-management burden described 288 in Section 2.1. Most IETF protocols to date require that such MITM 289 attacks not be feasible. 291 However, despite its vulnerability to MITM attacks, OE still has 292 value in some circumstances. This value arises because of the 293 difficulty of inserting a MITM actor, and the cost of processing for 294 the MITM in the case of a very large number of OE relationships. In 295 particular, where the choice is between no encryption (as has been 296 the case for MPLS to date) and OE, it is clear that using OE offers 297 better (although not the best) security. 299 Consider the case where an attacker taps a link on the path between 300 Alice and Bob. In this case, the attacker can capture every packet 301 between the two parties, and if there is no encryption, can read 302 every message. Furthermore, consider that the attacker could tap a 303 fiber in the core of the network and so capture every packet between 304 a large number of Alices and their corresponding Bobs. In these 305 cases, Charlie can operate as a "passive MITM" since all he has to do 306 is watch the packets. 308 With OE in use, Charlie is forced to be an "active MITM". That is he 309 must engage in the D-H exchange between each pair of Alices and Bobs, 310 and he must must decrypt and encrypt each packet he wants to inspect. 311 This imposes a higher cost and is especially burdensome if he is 312 attempting to do it in parallel for lots of Alice/Bob pairs using 313 lots of different keys and communication sessions. 315 Furthermore, when D-H is in use for OE, management tools can be used 316 to detect the presence of Charlie as a MITM. This is because 317 Charlie has to agree one key "kA" with Alice, and a different key 318 "kB" with Bob. As far as we know, Charlie cannot arranged that 319 kA equals kB because both sides contribute to the key value in the 320 D-H key agreement. That means that if Alice and Bob can check with 321 each other what value of "k" they are using and the values do not 322 match, then they know that Charlie is present. What is more, Alice 323 and Bob can make this check on the value of "k" for any of the 324 "E(k,M)" they ever exchanged. 326 Thus, in the case of a fiber tap where many Alice/Bob pairs are 327 being monitored, it only takes one Alice and Bob to detect the MITM 328 attack for all Alice/Bob pairs to be alerted to the problem. In 329 such cases the cost of detection for Charlie may be even greater than 330 the cost of performing the MITM attack. 332 Hence we conclude that OE can have considerable value when used in 333 MPLS networks. 335 2.4 OE in MPLS Overview 337 [[Editor Note - the details here are suitable for an early revision 338 draft. 339 We might change to ECDH later, or to use another KDF, or symmetric 340 cipher mode. All that is for discussion.]] 342 The basic requirement for MPLS OE is that we want to provide a way 343 for two MPLS nodes to do an OE key exchange and to derive a session 344 key from that to use in MPLS packet encryption. 346 To do that we use a Diffie-Hellman key exchange as outlined in 347 Section 2.2. We model this on IKE [RFC5996] using essentially the 348 same parameters. We feed the shared Diffie-Hellman value, which is 349 g^ir, into a standard key derivation function (KDF) 350 that also takes as input the LSP identifier (LSP ID) together with 351 the sending and receiving LSR IDs - where the the sending LSR is the 352 point of encryption and the receiving LSR is the point of decryption 353 such that the pair of LSRs define the Security Association (SA). 354 These additional inputs are used to ensure that we end up with 355 different keys on an LSP even if the same g^i and g^r values 356 are re-used. The KDF to be used here is as defined in [RFC5869]. 358 D-H values used for MPLS OE MUST be of at least 2048-bits. 359 Implementations of MPLS OE MUST support the 2048-bit modular 360 exponentiation (MODP) group from Section 3 of [RFC3526] and SHOULD 361 support the larger MODP groups from [RFC3526]. 363 This document also defines the mechanism used to derive an identifier 364 for a key (the key-id) from the shared Diffie-Hellman value, which 365 is also based on the KDF output. The key will be used with a 366 symmetric encryption algorithm, such as AEAD_AES_GCM_128 (the 367 default, following [RFC5116]). 369 As with any symmetric block cipher, one should not use the same key 370 for too long, so this document also defines a way for two LSRs using 371 a key on an LSP to agree a new key and to switch over to using that 372 key when desired. That means that implementations MUST be able to 373 handle at least two keys (old and new) for a given LSP. Once a new 374 key has been agreed then it should be used for sending packets; once 375 encrypted data packets protected with the new key have been 376 successfully received, the old key should be discarded. Section 4 377 describes how two LSRs agree keys, and to agree a new key, two LSRs 378 simply run the same key agreement exchange, but this time protected 379 with the old session key as described in Section 4.3. This process 380 can, of course, be repeated any number of times for the same LSP. It 381 is RECOMMENDED that the key on an LSP be changed at least once every 382 day or every 10^6 packets whichever is sooner. 383 [[Editor Note: These values need considered in the light of latest 384 cryptology advice, but also understanding that this is "best- 385 effort" OE]] 387 In the event of a key agreement exchange or decryption failure, an 388 alarm MUST be raised to the operator. Default (i.e., node-wide) and 389 per-LSP behavior SHOULD be configurable in this case: actions may 390 include reverting to non-encrypted traffic, re-attempting key 391 exchange, or tearing down the LSP. Note that a simple attack on OE 392 is to tamper with key agreement exchange messages or encrypted 393 packets so that OE fails. Such attacks may be intended to cause the 394 LSP to operate without encryption, so an operator should consider 395 this when setting the behavior in this case. 397 Section 7.1 also discusses a mechanism that allows a pair of LSRs 398 using OE on an LSP to detect that a MITM attack has happened. For 399 this, we simply define a function of the shared secret, which can be 400 logged and later compared. Note that logging a sample of these 401 "witness" values will likely be sufficient to detect pervasive MITM 402 attacks. As with the key-id, we base this on the same KDF output. 404 3. MPLS Packet Encryption 406 MPLS packets may be individually encrypted according to the 407 mechanisms described in this section. 409 When an MPLS packet is encrypted, this is indicated by the insertion 410 of a new special purpose label [ID.ietf-mpls-special-purpose-labels] 411 in the label stack. This is referred to as the Opportunistic 412 Encryption Label Indicator (OELI). The format of the OELI is 413 described in Section 3.1. 415 The OELI is followed immediately by a further label stack entry that 416 contains an identifier of the key and algorithm that is in use. This 417 label stack entry is referred to as the Opportunistic Encryption 418 Label (OEL). The format of the OEL is described in Section 3.2. 420 The OEL MUST have the bottom of stack bit (the S bit) set and MUST be 421 followed by a pseudowire control word [RFC4385]. The format of the 422 control word is described in Section 3.3. 424 The remainder of the MPLS packet is encrypted and cannot be parsed 425 without decryption. Implementations MUST support the 426 AEAD_AES_GCM_128 encryption algorithm, as specified in Section 5.1 427 of [RFC5116], which is the default as described in Section 4.2 of 428 this document. Note that it is critical that new nonces are used for 429 every encryption. Note also that the output from encryption will be 430 16 octets longer than the input. 432 The bottom of stack bit is set in the OEL to stop implementations 433 continuing to search down the label stack (which is encrypted) and 434 attempting to use the data as though it was a valid label stack. The 435 control word is needed because many implementations that find the 436 bottom of stack expect the next bytes to be a control word or 437 protocol indicator. 439 The position of the OELI, OEL, and control word depend on whether 440 hop-by-hop or end-to-end encryption is being applied. 442 Figure 1 illustrates the format of an example MPLS packet before and 443 after hop-by-hop opportunistic encryption. The left hand part of the 444 figure shows a normal MPLS packet with a label stack and payload. 445 The bottom label in the stack has the S bit set. The payload is the 446 data carried by the MPLS packet (such as IP) and may be prefixed by a 447 control word. 449 The right hand part of Figure 1 shows the same packet after it has 450 been encrypted. The top of stack is the OELI followed by the OEL 451 with the S bit set. The OEL is followed by a control word. 452 Everything that follows the control word is the entire original MPLS 453 packet encrypted. 455 ----------- . ----------- 456 | Top Label | . | OELI | 457 +-----------+ . +-----------+ 458 | Label | . | OEL S=1 | 459 +-----------+ . +-----------+ 460 | Label S=1 | .| Ctrl Word | 461 +-----------+ +-----------+ 462 | | | | 463 ~ Payload ~ ~ Encrypted ~ 464 | | | | 465 -----------........----------- 467 Figure 1 : The Use of the OEL for Hop-by-Hop Opportunistic Encryption 469 Figure 2 illustrates the format of an example MPLS packet before and 470 after end-to-end opportunistic encryption. The left hand part of the 471 figure shows a normal MPLS packet with a label stack and payload. 472 The bottom label in the stack has the S bit set and the payload may 473 be prefixed by a control word. The right hand part of the figure shows 474 how the top two labels (or however many labels are needed for end-to- 475 end delivery) remain at the top of the label stack. Then follows the 476 OELI and OEL with S bit set, and a control word. The remainder of 477 the packet is encrypted and contains the rest of the label stack and 478 the payload. 480 ----------- ----------- 481 | Top Label | | Top Label | 482 +-----------+ +-----------+ 483 | Label | | Label | 484 +-----------+. +-----------+ 485 | Label | . | OELI | 486 +-----------+ . +-----------+ 487 | Label | . | OEL S=1 | 488 +-----------+ . +-----------+ 489 | Label S=1 | .| Ctrl Word | 490 +-----------+ +-----------+ 491 | | | | 492 ~ Payload ~ ~ Encrypted ~ 493 | | | | 494 -----------........----------- 496 Figure 2 : The Use of the OEL for End-to-End Opportunistic Encryption 498 3.1. Opportunistic Encryption Label Indicator 500 The Opportunistic Encryption Label Indicator (OELI) is a normal label 501 stack entry carrying a special purpose label with value TBD1 to be 502 assigned by IANA. The format of the label stack entry is defined in 503 [RFC3032] and shown in Figure 3. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Label | TC |S| TTL | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 3 : Format of the OELI Label Stack Entry 513 Label: Set to TBD1 to indicate this is an OELI 514 TC: SHOULD be copied from the TC of the first encrypted label. 515 S: MUST be set to zero. 516 TTL: SHOULD be set to the TTL of the first encrypted label. 518 3.2. Opportunistic Encryption Label 520 The Opportunistic Encryption Label (OEL) is carried in a normal label 521 stack entry immediately following an OELI. The format of the label 522 stack entry is defined in [RFC3032] and shown in Figure 4. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Label | TC |S| TTL | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 4 : Format of the OEL Label Stack Entry 532 Label: Any value from 16 to 1048575 used as a look-up into a table of 533 encryption algorithms and keys that has been established 534 through configuration or dynamic key exchange as described in 535 Section 4. 536 This label MUST NOT be used for forwarding, and MUST NOT come 537 from the range 0 through 15. 538 TC: MAY be copied from the TC of the first encrypted label. 539 Otherwise set to zero. 540 S: MUST be set to one. 541 TTL: SHOULD be set to zero to prevent encrypted packets being 542 accidentally forwarded beyond the point of intended 543 decryption. 545 3.3. Control Word 547 The control word is inserted after the OEL as described in Section 3. 548 The S bit set to one in the OEL and the presence of the control word 549 helps protect against transit nodes that may perform hashing or 550 inspection of the label stack and payload packet headers when 551 forwarding MPLS packets (for example, to enable ECMP). The control 552 word indicates that the payload is not a protocol that can be 553 meaningfully hashed or inspected. 555 The format of the control word is defined in [RFC4385] and shown in 556 Figure 5. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 |0 0 0 1|Version| Reserved | Channel Type | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Figure 5: Control Word for Opportunistically Encrypted MPLS 566 Version: MUST be zero. 567 Reserved: MUST be sent as 0, and ignored on receipt. 568 Channel Type: Set to TBD2 to indicate that the following bytes are 569 encrypted MPLS. 571 3.4. Considerations for ECMP 573 As previously stated, the S bit set in the OEL and the presence of 574 the control word prevent implementations from attempting to use the 575 encrypted MPLS packet and its payload to determine a hash value for 576 uses such as ECMP. However, the resultant label stack shown in 577 Figure 2 will probably not provide sufficient entropy for ECMP 578 purposes. 580 In order to increase the entropy, an implementation that inserts an 581 OELI and OEL MAY also insert an Entropy Label Indicator (ELI) and 582 Entropy Label (EL) as defined in [RFC6790]. The ELI and EL are 583 positioned in the label stack before the OELI and OEL. The setting 584 of the fields in the ELI and EL label stack entries are as described 585 in [RFC6790]. 587 The ELI and EL will normally occur immediately before the OELI, but 588 they MAY be placed higher up the label stack. 590 ----------- 591 | Top Label | 592 +-----------+ 593 | Label | 594 ----------- +-----------+ 595 | Top Label | | ELI | 596 +-----------+ +-----------+ 597 | Label | | EL | 598 +-----------+. +-----------+ 599 | Label | . | OELI | 600 +-----------+ . +-----------+ 601 | Label | . | OEL S=1 | 602 +-----------+ . +-----------+ 603 | Label S=1 | .| Ctrl Word | 604 +-----------+ +-----------+ 605 | | | | 606 ~ Payload ~ ~ Encrypted ~ 607 | | | | 608 -----------........----------- 610 Figure 6 : The Use of ELI and EL with OEL 612 3.5. Backward Compatibility 614 Keys and encryption algorithms may be configured manually or 615 exchanged dynamically as described in Section 4. These mechanisms 616 provide a preliminary way to protect against a sender encrypting data 617 that the receiver cannot decrypt, however, misconfiguration may lead 618 to a sender using the OELI when the receiver does not support 619 opportunistic encryption. 621 When a node finds an unknown label at the top of the label stack it 622 must discard the packet as described in [RFC3031]. Therefore, when a 623 receiver discovers the OELI and does not support opportunistic 624 encryption it will discard the packet. The net result is that when a 625 sender uses opportunistic encryption in error, all packets that it 626 sends on the LSP will be discarded by the receiver. Note that in 627 this discussion, "the receiver" may be the next hop if single hop 628 encryption is used, or may be the end of the LSP if end-to-end 629 encryption is used. 631 Transit nodes that are not actively participating in the encryption 632 will not inspect the OELI except potentially as part of an ECMP hash. 633 This means that transit nodes will not encounter the OELI during 634 normal packet processing and will not discard packets. 636 3.6. MTU Considerations 638 Adding the OELI and OEL as described above will reduce the available 639 data size by 8 octets. Furthermore, as described in in Section 3, 640 the output of the encryption algorithm is 16 octets longer than the 641 input. Therefore, the use of MPLS OE reduces the available MTU by 20 642 octets. 644 When end-to-end OE is in use this can be considered by the ingress 645 LSR, however, when single-hop OE is in use the participating LSRs 646 need to advertise this reduction in link MTU so that the packets do 647 not overflow. MPLS packets MUST NOT be fragmented as a result of 648 OE. 650 3.7. Recursive OE 652 The use of OELI, OEL, and control word described in Section 3 may 653 be applied recursively. That is, the payload of an encrypted MPLS 654 packet may, itself be an encrypted MPLS packet. This may be 655 particularly useful in the case where an MPLS VPN has native MPLS 656 traffic. 658 There are no special considerations except to note that encryption 659 and decryption processing may be burdensome if an LSP and its payload 660 LSP have OE applied at the same LSR. Additionally, it should be 661 noted that, as described in Section 3.6, each recursive encryption 662 reduces the MTU by 20 octets. 664 4. Key Exchange For Opportunistic Encryption in MPLS 666 For encryption to be useful both ends of an encrypted session must 667 know which algorithm is in use and which key to use. The mechanism 668 described in Section 3 provides a way to indicate an index into a 669 table of algorithms and keys that can be used to decrypt an encrypted 670 MPLS packet. 672 It is possible that this table has been manually configured or set up 673 using a key exchange protocol such as Internet Key Exchange version 2 674 (IKEv2) [RFC5996]. However, such a process implies a stable security 675 association between encrypter and decrypter of MPLS packets. Such a 676 stable association is not consistent with the concept of 677 opportunistic encryption. 679 This section provides a mechanism for adjacent MPLS LSRs, or for a 680 pair of LSRs at opposite ends of an MPLS LSP, to dynamically 681 exchange keys and algorithm identifiers so that encryption may be 682 applied opportunistically. 684 The mechanism uses message exchange in the MPLS Generic Associated 685 Channel (G-ACh) [RFC5586]. This channel is in-band with an LSP and 686 may be used to carry messages between neighbors or between the end 687 points of the LSP. A type field within the common message header, 688 the Associated Channel Header (ACH), is used to indicate the type of 689 message carried. 691 Nodes that receive G-ACh messages and do not understand them, or 692 nodes that understand the G-ACh but do not recognize the ACH message 693 type drop the packets as described in [RFC5586]. 695 4.1. Associated Channel for Key Exchange 697 The Associated Channel Type value TBD3 indicates that the packet 698 contains a Key Exchange Protocol message as defined in Section 4.2. 700 Implementations that do not support key exchange in this manner will 701 discard received packets with this Associated Channel Type as 702 described in [RFC5586]. This will result in no dynamic key exchange, 703 but other key definitions are still supported (such as manual 704 configuration) and may be used to construct a table of algorithms and 705 keys that can be used to achieve MPLS encryption using the mechanisms 706 described in Section 3. 708 Note that TBD3 indicates the use of Diffie-Hellman key exchange. If 709 ECDH is added later a new value will be required. 710 [[Editor Note. An alternative to this is to embed the type of key 711 exchange within the key exchange messages.]] 713 4.2. Key Exchange Protocol 715 A session key is to be established between an initiator (Alice) and 716 a recipient (Bob). The D-H public value for Alice is g^i and for 717 Bob, g^r. The shared Diffie-Hellman value is g^ir. 719 g^ir is represented as a string of octets in big endian 720 order padded with zeros if necessary to make it the length of the 721 modulus. 723 Both g^i and g^r will be 2048 bits long, if the Diffie-Hellman 724 modulus is 2048 bits long. 726 The key exchange payload is modelled on that from Section 3.4 of 727 [RFC5996], and is shown in Figure 7. 729 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |D| Payload Length | algorithm | Group Num | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | | 735 ~ D-H Public value ~ 736 | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 7 - Key Exchange Message 741 The flag D denotes the direction of the message, '0' indicates a 742 message from initiator (Alice) to recipient. '1' indicates the 743 reverse direction. 745 The Payload Length field contains the number of octets following the 746 payload length field (including the group number). This is 15 bits 747 wide. 749 The algorithm field is a one octet field that specifies both the KDF 750 to use and the symmetric algorithm to be used for data packet 751 encryption. A registry for values of this field is defined in 752 Section 8.3. The value 0 is used to indicate the default KDF and 753 symmetric encryption mode. 755 The Diffie-Hellman Group Num is from [RFC3526], so the group number 756 for 2048 MODP is decimal 14. Note that this is a one octet field, 757 but is two octets in the [RFC5996] equivalent. This is not an issue 758 because there are only 30 MODP groups defined at present and new 759 groups are not added frequently. 761 The D-H public value will contain g^i or g^r depending on the 762 direction (i.e., the setting of the D flag) and is in big endian 763 order. 765 The length of the Diffie-Hellman public value for MODP groups MUST be 766 equal to the length of the prime modulus over which the 767 exponentiation was performed, prepending zero bits to the value if 768 necessary. 770 Once both sides have derived g^ir they need to feed that and the 771 other inputs described in Section 2.4 into the KDF indicated by the 772 algorithm field. With the default algorithm (value zero), the KDF to 773 be used is HKDF as specified in [RFC5869]. 775 The parameters for the use of HKDF are: 777 Hash: SHA-256 779 Salt: not used [[Editor Note: maybe we should?]] 781 Skip: do not skip 783 Info: The catenation of a fixed string indicating use of MPLS OE, 784 with the value "MPLS-OE", the first 32 bits of the key 785 exchange message, with the D flag set to 0, plus the LSP 786 ID and the sender and receiver LSR IDs in that order. That 787 is: 789 MPLS-OE||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID 791 L: The output length in bits is 256. 793 The fixed string "MPLS-OE" is used as an input here to prevent 794 potential cross-protocol attacks. Those might otherwise be 795 possible if this mechanism were to be copied in other protocols. 796 (If copying this mechanism for any reason, then a different 797 fixed string value should be used.) 799 The default encryption algorithm, AEAD_AES_GCM_128, specified 800 in Section 3, requires a 128 bit session key. 802 The 256-bit HKDF output is the catenation of the session key, the key 803 id, and the witness value in that order. That is the session key is 804 the leftmost 128 bits of the HKDF output. The key-id is the next 16 805 bits and the witness value is the remaining 112 bits. 807 The key-id is prepended with four zero bits and used as the label 808 value in the OEL (see Section 3.2) so that the label does not take 809 any of the values 0-15. 811 [[Editor note - we might want to consider deriving the witness 812 value from a separate invocation of the KDF that does not depend 813 on the LSP-specific inputs. The benefit from that would be 814 that the same MITM-detection infrastructure could be used for 815 many protocols. However, that would require standardizing a 816 generic D-H MITM-detection protocol, or at least formats, in 817 order to be useful. We also need to consider what additional 818 information needs to be logged with the witness value so that 819 comparisons can easily be made at scale but without creating 820 new privacy-invasive meta-data. (That last is not much of an 821 issue for MPLS-OE, but could be elsewhere.) At present we do 822 not intend to go for the generic MITM-detection approach, but 823 it is worth considering.]] 825 4.3. Protecting the Key Exchange Protocol Messages 827 As described in Section 2.4, once one key exchange has been 828 successfully completed, further key exchanges should be protected 829 using a previous key. This is simply achieved since key exchange 830 messages are, themselves, carried in MPLS packets on the LSP and may 831 be subject to encryption exactly as any other packet. 833 5. Applicability of MPLS Opportunistic Encryption 835 As noted throughout this document, the intention of OE in MPLS is to 836 allow one LSR to enable encryption between itself and its neighbor, 837 or between itself and the other end of an LSP, in a dynamic and un- 838 planned way. 840 In order that OE, one end of a peering (neighbor or LSP end) must 841 decide to attempt OE and the other end must support it. This can be 842 determined by the message exchanges described in Section 4.2 since if 843 one peer does not send a key exchange message then encryption will 844 not be used, and if the other peer does not respond then it is 845 unwilling or unable to decrypt messages. 847 6. Security Considerations 849 6.1. Security Improvements 851 See section 2.1. 853 6.2. Continued Vulnerabilities 855 The mechanisms described in this document do not provide protection 856 against certain types of MITM attacks. For example, the key exchange 857 protocol in Section 4.2 will not detect if key exchange messages or 858 their responses are intercepted and discarded such that the 859 initiating peer believes that encryption is not supported. 860 Similarly, those messages may be tampered with such that a receiver 861 cannot determine the correct table index to algorithm and key mapping 862 when an encrypted packet is received. Furthermore, the OEL in an 863 MPLS packet is not protected and may be overwritten such that a 864 receiver is unable to decrypt the packet. 866 See Section 7.1 for a discussion of how active MITM attacks can be 867 detected. 869 6.3. New Security Considerations 871 If a pair of LSRs do not do the key exchange before sending any data 872 packets on the LSP then those first packets will not be protected by 873 OE and hence will be available to a monitor. 875 If a MITM can prevent the OE key exchange from completing, e.g. 876 via deleting messages or changing bits in messages, and if the LSRs 877 continue to send data regardless then those data packets will be 878 available to a monitor. See Section 2.4 and Section 7 for a 879 description of how alarms should be raised in these circumstances. 881 7. Manageability Considerations 883 As described in Section 2.4 node-wide and per-LSP behavior SHOULD be 884 configurable to describe the action where key agreement exchange or 885 packet decryption fails. In any case, such events MUST trigger 886 alarms to the operator. 888 7.1. MITM Detection 890 Section 2.4 introduces the concept of a function of the shared 891 secret that can be compared by two LSRs that are using OE to see 892 whether they are victims of an active MITM attack. 894 Section 4.2 describes how a witness value is derived for the 895 default KDF, HKDF. 897 The participating LSRs can simply log this value plus the LSP 898 and LSR IDs from time to time and a management application can 899 compare the values. If they are different for the same LSP ID, 900 then an active MITM attack has taken place. 902 It needs to be carefully noted that the management channel used to 903 log or otherwise compare the witness values from the two LSRs MUST be 904 secure. It is likely that routers use relatively high security 905 management channels for configuration and other management 906 operations. 908 [[Editor note - please see the note in 4.2 about generic 909 MITM-detection. Changes there could affect what needs to be 910 done here.]] 912 8. IANA Considerations 914 8.1. Opportunistic Encryption Label Indicator 916 IANA maintains a registry called "Multiprotocol Label Switching 917 Architecture (MPLS) Label Values" with a single sub-registry called 918 "Label Values". This registry is to be renamed "Special Purpose MPLS 919 Label Values according to [ID.ietf-mpls-special-purpose-labels]. 921 IANA is requested to assign a value from this registry as follows: 923 Value | Description | Reference 924 ------+-------------------------------------------------+----------- 925 TBD1 | Opportunistic Encryption Label Indicator (OELI) | [This.ID] 927 The value 8 is suggested. 929 [RFC Editor is requested to replace the string "TBD1" with the value 930 assigned by IANA throughout this document, and to remove this note.] 932 8.2. Pseudowire Associated Channel Types 934 IANA maintains a registry called "Pseudowire Name Spaces (PWE3)" with 935 a sub-registry called "Pseudowire Associated Channel Types". IANA is 936 requested to assign a value as follows: 938 Value | Description | Reference 939 ------+-------------------------------------------------+----------- 940 TBD3 | Opportunistic Key Exchange Protocol for MPLS | [This.ID] 941 TBD2 | Opportunistically Encrypted MPLS | [This.ID] 943 The values 19 and 20 are suggested. It is suggested that TBD3 have 944 a value 1 smaller than TBD2. 946 [RFC Editor is requested to replace the string "TBD2" and "TBD3" with 947 the values assigned by IANA throughout this document, and to remove this 948 note.] 949 8.3. Key Derivation Functions and Symmetric Algorithms 951 IANA is requested to create a new MPLS registry called the "MPLS 952 Opportunistic Encryption Algorithms Registry". New values are to 953 be assigned through "IETF Review" as defined in [RFC5226]. 955 The available range is 0 - 255. 957 IANA is requested to record the following information and create an 958 initial entry as follows: 960 Value | Key Derivation Function | Symmetric Algorithm | Reference 961 ------+-------------------------+---------------------+----------- 962 0 | HKDF | AEAD_AES_GCM_128 | [This.I-D] 963 1-255 | Unassigned | | 965 9. Acknowledgements 967 Many thanks to Alia Atlas for detailed discussion of the implications 968 of MPLS opportunistic encryption. Thanks also to Ron Bonica for 969 encouraging this work, to Sean Turner and Stewart Bryant for early 970 review, and to Jeff Haas and Ross Callon for discussions. 972 10. References 974 10.1. Normative References 976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 977 Requirement Levels", BCP 14, RFC 2119, March 1997. 979 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 980 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 981 Use over an MPLS PSN", RFC 4385, February 2006. 983 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 984 Associated Channel", RFC 5586, June 2009. 986 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 987 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 988 RFC 6790, November 2012. 990 [ID.ietf-mpls-special-purpose-labels] 991 Kompella, K., Andersson, L., and A. Farrel, "Allocating 992 and Retiring Special Purpose MPLS Labels" draft-ietf-mpls- 993 special-purpose-labels, work in progress. 995 [RFC3526] Kivinen, T., and M. Kojo, "More Modular Exponential (MODP) 996 Diffie-Hellman groups for Internet Key Exchange (IKE)", 997 RFC 3526, May 2003. 999 [RFC5116] D. McGrew, "An Interface and Algorithms for Authenticated 1000 Encryption", RFC 5116, January 2008. 1002 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1003 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1004 May 2008. 1006 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1007 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1009 10.2. Informative References 1011 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1012 Label Switching Architecture", RFC 3031, January 2001. 1014 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1015 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1016 Encoding", RFC 3032, January 2001. 1018 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1019 December 2005. 1021 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1022 RFC 4303, December 2005. 1024 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1025 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1026 RFC 5996, September 2010. 1028 Authors' Addresses 1030 Adrian Farrel 1031 Juniper Networks 1033 EMail: adrian@olddog.co.uk 1035 Stephen Farrell 1036 Trinity College Dublin 1037 Dublin, 2 1038 Ireland 1040 Phone: +353-1-896-2354 1041 Email: stephen.farrell@cs.tcd.ie