idnits 2.17.1 draft-farrelll-mpls-opportunistic-encrypt-01.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 (January 21, 2014) is 3720 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: 2 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 21, 2014 S. Farrell 6 Trinity College, Dublin 7 January 21, 2014 9 Opportunistic Encryption in MPLS Networks 11 draft-farrelll-mpls-opportunistic-encrypt-01.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 ........................................... 8 71 3. MPLS Packet Encryption ......................................... 9 72 3.1. Opportunistic Encryption Label Indicator .................... 12 73 3.2. Opportunistic Encryption Label .............................. 12 74 3.3. Control Word ................................................ 13 75 3.4. Considerations for ECMP ..................................... 14 76 3.5. Backward Compatibility ...................................... 14 77 3.6. MTU Considerations .......................................... 15 78 3.7. Recursive OE ................................................ 15 79 4. Key Exchange For Opportunistic Encryption in MPLS ............. 16 80 4.1. Associated Channel for Key Exchange ......................... 16 81 4.2. Key Exchange Protocol ....................................... 17 82 4.3. Protecting the Key Exchange Protocol Messages ............... 19 83 5. Applicability of MPLS Opportunistic Encryption ................ 19 84 6. Security Considerations ....................................... 21 85 6.1. Security Improvements ....................................... 21 86 6.2. Continued Vulnerabilities ................................... 21 87 6.3. New Security Considerations ................................. 21 88 7. Manageability Considerations .................................. 22 89 7.1. MITM Detection .............................................. 22 90 8. IANA Considerations .......................................... 22 91 8.1. Opportunistic Encryption Label Indicator .................... 22 92 8.2. Pseudowire Associated Channel Types ......................... 23 93 8.3. Key Derivation Functions and Symmetric Algorithms ........... 23 94 9. Acknowledgements ............................................. 23 95 10. References .................................................. 24 96 10.1. Normative References ...................................... 24 97 10.2. Informative References .................................... 24 98 Authors' Addresses ............................................... 25 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 Please note that a discussion of the applicability of MPLS 156 Opportunistic Encryption is provided in Section 5. 158 2. Principles of Opportunistic Encryption 160 [[Editor note - the introductory material in Sections 2.1 to 2.3 161 here will likely be mostly or fully replaced with a reference to 162 a more generic OE draft that is in the process of being written. 163 That may lead to some terminology changes, but shouldn't impact 164 on functionality.]] 166 2.1 Why Do We Need Opportunistic Encryption? 168 To introduce this discussion we start from a basic view of how 169 encryption is used in IETF protocols. 171 Say we have two protocol entities, Alice and Bob, and they would like 172 some message "M" sent from Alice to Bob to have confidentiality. 173 Then Alice needs to send M encrypted with algorithm "E" under some 174 some symmetric (e.g., AES) key, "k". Thus Alice wants to send Bob 175 "E(k,M)", but since she and Bob don't yet have such a shared secret 176 they need to agree on the key, "k". 178 In many IETF protocols, such as TLS (as commonly used) or S/MIME 179 (CMS) or PGP, Alice simply invents a random key "k" and then encrypts 180 that under Bob's public key "Pub-b" and sends Bob E(Pub-b,k) and 181 E(k,M) together. (There are lots of other details and other options 182 for how this can be handled, but we ignore those for now.) In such 183 cases, before Alice can send "E(k,M)", she needs to first get Bob's 184 public key and she needs to be certain that it really is Bob's public 185 key and not Charlie's. That knowledge requires some long-term key 186 management, which is often done using a Public Key Infrastructure 187 (PKI) so that Alice actually stores the public key (Pub-ca) of a 188 Certification Authority (CA), and Bob gets his public key (Pub-b) 189 "certified" by the CA, which means the CA creates a digitally signed 190 data structure "Cert(Pub-ca,Pub-b)". The crucial thing is that 191 Alice, Bob, and a CA need to co-ordinate before Alice and Bob can 192 agree on a key "k", and that process imposes a key-management burden. 194 Doing such key management is clearly quite possible, since TLS and 195 IPsec and other well-deployed technologies depend on it. But, in 196 the case of HTTP/TLS on the public web, we see that only roughly 30% 197 of web sites actually take on this burden, even though the software 198 required is ubiquitous and, at least for 2nd level DNS domains in 199 .com for example, there are CAs who offer free domain-validated 200 certificates. While, some of the 70% who don't set up certificates 201 might not actually want confidentiality, there are certainly some who 202 would and arguably many that would benefit from confidentiality, if 203 it just happened out of the box, without an administrator having to 204 do anything. And there are also arguably many other protocols where 205 the same is true. 207 Opportunistic encryption (OE) offers a mechanisms to achieve 208 encryption between Alice and Bob without resorting to key-management 209 through CAs and without relying on manual configuration of keys. 211 2.2 Opportunistic Encryption at 10,000ft 213 Instead of the "key transport" mechanisms described in Section 2.1, 214 opportunistic encryption uses "key agreement". With key agreement, 215 both Alice and Bob contribute to calculating "k" (instead of the 216 the mechanism where Alice invents "k" and safely transports it to 217 Bob encrypted with Bob's public key as "E(Pub-b,k)"). 219 Assume that Alice and Bob are using some protocol where they can 220 exchange a few messages in order to agree on the key "k" to use. 221 With a Diffie-Hellman key agreement ("D-H") both Alice and Bob have 222 public and private values, where the private value can be randomly 223 generated, perhaps even once per message "M". They swap the public 224 values, and can then, thanks to the "magic" of Diffie-Hellman, derive 225 a key "k" that nobody else can know. 227 In this way Alice sends Bob "Pub-a" and Bob sends Alice "Pub-b" and 228 at that point both of them can safely calculate a shared secret "k" 229 from those values. And after that Alice can send Bob "E(k,M)". 231 From here on, we change the terminology slightly and refer to 232 Alice as the initiator, with private key "i" and Bob as the 233 recipient, with private key "r" so that our notation is closer 234 to that used in IPsec's IKE, on which we model our use of OE. 236 The "magic" of D-H works as follows. Let "p" be well-known large 237 prime number that we use for all modular arithmetic (meaning that 238 "a^b" is actually "(a^b) mod p"), and let "g" be another well-known 239 value (called a generator for the group determined by "p"). Also let 240 Alice and Bob's private values be "i" and "r" respectively. 241 Now, if Alice sends Bob "g^i" as her public value, and Bob 242 similarly sends Alice "g^r" then both of them can easily 243 calculate "g^(i*r)" or "g^ir" but nobody else can, since calculating 244 "x" when only given "g^x" is a computationally hard 245 problem for any "x". Once both Alice and Bob have the value "g^ir" 246 in hand, they can easily derive a value "k" from that using any of a 247 number of well-known key derivation functions (KDF). 249 As you can see from the above, Alice and Bob do not need to pre- 250 arrange anything other than "g" and "p", and those can be public 251 values, that are used by everyone everywhere (or at least by all 252 participants in a particular deployment). Yet, Alice and Bob have 253 managed to derive a common value for a key "k" that they can use to 254 encrypt (and decrypt) "M". 256 This kind of opportunistic encryption provides strong 257 confidentiality and can be built into any protocol that allows Alice 258 and Bob to occasionally exchange public values. 260 There are also additional advantages to key agreement when 261 compared to key transport. The most important of those is 262 that with key agreement we can easily ensure that k has a 263 property called Perfect Forward Secrecy (PFS). That means 264 that an attacker has to separately attack each key k. In 265 contrast, if we use the key transport approach, then an 266 attacker who somehow accesses Bob's private key "Priv-b" 267 can record lots of traffic and later go back and decrypt all 268 the "E(Pub-b,k)" values that all Alice's ever sent to Bob. 269 With key agreement as described, since both Alice and Bob 270 contribute to the value k, and since Alice and Bob will 271 typically periodically generate new private values i and r 272 (perhaps even for every single M), compromise of one party 273 is far less catastrophic, and an attacker who gets access to 274 one private value gets far less benefit. 276 2.3 What about a Man-in-the-Middle? 278 But OE is not resilient to Man-in-the-Middle (MITM) attacks. The 279 problem is that Alice does not know that it was really Bob's public 280 value that she received; it could have been Charlie's public value 281 sent by Charlie. And Charlie could also send Bob his public value 282 pretending to be Alice. Now Charlie can share a key with Alice and 283 a key with Bob so that Charlie can sit between Alice and Bob 284 decrypting what he gets from Alice and then re-encrypting it to send 285 to Bob. Neither Alice nor Bob can tell that Charlie is present as a 286 "Man-in-the-Middle" and both Alice and Bob think they are safely 287 exchanging encrypted messages. 289 A MITM attack like that is bad and making a protocol proof against 290 such attacks comes at the cost of the key-management burden described 291 in Section 2.1. Most IETF protocols to date require that such MITM 292 attacks not be feasible. 294 However, despite its vulnerability to MITM attacks, OE still has 295 value in some circumstances. This value arises because of the 296 difficulty of inserting a MITM actor, and the cost of processing for 297 the MITM in the case of a very large number of OE relationships. In 298 particular, where the choice is between no encryption (as has been 299 the case for MPLS to date) and OE, it is clear that using OE offers 300 better (although not the best) security. 302 Consider the case where an attacker taps a link on the path between 303 Alice and Bob. In this case, the attacker can capture every packet 304 between the two parties, and if there is no encryption, can read 305 every message. Furthermore, consider that the attacker could tap a 306 fiber in the core of the network and so capture every packet between 307 a large number of Alices and their corresponding Bobs. In these 308 cases, Charlie can operate as a "passive MITM" since all he has to do 309 is watch the packets. 311 With OE in use, Charlie is forced to be an "active MITM". That is he 312 must engage in the D-H exchange between each pair of Alices and Bobs, 313 and he must must decrypt and encrypt each packet he wants to inspect. 314 This imposes a higher cost and is especially burdensome if he is 315 attempting to do it in parallel for lots of Alice/Bob pairs using 316 lots of different keys and communication sessions. 318 Furthermore, when D-H is in use for OE, management tools can be used 319 to detect the presence of Charlie as a MITM. This is because 320 Charlie has to agree one key "kA" with Alice, and a different key 321 "kB" with Bob. As far as we know, Charlie cannot arrange that kA 322 equals kB because both sides contribute to the key value in the D-H 323 key agreement. That means that if Alice and Bob can check with each 324 other what value of "k" they are using and the values do not match, 325 then they know that Charlie is present. What is more, Alice and Bob 326 can make this check on the value of "k" for any of the "E(k,M)" they 327 ever exchanged. 329 Thus, in the case of a fiber tap where many Alice/Bob pairs are 330 being monitored, it only takes one Alice and Bob to detect the MITM 331 attack for all Alice/Bob pairs to be alerted to the problem. In 332 such cases the cost of detection for Charlie may be even greater than 333 the cost of performing the MITM attack. 335 Hence we conclude that OE can have considerable value when used in 336 MPLS networks. 338 2.4 OE in MPLS Overview 340 [[Editor Note - the details here are suitable for an early revision 341 draft. 342 We might change to ECDH later, or to use another KDF, or symmetric 343 cipher mode. All that is for discussion.]] 345 The basic requirement for MPLS OE is that we want to provide a way 346 for two MPLS nodes to do an OE key exchange and to derive a session 347 key from that to use in MPLS packet encryption. 349 To do that we use a Diffie-Hellman key exchange as outlined in 350 Section 2.2. We model this on IKE [RFC5996] using essentially the 351 same parameters. We feed the shared Diffie-Hellman value, which is 352 g^ir, into a standard key derivation function (KDF) 353 that also takes as input the LSP identifier (LSP ID) together with 354 the sending and receiving LSR IDs - where the the sending LSR is the 355 point of encryption and the receiving LSR is the point of decryption 356 such that the pair of LSRs define the Security Association (SA). 357 These additional inputs are used to ensure that we end up with 358 different keys on an LSP even if the same g^i and g^r values 359 are re-used. The KDF to be used here is as defined in [RFC5869]. 361 D-H values used for MPLS OE MUST be of at least 2048-bits. 362 Implementations of MPLS OE MUST support the 2048-bit modular 363 exponentiation (MODP) group from Section 3 of [RFC3526] and SHOULD 364 support the larger MODP groups from [RFC3526]. 366 This document also defines the mechanism used to derive an identifier 367 for a key (the key-id) from the shared Diffie-Hellman value, which 368 is also based on the KDF output. The key will be used with a 369 symmetric encryption algorithm, such as AEAD_AES_GCM_128 (the 370 default, following [RFC5116]). 372 As with any symmetric block cipher, one should not use the same key 373 for too long. The nonce defined for MPLS OE keys is derived using 374 a 96 bit counter incremented by one for each encrypted packet. 375 It is critical for security that nonce values MUST NOT be re-used 376 with a given key. (This is an inherent issue with how AES-GCM or any 377 counter mode achieves high performance.) 379 Accordingly, implementations are RECOMMENDED to change keys at least 380 every 2^32 packets, and MUST change keys before encrypting 2^64 381 packets. For an LSP running over a fully-busy 100Gbe interface, 382 we might assume that means roughly 160 million packets per second, 383 or roughly 2^44 packets per day. The 2^64 limit therefore means 384 changing keys daily in the busiest cases of some of the largest 385 current links capacities. 387 To support key change, this document defines a way for two LSRs using 388 a key on an LSP to agree a new key and to switch over to using that 389 key when desired. That means that implementations MUST be able to 390 handle at least two keys (old and new) for a given LSP. Once a new 391 key has been agreed then it should be used for sending packets; once 392 encrypted data packets protected with the new key have been 393 successfully received, the old key should be discarded. Section 4 394 describes how two LSRs agree keys, and to agree a new key, two LSRs 395 simply run the same key agreement exchange, but this time protected 396 with the old session key as described in Section 4.3. This process 397 can, of course, be repeated any number of times for the same LSP. It 398 is RECOMMENDED that the key on an LSP be changed at least once every 399 day or every 10^6 packets whichever is sooner. 400 [[Editor Note: These values need considered in the light of latest 401 cryptology advice, but also understanding that this is "best- 402 effort" OE]] 404 In the event of a key agreement exchange or decryption failure, an 405 alarm MUST be raised to the operator. Default (i.e., node-wide) and 406 per-LSP behavior SHOULD be configurable in this case: actions may 407 include reverting to non-encrypted traffic, re-attempting key 408 exchange, or tearing down the LSP. Note that a simple attack on OE 409 is to tamper with key agreement exchange messages or encrypted 410 packets so that OE fails. Such attacks may be intended to cause the 411 LSP to operate without encryption, so an operator should consider 412 this when setting the behavior in this case. 414 Section 7.1 also discusses a mechanism that allows a pair of LSRs 415 using OE on an LSP to detect that a MITM attack has happened. For 416 this, we simply define a function of the shared secret, which can be 417 logged and later compared. Note that logging a sample of these 418 "witness" values will likely be sufficient to detect pervasive MITM 419 attacks. As with the key-id, we base this on the same KDF output. 421 An additional discussion of the applicability of MPLS OE is found in 422 Section 5. 424 3. MPLS Packet Encryption 426 MPLS packets may be individually encrypted according to the 427 mechanisms described in this section. 429 When an MPLS packet is encrypted, this is indicated by the insertion 430 of a new special purpose label [ID.ietf-mpls-special-purpose-labels] 431 in the label stack. This is referred to as the Opportunistic 432 Encryption Label Indicator (OELI). The format of the OELI is 433 described in Section 3.1. 435 The OELI is followed immediately by a further label stack entry that 436 contains an identifier of the key and algorithm that is in use. This 437 label stack entry is referred to as the Opportunistic Encryption 438 Label (OEL). The format of the OEL is described in Section 3.2. 440 The OEL MUST have the bottom of stack bit (the S bit) set and MUST be 441 followed by a pseudowire control word [RFC4385]. The format of the 442 control word is described in Section 3.3. 444 The remainder of the MPLS packet is encrypted and cannot be parsed 445 without decryption. Implementations MUST support the 446 AEAD_AES_GCM_128 encryption algorithm, as specified in Section 5.1 447 of [RFC5116], which is the default as described in Section 4.2 of 448 this document. 450 Note that it is critical that a new nonce is used for every 451 encryption. The nonce is an implicit packet counter. The 452 initial nonce value is derived from the HKDF output at key 453 agreement time and the counter is incremented by one for 454 each packet encrypted on the sending side and by one 455 for each packet successfully decrypted on the receiver side. 457 Although the nonce is not transmitted with the packets, a 3-bit 458 counter indicates the nonce value modulo 8. This feature allows a 459 receiving node to quickly spot that a packet has been dropped and 460 resynch its own counter in order to be able to continue to decrypt 461 received packets. In the event that more than 7 packets are lost in 462 one batch the receiver will encounter a decryption error. In this 463 case the receiver may report a general decryption error or may 464 attempt to resynchronize by advancing its own counter in units of 8 465 according to the modulo value in the received packet. Note that 466 incrementing the counter in order to test for decryption failure 467 does generate a potential DoS if e.g. an attacker decrements the 468 nonce-mod-8 value. Implementations that do such tests SHOULD 469 maintain a small maximum window size beyond which they will cease 470 attempting to decrypt. It could be that throwing an error might 471 be the more effective response if the packet loss rates are 472 expected to be low enough. 474 It should also be noted that the output from encryption will be 16 475 octets longer than the input. 477 The bottom of stack bit is set in the OEL to stop implementations 478 continuing to search down the label stack (which is encrypted) and 479 attempting to use the data as though it was a valid label stack. The 480 control word is needed because many implementations that find the 481 bottom of stack expect the next bytes to be a control word or 482 protocol indicator. 484 The position of the OELI, OEL, and control word depend on whether 485 hop-by-hop or end-to-end encryption is being applied. 487 Figure 1 illustrates the format of an example MPLS packet before and 488 after hop-by-hop opportunistic encryption. The left hand part of the 489 figure shows a normal MPLS packet with a label stack and payload. 490 The bottom label in the stack has the S bit set. The payload is the 491 data carried by the MPLS packet (such as IP) and may be prefixed by a 492 control word. 494 The right hand part of Figure 1 shows the same packet after it has 495 been encrypted. The top of stack is the OELI followed by the OEL 496 with the S bit set. The OEL is followed by a control word. 497 Everything that follows the control word is the entire original MPLS 498 packet encrypted. 500 ----------- . ----------- 501 | Top Label | . | OELI | 502 +-----------+ . +-----------+ 503 | Label | . | OEL S=1 | 504 +-----------+ . +-----------+ 505 | Label S=1 | .| Ctrl Word | 506 +-----------+ +-----------+ 507 | | | | 508 ~ Payload ~ ~ Encrypted ~ 509 | | | | 510 -----------........----------- 512 Figure 1 : The Use of the OEL for Hop-by-Hop Opportunistic Encryption 514 Figure 2 illustrates the format of an example MPLS packet before and 515 after end-to-end opportunistic encryption. The left hand part of the 516 figure shows a normal MPLS packet with a label stack and payload. 517 The bottom label in the stack has the S bit set and the payload may 518 be prefixed by a control word. The right hand part of the figure 519 shows how the top two labels (or however many labels are needed for 520 end-to-end delivery) remain at the top of the label stack. Then 521 follows the OELI and OEL with S bit set, and a control word. The 522 remainder of the packet is encrypted and contains the rest of the 523 label stack and the payload. 525 ----------- ----------- 526 | Top Label | | Top Label | 527 +-----------+ +-----------+ 528 | Label | | Label | 529 +-----------+. +-----------+ 530 | Label | . | OELI | 531 +-----------+ . +-----------+ 532 | Label | . | OEL S=1 | 533 +-----------+ . +-----------+ 534 | Label S=1 | .| Ctrl Word | 535 +-----------+ +-----------+ 536 | | | | 537 ~ Payload ~ ~ Encrypted ~ 538 | | | | 539 -----------........----------- 541 Figure 2 : The Use of the OEL for End-to-End Opportunistic Encryption 543 3.1. Opportunistic Encryption Label Indicator 545 The Opportunistic Encryption Label Indicator (OELI) is a normal label 546 stack entry carrying a special purpose label with value TBD1 to be 547 assigned by IANA. The format of the label stack entry is defined in 548 [RFC3032] and shown in Figure 3. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Label | TC |S| TTL | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Figure 3 : Format of the OELI Label Stack Entry 558 Label: Set to TBD1 to indicate this is an OELI 559 TC: SHOULD be copied from the TC of the first encrypted label. 560 S: MUST be set to zero. 561 TTL: SHOULD be set to the TTL of the first encrypted label. 563 3.2. Opportunistic Encryption Label 565 The Opportunistic Encryption Label (OEL) is carried in a normal label 566 stack entry immediately following an OELI. The format of the label 567 stack entry is defined in [RFC3032] and shown in Figure 4. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Label | TC |S| TTL | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 4 : Format of the OEL Label Stack Entry 577 Label: Any value from 16 to 1048575 used as a look-up into a table of 578 encryption algorithms and keys that has been established 579 through configuration or dynamic key exchange as described in 580 Section 4. 581 This label MUST NOT be used for forwarding, and MUST NOT come 582 from the range 0 through 15. 583 TC: This field contains the packet counter (nonce) for the 584 encryption algorithm and key currently in use modulo 8. It 585 can be used by a receiver to quickly check that the value of 586 the nonce being used for decryption is likely to be correct. 587 S: MUST be set to one. 588 TTL: SHOULD be set to zero to prevent encrypted packets being 589 accidentally forwarded beyond the point of intended 590 decryption. 592 3.3. Control Word 594 The control word is inserted after the OEL as described in Section 3. 595 The S bit set to one in the OEL and the presence of the control word 596 helps protect against transit nodes that may perform hashing or 597 inspection of the label stack and payload packet headers when 598 forwarding MPLS packets (for example, to enable ECMP). The control 599 word indicates that the payload is not a protocol that can be 600 meaningfully hashed or inspected. 602 The format of the control word is defined in [RFC4385] and shown in 603 Figure 5. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |0 0 0 1|Version| Reserved | Channel Type | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 5: Control Word for Opportunistically Encrypted MPLS 613 Version: MUST be zero. 614 Reserved: MUST be sent as 0, and ignored on receipt. 615 Channel Type: Set to TBD2 to indicate that the following bytes are 616 encrypted MPLS. 618 3.4. Considerations for ECMP 620 As previously stated, the S bit set in the OEL and the presence of 621 the control word prevent implementations from attempting to use the 622 encrypted MPLS packet and its payload to determine a hash value for 623 uses such as ECMP. However, the resultant label stack shown in 624 Figure 2 will probably not provide sufficient entropy for ECMP 625 purposes. 627 In order to increase the entropy, an implementation that inserts an 628 OELI and OEL MAY also insert an Entropy Label Indicator (ELI) and 629 Entropy Label (EL) as defined in [RFC6790]. The ELI and EL are 630 positioned in the label stack before the OELI and OEL. The setting 631 of the fields in the ELI and EL label stack entries are as described 632 in [RFC6790]. 634 The ELI and EL will normally occur immediately before the OELI, but 635 they MAY be placed higher up the label stack. 637 ----------- 638 | Top Label | 639 +-----------+ 640 | Label | 641 ----------- +-----------+ 642 | Top Label | | ELI | 643 +-----------+ +-----------+ 644 | Label | | EL | 645 +-----------+. +-----------+ 646 | Label | . | OELI | 647 +-----------+ . +-----------+ 648 | Label | . | OEL S=1 | 649 +-----------+ . +-----------+ 650 | Label S=1 | .| Ctrl Word | 651 +-----------+ +-----------+ 652 | | | | 653 ~ Payload ~ ~ Encrypted ~ 654 | | | | 655 -----------........----------- 657 Figure 6 : The Use of ELI and EL with OEL 659 3.5. Backward Compatibility 661 Keys and encryption algorithms may be configured manually or 662 exchanged dynamically as described in Section 4. These mechanisms 663 provide a preliminary way to protect against a sender encrypting data 664 that the receiver cannot decrypt, however, misconfiguration may lead 665 to a sender using the OELI when the receiver does not support 666 opportunistic encryption. 668 When a node finds an unknown label at the top of the label stack it 669 must discard the packet as described in [RFC3031]. Therefore, when a 670 receiver discovers the OELI and does not support opportunistic 671 encryption it will discard the packet. The net result is that when a 672 sender uses opportunistic encryption in error, all packets that it 673 sends on the LSP will be discarded by the receiver. Note that in 674 this discussion, "the receiver" may be the next hop if single hop 675 encryption is used, or may be the end of the LSP if end-to-end 676 encryption is used. 678 Transit nodes that are not actively participating in the encryption 679 will not inspect the OELI except potentially as part of an ECMP hash. 680 This means that transit nodes will not encounter the OELI during 681 normal packet processing and will not discard packets. 683 3.6. MTU Considerations 685 Adding the OELI and OEL as described above will reduce the available 686 data size by 8 octets. Furthermore, as described in in Section 3, 687 the output of the encryption algorithm is 16 octets longer than the 688 input. Therefore, the use of MPLS OE reduces the available MTU by 20 689 octets. 691 When end-to-end OE is in use this can be considered by the ingress 692 LSR, however, when single-hop OE is in use the participating LSRs 693 need to advertise this reduction in link MTU so that the packets do 694 not overflow. MPLS packets MUST NOT be fragmented as a result of 695 OE. 697 3.7. Recursive OE 699 The use of OELI, OEL, and control word described in Section 3 may 700 be applied recursively. That is, the payload of an encrypted MPLS 701 packet may, itself be an encrypted MPLS packet. This may be 702 particularly useful in the case where an MPLS VPN has native MPLS 703 traffic. 705 There are no special considerations except to note that encryption 706 and decryption processing may be burdensome if an LSP and its payload 707 LSP have OE applied at the same LSR. Additionally, it should be 708 noted that, as described in Section 3.6, each recursive encryption 709 reduces the MTU by 20 octets. 711 4. Key Exchange For Opportunistic Encryption in MPLS 713 For encryption to be useful both ends of an encrypted session must 714 know which algorithm is in use and which key to use. The mechanism 715 described in Section 3 provides a way to indicate an index into a 716 table of algorithms and keys that can be used to decrypt an encrypted 717 MPLS packet. 719 It is possible that this table has been manually configured or set up 720 using a key exchange protocol such as Internet Key Exchange version 2 721 (IKEv2) [RFC5996]. However, such a process implies a stable security 722 association between encrypter and decrypter of MPLS packets. Such a 723 stable association is not consistent with the concept of 724 opportunistic encryption. 726 This section provides a mechanism for adjacent MPLS LSRs, or for a 727 pair of LSRs at opposite ends of an MPLS LSP, to dynamically 728 exchange keys and algorithm identifiers so that encryption may be 729 applied opportunistically. 731 The mechanism uses message exchange in the MPLS Generic Associated 732 Channel (G-ACh) [RFC5586]. This channel is in-band with an LSP and 733 may be used to carry messages between neighbors or between the end 734 points of the LSP. A type field within the common message header, 735 the Associated Channel Header (ACH), is used to indicate the type of 736 message carried. 738 Nodes that receive G-ACh messages and do not understand them, or 739 nodes that understand the G-ACh but do not recognize the ACH message 740 type drop the packets as described in [RFC5586]. 742 4.1. Associated Channel for Key Exchange 744 The Associated Channel Type value TBD3 indicates that the packet 745 contains a Key Exchange Protocol message as defined in Section 4.2. 747 Implementations that do not support key exchange in this manner will 748 discard received packets with this Associated Channel Type as 749 described in [RFC5586]. This will result in no dynamic key exchange, 750 but other key definitions are still supported (such as manual 751 configuration) and may be used to construct a table of algorithms and 752 keys that can be used to achieve MPLS encryption using the mechanisms 753 described in Section 3. 755 Note that TBD3 indicates the use of Diffie-Hellman key exchange. If 756 ECDH is added later a new value will be required. 757 [[Editor Note. An alternative to this is to embed the type of key 758 exchange within the key exchange messages.]] 760 4.2. Key Exchange Protocol 762 A session key is to be established between an initiator (Alice) and 763 a recipient (Bob). The D-H public value for Alice is g^i and for 764 Bob, g^r. The shared Diffie-Hellman value is g^ir. 766 g^ir is represented as a string of octets in big endian 767 order padded with zeros if necessary to make it the length of the 768 modulus. 770 Both g^i and g^r will be 2048 bits long, if the Diffie-Hellman 771 modulus is 2048 bits long. 773 The key exchange payload is modelled on that from Section 3.4 of 774 [RFC5996], and is shown in Figure 7. 776 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 |D| Payload Length | algorithm | Group Num | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | | 782 ~ D-H Public value ~ 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Figure 7 - Key Exchange Message 788 The flag D denotes the direction of the message, '0' indicates a 789 message from initiator (Alice) to recipient. '1' indicates the 790 reverse direction. 792 The Payload Length field contains the number of octets following the 793 payload length field (including the group number). This is 15 bits 794 wide. 796 The algorithm field is a one octet field that specifies both the KDF 797 to use and the symmetric algorithm to be used for data packet 798 encryption. A registry for values of this field is defined in 799 Section 8.3. The value 0 is used to indicate the default KDF and 800 symmetric encryption mode. 802 The Diffie-Hellman Group Num is from [RFC3526], so the group number 803 for 2048 MODP is decimal 14. Note that this is a one octet field, 804 but is two octets in the [RFC5996] equivalent. This is not an issue 805 because there are only 30 MODP groups defined at present and new 806 groups are not added frequently. 808 The D-H public value will contain g^i or g^r depending on the 809 direction (i.e., the setting of the D flag) and is in big endian 810 order. 812 The length of the Diffie-Hellman public value for MODP groups MUST be 813 equal to the length of the prime modulus over which the 814 exponentiation was performed, prepending zero bits to the value if 815 necessary. 817 Once both sides have derived g^ir they need to feed that and the 818 other inputs described in Section 2.4 into the KDF indicated by the 819 algorithm field. With the default algorithm (value zero), the KDF to 820 be used is HKDF as specified in [RFC5869]. 822 The parameters for the use of HKDF are: 824 Hash: SHA-256 826 Salt: not used [[Editor Note: maybe we should?]] 828 Skip: do not skip 830 Info: The catenation of a fixed string indicating use of MPLS OE, 831 with the value "MPLS-OE", the first 32 bits of the key 832 exchange message, with the D flag set to 0, plus the LSP 833 ID and the sender and receiver LSR IDs in that order. That 834 is: 836 MPLS-OE||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID 838 L: The output length in bits is 272. 840 The fixed string "MPLS-OE" is used as an input here to prevent 841 potential cross-protocol attacks. Those might otherwise be 842 possible if this mechanism were to be copied in other protocols. 843 (If copying this mechanism for any reason, then a different 844 fixed string value should be used.) 846 The default encryption algorithm, AEAD_AES_GCM_128, specified 847 in Section 3, requires a 128 bit session key. 849 The 272-bit HKDF output is the catenation of the session key, the key 850 id, the witness value and the high-order 16 bits of the initial nonce 851 value in that order. That is the session key is 852 the leftmost 128 bits of the HKDF output. The key-id is the next 16 853 bits, the witness value is the next 112 bits and the last 16 bits 854 are the 16 most significant bits of the initial nonce value. The 855 low order 64 bits of the initial nonce value are set to zero before 856 the first call to the AES-GCM encryption function. 858 The key-id is prepended with four bits set to one and used as the 859 label value in the OEL (see Section 3.2) so that the label does not 860 take any of the values 0-15. 862 [[Editor note - we might want to consider deriving the witness 863 value from a separate invocation of the KDF that does not depend 864 on the LSP-specific inputs. The benefit from that would be 865 that the same MITM-detection infrastructure could be used for 866 many protocols. However, that would require standardizing a 867 generic D-H MITM-detection protocol, or at least formats, in 868 order to be useful. We also need to consider what additional 869 information needs to be logged with the witness value so that 870 comparisons can easily be made at scale but without creating 871 new privacy-invasive meta-data. (That last is not much of an 872 issue for MPLS-OE, but could be elsewhere.) At present we do 873 not intend to go for the generic MITM-detection approach, but 874 it is worth considering.]] 876 4.3. Protecting the Key Exchange Protocol Messages 878 As described in Section 2.4, once one key exchange has been 879 successfully completed, further key exchanges should be protected 880 using a previous key. This is simply achieved since key exchange 881 messages are, themselves, carried in MPLS packets on the LSP and may 882 be subject to encryption exactly as any other packet. 884 5. Applicability of MPLS Opportunistic Encryption 886 MPLS OE provides another tool in the security and privacy toolkit. 887 It is not a panacea and does not solve (nor is it intended to solve) 888 all security or privacy problems. In particular, the use of MPLS OE 889 does not protect user-data end-to-end that might be better secured 890 using encryption at the IP layer or at higher layers. 892 As noted throughout this document, the intention of OE in MPLS is to 893 allow one LSR to enable encryption between itself and its neighbor, 894 or between itself and the other end of an LSP, in a dynamic and un- 895 planned way. This can have benefits in a number of scenarios where 896 the network that generates MPLS traffic transmits it over another 897 network (for example, carrier's carrier, or some deployments of 898 enterprise network). Additionally, the use of MPLS OE might allow a 899 service provider to offer a secure edge-to-edge service for a variety 900 of applications ranging from VPNs through pseudowires and where the 901 payload traffic might not always be IP. Lastly, in some non- 902 traditional carriers the user data belongs to the operator or is the 903 direct responsibility of the operator (for example, in data centers, 904 or in large-scale private networks). 906 As with all security mechanisms, there is a trade-off between a 907 number of factors. On one side is the completeness of the security 908 of the user-data, and on the other side is the complexity of 909 configuring and managing the necessary security associations. 910 Furthermore, while mechanisms closer to the end-user than MPLS OE 911 (for example, TLS and IPsec in tunnel mode) provide better security 912 for user-data by virtue of not transmitting the data across any 913 network hops without it being encrypted, such mechanisms often 914 expose more metadata for inspection by snoopers within the network. 916 Additionally, while a variety of per-link encryption mechanisms exist 917 and could be used to guard against attacks such as fiber taps, those 918 approaches do not protect against subverted nodes (i.e., routers) on 919 the path since, by definition, per-link encryption does not protect 920 packets once they come off the link. MPLS OE in the end-to-end LSP 921 mode protects packets on the links and as they cross transit routers. 923 Nevertheless, it is not the purpose of this document to recommend the 924 use of MPLS OE to the exclusion of all other encryption techniques. 925 As already mentioned, MPLS OE is offered as another tool in the tool 926 kit and users as well as network operators are strongly advised to 927 consider using a variety of tools to achieve the level of security 928 and privacy that they desire. 930 Note that, in order that OE can be used, one end of a peering 931 (neighbor or LSP end) must decide to attempt OE and the other end 932 must support it. This can be determined by the message exchanges 933 described in Section 4.2 since if one peer does not send a key 934 exchange message then encryption will not be used, and if the other 935 peer does not respond then it is unwilling or unable to decrypt 936 messages. 938 MPLS OE should be applicable to all forms of MPLS. That is, it should 939 be possible to use it in RSVP-TE systems, in LDP systems, and in 940 MPLS-TP systems (by which we mean those that have manually configured 941 LSPs). Equally, it should work for point-to-point (P2P) and 942 multipoint-to-point (MP2P) uses of MPLS because there is a simple 943 relationship between the sender (encrypter) and the receiver 944 (decrypter) in both cases. In the MP2P case, the sender's identity 945 can be extracted from the key identifier and there are considered to 946 be enough key identifiers to allow an arbitrary number of senders on 947 the LSP. There will, however, be the need for the receiver to hold OE 948 state (keys, packet counters) for each sender which may be a 949 significant amount of data for an MP2P LSP (although no more than if 950 the same LSP were replaced by multiple P2P LSPs). Additionally, it 951 should be noted that not only will each sender on an MP2P LSP have a 952 different key, but each may separately decide whether to encrypt data 953 or not. 955 At this time it is not certain whether MPLS OE can be applied to a 956 point-to-multipoint (P2MP) or a multipoint-to-multipoint LSP in its 957 entirety because packet replication cannot handle the necessary key 958 conversions for each receiver. However, MPLS OE can certainly be 959 applied to individual hops on these LSPs. Further work is needed to 960 determine whether non-branching multi-hop segments of P2MP and MP2P 961 LSPs can also be protected using MPLS OE. 963 6. Security Considerations 965 6.1. Security Improvements 967 See section 2.1. 969 6.2. Continued Vulnerabilities 971 The mechanisms described in this document do not provide protection 972 against certain types of MITM attacks. For example, the key exchange 973 protocol in Section 4.2 will not detect if key exchange messages or 974 their responses are intercepted and discarded such that the 975 initiating peer believes that encryption is not supported. 976 Similarly, those messages may be tampered with such that a receiver 977 cannot determine the correct table index to algorithm and key mapping 978 when an encrypted packet is received. Furthermore, the OEL in an 979 MPLS packet is not protected and may be overwritten such that a 980 receiver is unable to decrypt the packet. 982 See Section 7.1 for a discussion of how active MITM attacks can be 983 detected. 985 6.3. New Security Considerations 987 If a pair of LSRs do not do the key exchange before sending any data 988 packets on the LSP then those first packets will not be protected by 989 OE and hence will be available to a monitor. 991 If a MITM can prevent the OE key exchange from completing, e.g. 992 via deleting messages or changing bits in messages, and if the LSRs 993 continue to send data regardless then those data packets will be 994 available to a monitor. See Section 2.4 and Section 7 for a 995 description of how alarms should be raised in these circumstances. 997 7. Manageability Considerations 999 As described in Section 2.4 node-wide and per-LSP behavior SHOULD be 1000 configurable to describe the action where key agreement exchange or 1001 packet decryption fails. In any case, such events MUST trigger 1002 alarms to the operator. 1004 7.1. MITM Detection 1006 Section 2.4 introduces the concept of a function of the shared 1007 secret that can be compared by two LSRs that are using OE to see 1008 whether they are victims of an active MITM attack. 1010 Section 4.2 describes how a witness value is derived for the 1011 default KDF, HKDF. 1013 The participating LSRs can simply log this value plus the LSP 1014 and LSR IDs from time to time and a management application can 1015 compare the values. If they are different for the same LSP ID, 1016 then an active MITM attack has taken place. 1018 It needs to be carefully noted that the management channel used to 1019 log or otherwise compare the witness values from the two LSRs MUST be 1020 secure. It is likely that routers use relatively high security 1021 management channels for configuration and other management 1022 operations. 1024 [[Editor note - please see the note in 4.2 about generic 1025 MITM-detection. Changes there could affect what needs to be 1026 done here.]] 1028 8. IANA Considerations 1030 8.1. Opportunistic Encryption Label Indicator 1032 IANA maintains a registry called "Multiprotocol Label Switching 1033 Architecture (MPLS) Label Values" with a single sub-registry called 1034 "Label Values". This registry is to be renamed "Special Purpose MPLS 1035 Label Values according to [ID.ietf-mpls-special-purpose-labels]. 1037 IANA is requested to assign a value from this registry as follows: 1039 Value | Description | Reference 1040 ------+-------------------------------------------------+----------- 1041 TBD1 | Opportunistic Encryption Label Indicator (OELI) | [This.ID] 1043 The value 8 is suggested. 1045 [RFC Editor is requested to replace the string "TBD1" with the value 1046 assigned by IANA throughout this document, and to remove this note.] 1048 8.2. Pseudowire Associated Channel Types 1050 IANA maintains a registry called "Pseudowire Name Spaces (PWE3)" with 1051 a sub-registry called "Pseudowire Associated Channel Types". IANA is 1052 requested to assign a value as follows: 1054 Value | Description | Reference 1055 ------+-------------------------------------------------+----------- 1056 TBD3 | Opportunistic Key Exchange Protocol for MPLS | [This.ID] 1057 TBD2 | Opportunistically Encrypted MPLS | [This.ID] 1059 The values 19 and 20 are suggested. It is suggested that TBD3 have 1060 a value 1 smaller than TBD2. 1062 [RFC Editor is requested to replace the string "TBD2" and "TBD3" with 1063 the values assigned by IANA throughout this document, and to remove this 1064 note.] 1066 8.3. Key Derivation Functions and Symmetric Algorithms 1068 IANA is requested to create a new MPLS registry called the "MPLS 1069 Opportunistic Encryption Algorithms Registry". New values are to 1070 be assigned through "IETF Review" as defined in [RFC5226]. 1072 The available range is 0 - 255. 1074 IANA is requested to record the following information and create an 1075 initial entry as follows: 1077 Value | Key Derivation Function | Symmetric Algorithm | Reference 1078 ------+-------------------------+---------------------+----------- 1079 0 | HKDF | AEAD_AES_GCM_128 | [This.I-D] 1080 1-255 | Unassigned | | 1082 9. Acknowledgements 1084 Many thanks to Alia Atlas for detailed discussion of the implications 1085 of MPLS opportunistic encryption. Thanks also to Ron Bonica for 1086 encouraging this work, to Sean Turner and Stewart Bryant for early 1087 review, and to Jeff Haas and Ross Callon for discussions. 1089 10. References 1091 10.1. Normative References 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1096 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1097 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1098 Use over an MPLS PSN", RFC 4385, February 2006. 1100 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1101 Associated Channel", RFC 5586, June 2009. 1103 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1104 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1105 RFC 6790, November 2012. 1107 [ID.ietf-mpls-special-purpose-labels] 1108 Kompella, K., Andersson, L., and A. Farrel, "Allocating 1109 and Retiring Special Purpose MPLS Labels" draft-ietf-mpls- 1110 special-purpose-labels, work in progress. 1112 [RFC3526] Kivinen, T., and M. Kojo, "More Modular Exponential (MODP) 1113 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1114 RFC 3526, May 2003. 1116 [RFC5116] D. McGrew, "An Interface and Algorithms for Authenticated 1117 Encryption", RFC 5116, January 2008. 1119 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1120 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1121 May 2008. 1123 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1124 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1126 10.2. Informative References 1128 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1129 Label Switching Architecture", RFC 3031, January 2001. 1131 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1132 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1133 Encoding", RFC 3032, January 2001. 1135 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1136 December 2005. 1138 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1139 RFC 4303, December 2005. 1141 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1142 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1143 RFC 5996, September 2010. 1145 Authors' Addresses 1147 Adrian Farrel 1148 Juniper Networks 1150 EMail: adrian@olddog.co.uk 1152 Stephen Farrell 1153 Trinity College Dublin 1154 Dublin, 2 1155 Ireland 1157 Phone: +353-1-896-2354 1158 Email: stephen.farrell@cs.tcd.ie