idnits 2.17.1 draft-farrelll-mpls-opportunistic-encrypt-02.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 (February 10, 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: August 10, 2014 S. Farrell 6 Trinity College, Dublin 7 February 10, 2014 9 Opportunistic Encryption in MPLS Networks 11 draft-farrelll-mpls-opportunistic-encrypt-02.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 .............................. 12 73 3.2. Control Word ................................................ 13 74 3.3. Considerations for ECMP ..................................... 13 75 3.4. Backward Compatibility ...................................... 14 76 3.5. MTU Considerations .......................................... 15 77 3.6. Recursive OE ................................................ 15 78 4. Key Exchange For Opportunistic Encryption in MPLS ............. 15 79 4.1. Associated Channel for Key Exchange ......................... 16 80 4.2. Key Exchange Protocol ....................................... 16 81 4.3. Protecting the Key Exchange Protocol Messages ............... 19 82 5. Applicability of MPLS Opportunistic Encryption ................ 19 83 6. Security Considerations ....................................... 21 84 6.1. Security Improvements ....................................... 21 85 6.2. Continued Vulnerabilities ................................... 21 86 6.3. New Security Considerations ................................. 21 87 7. Manageability Considerations .................................. 22 88 7.1. MITM Detection .............................................. 22 89 8. IANA Considerations .......................................... 22 90 8.1. Opportunistic Encryption Label Indicator .................... 22 91 8.2. Pseudowire Associated Channel Types ......................... 23 92 8.3. Key Derivation Functions and Symmetric Algorithms ........... 23 93 9. Acknowledgements ............................................. 24 94 10. References .................................................. 24 95 10.1. Normative References ...................................... 24 96 10.2. Informative References .................................... 24 97 Authors' Addresses ............................................... 25 99 1. Introduction 101 MPLS is an established data plane protocol in the Internet. It is 102 found in the majority of core service provider networks and most end- 103 to-end traffic in the Internet will be carried over MPLS at some 104 point in its path. The MPLS data plane is defined by [RFC3031] and 105 [RFC3032]. 107 Data security (i.e., confidentiality) in MPLS has previously relied 108 on just two features: 110 - Physical isolation of MPLS networks has been used to ensure that 111 interception of MPLS traffic was not possible. 113 - Higher-layer protocol security (such as IPsec [RFC4302], [RFC4303]) 114 has been used whenever a particular flow has determined that 115 security was desirable. 117 These features have a number of significant vulnerabilities: 119 - Networks are increasingly easily compromised physically such that 120 "taps" may be inserted in links between routers. 122 - Routers may be compromised either in their entirety or through 123 the management/control plane (or misconfiguration). This may 124 result in packets being diverted to transit inspection points on 125 their way to their destination. 127 - The increased support for point-to-multipoint (P2MP) MPLS means 128 that routers can easily be configured (or misconfigured) to make a 129 copy of data and to send it to an additional destination. 131 - End-to-end payload security may be hard to manage and operate and 132 is not turned on by default by many users. While this form of 133 security is desirable, the network should also improve the security 134 of data transfer that it offers. 136 This document describes a mechanism for opportunistic encryption of 137 the MPLS data plane. It shows what part of an MPLS packet may be 138 encrypted and provides a way to indicate that the packet is encrypted 139 as well as to carry a key identifier with each packet. 141 MPLS opportunistic encryption can be achieved between adjacent Label 142 Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and 143 also between end points of an LSP. 145 This document also provides a mechanism for keys to be exchanged to 146 facilitate encryption. Finally, this document describes the 147 applicability of opportunistic encryption in MPLS networks with an 148 indication of the level of improved security as well as the continued 149 vulnerabilities. 151 This document does not describe security for MPLS control plane 152 protocols. 154 Please note that a discussion of the applicability of MPLS 155 Opportunistic Encryption is provided in Section 5. 157 2. Principles of Opportunistic Encryption 159 [[Editor note - the introductory material in Sections 2.1 to 2.3 160 here will likely be mostly or fully replaced with a reference to 161 a more generic OE draft that is in the process of being written. 162 That may lead to some terminology changes, but shouldn't impact 163 on functionality.]] 165 2.1 Why Do We Need Opportunistic Encryption? 167 To introduce this discussion we start from a basic view of how 168 encryption is used in IETF protocols. 170 Say we have two protocol entities, Alice and Bob, and they would like 171 some message "M" sent from Alice to Bob to have confidentiality. 172 Then Alice needs to send M encrypted with algorithm "E" under some 173 some symmetric (e.g., AES) key, "k". Thus Alice wants to send Bob 174 "E(k,M)", but since she and Bob don't yet have such a shared secret 175 they need to agree on the key, "k". 177 In many IETF protocols, such as TLS (as commonly used) or S/MIME 178 (CMS) or PGP, Alice simply invents a random key "k" and then encrypts 179 that under Bob's public key "Pub-b" and sends Bob E(Pub-b,k) and 180 E(k,M) together. (There are lots of other details and other options 181 for how this can be handled, but we ignore those for now.) In such 182 cases, before Alice can send "E(k,M)", she needs to first get Bob's 183 public key and she needs to be certain that it really is Bob's public 184 key and not Charlie's. That knowledge requires some long-term key 185 management, which is often done using a Public Key Infrastructure 186 (PKI) so that Alice actually stores the public key (Pub-ca) of a 187 Certification Authority (CA), and Bob gets his public key (Pub-b) 188 "certified" by the CA, which means the CA creates a digitally signed 189 data structure "Cert(Pub-ca,Pub-b)". The crucial thing is that 190 Alice, Bob, and a CA need to co-ordinate before Alice and Bob can 191 agree on a key "k", and that process imposes a key-management burden. 193 Doing such key management is clearly quite possible, since TLS and 194 IPsec and other well-deployed technologies depend on it. But, in 195 the case of HTTP/TLS on the public web, we see that only roughly 30% 196 of web sites actually take on this burden, even though the software 197 required is ubiquitous and, at least for 2nd level DNS domains in 198 .com for example, there are CAs who offer free domain-validated 199 certificates. While, some of the 70% who don't set up certificates 200 might not actually want confidentiality, there are certainly some who 201 would and arguably many that would benefit from confidentiality, if 202 it just happened out of the box, without an administrator having to 203 do anything. And there are also arguably many other protocols where 204 the same is true. 206 Opportunistic encryption (OE) offers a mechanisms to achieve 207 encryption between Alice and Bob without resorting to key-management 208 through CAs and without relying on manual configuration of keys. 210 2.2 Opportunistic Encryption at 10,000ft 212 Instead of the "key transport" mechanisms described in Section 2.1, 213 opportunistic encryption uses "key agreement". With key agreement, 214 both Alice and Bob contribute to calculating "k" (instead of the 215 the mechanism where Alice invents "k" and safely transports it to 216 Bob encrypted with Bob's public key as "E(Pub-b,k)"). 218 Assume that Alice and Bob are using some protocol where they can 219 exchange a few messages in order to agree on the key "k" to use. 220 With a Diffie-Hellman key agreement ("D-H") both Alice and Bob have 221 public and private values, where the private value can be randomly 222 generated, perhaps even once per message "M". They swap the public 223 values, and can then, thanks to the "magic" of Diffie-Hellman, derive 224 a key "k" that nobody else can know. 226 In this way Alice sends Bob "Pub-a" and Bob sends Alice "Pub-b" and 227 at that point both of them can safely calculate a shared secret "k" 228 from those values. And after that Alice can send Bob "E(k,M)". 230 From here on, we change the terminology slightly and refer to 231 Alice as the initiator, with private key "i" and Bob as the 232 recipient, with private key "r" so that our notation is closer 233 to that used in IPsec's IKE, on which we model our use of OE. 235 The "magic" of D-H works as follows. Let "p" be well-known large 236 prime number that we use for all modular arithmetic (meaning that 237 "a^b" is actually "(a^b) mod p"), and let "g" be another well-known 238 value (called a generator for the group determined by "p"). Also let 239 Alice and Bob's private values be "i" and "r" respectively. 240 Now, if Alice sends Bob "g^i" as her public value, and Bob 241 similarly sends Alice "g^r" then both of them can easily 242 calculate "g^(i*r)" or "g^ir" but nobody else can, since calculating 243 "x" when only given "g^x" is a computationally hard 244 problem for any "x". Once both Alice and Bob have the value "g^ir" 245 in hand, they can easily derive a value "k" from that using any of a 246 number of well-known key derivation functions (KDF). 248 As you can see from the above, Alice and Bob do not need to pre- 249 arrange anything other than "g" and "p", and those can be public 250 values, that are used by everyone everywhere (or at least by all 251 participants in a particular deployment). Yet, Alice and Bob have 252 managed to derive a common value for a key "k" that they can use to 253 encrypt (and decrypt) "M". 255 This kind of opportunistic encryption provides strong confidentiality 256 and can be built into any protocol that allows Alice and Bob to 257 occasionally exchange public values. 259 There are also additional advantages to key agreement when compared 260 to key transport. The most important of those is that with key 261 agreement we can easily ensure that k has a property called Perfect 262 Forward Secrecy (PFS). That means that an attacker has to separately 263 attack each key k. In contrast, if we use the key transport 264 approach, then an attacker who somehow accesses Bob's private key 265 "Priv-b" can record lots of traffic and later go back and decrypt all 266 the "E(Pub-b,k)" values that all Alice's ever sent to Bob. With key 267 agreement as described, since both Alice and Bob contribute to the 268 value k, and since Alice and Bob will typically periodically generate 269 new private values i and r (perhaps even for every single M), 270 compromise of one party is far less catastrophic, and an attacker who 271 gets access to 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 arrange that kA 319 equals kB because both sides contribute to the key value in the D-H 320 key agreement. That means that if Alice and Bob can check with each 321 other what value of "k" they are using and the values do not match, 322 then they know that Charlie is present. What is more, Alice and Bob 323 can make this check on the value of "k" for any of the "E(k,M)" they 324 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. We might change to ECDH later, or to use another KDF, or 339 symmetric cipher mode. All that is for discussion.]] 341 The basic requirement for MPLS OE is that we want to provide a way 342 for two MPLS nodes to do an OE key exchange and to derive a session 343 key from that to use in MPLS packet encryption. 345 To do that we use a Diffie-Hellman key exchange as outlined in 346 Section 2.2. We model this on IKE [RFC5996] using essentially the 347 same parameters. We feed the shared Diffie-Hellman value, which is 348 g^ir, into a standard key derivation function (KDF) that also takes 349 as input the LSP identifier (LSP ID) together with the sending and 350 receiving LSR IDs - where the the sending LSR is the point of 351 encryption and the receiving LSR is the point of decryption such that 352 the pair of LSRs define the Security Association (SA). These 353 additional inputs are used to ensure that we end up with different 354 keys on an LSP even if the same g^i and g^r values are re-used. The 355 KDF to be used here is as defined in [RFC5869]. 357 D-H values used for MPLS OE MUST be of at least 2048-bits. 358 Implementations of MPLS OE MUST support the 2048-bit modular 359 exponentiation (MODP) group from Section 3 of [RFC3526] and SHOULD 360 support the larger MODP groups from [RFC3526]. 362 This document also defines the mechanism used to derive an identifier 363 for a key (the key-id) from the shared Diffie-Hellman value, which 364 is also based on the KDF output. The key will be used with a 365 symmetric encryption algorithm, such as AEAD_AES_GCM_128 (the 366 default, following [RFC5116]). 368 As with any symmetric block cipher, one should not use the same key 369 for too long. The nonce defined for MPLS OE keys is derived using 370 a 96 bit counter incremented by one for each encrypted packet. 371 It is critical for security that nonce values MUST NOT be re-used 372 with a given key. (This is an inherent issue with how AES-GCM or any 373 counter mode achieves high performance.) 375 Accordingly, implementations are RECOMMENDED to change keys at least 376 every 2^32 packets, and MUST change keys before encrypting 2^64 377 packets. For an LSP running over a fully-busy 100Gbe interface, 378 we might assume that means roughly 160 million packets per second, 379 or roughly 2^44 packets per day. The 2^64 limit therefore means 380 changing keys daily in the busiest cases of some of the largest 381 current links capacities. 383 To support key change, this document defines a way for two LSRs using 384 a key on an LSP to agree a new key and to switch over to using that 385 key when desired. That means that implementations MUST be able to 386 handle at least two keys (old and new) for a given LSP. Once a new 387 key has been agreed then it should be used for sending packets; once 388 encrypted data packets protected with the new key have been 389 successfully received, the old key should be discarded. Section 4 390 describes how two LSRs agree keys, and to agree a new key, two LSRs 391 simply run the same key agreement exchange, but this time protected 392 with the old session key as described in Section 4.3. This process 393 can, of course, be repeated any number of times for the same LSP. It 394 is RECOMMENDED that the key on an LSP be changed at least once every 395 day or every 10^6 packets whichever is sooner. 397 [[Editor Note: These values need considered in the light of latest 398 cryptology advice, but also understanding that this is "best-effort" 399 OE.]] 401 In the event of a key agreement exchange or decryption failure, an 402 alarm MUST be raised to the operator. Default (i.e., node-wide) and 403 per-LSP behavior SHOULD be configurable in this case: actions may 404 include reverting to non-encrypted traffic, re-attempting key 405 exchange, or tearing down the LSP. Note that a simple attack on OE 406 is to tamper with key agreement exchange messages or encrypted 407 packets so that OE fails. Such attacks may be intended to cause the 408 LSP to operate without encryption, so an operator should consider 409 this when setting the behavior in this case. 411 Section 7.1 also discusses a mechanism that allows a pair of LSRs 412 using OE on an LSP to detect that a MITM attack has happened. For 413 this, we simply define a function of the shared secret, which can be 414 logged and later compared. Note that logging a sample of these 415 "witness" values will likely be sufficient to detect pervasive MITM 416 attacks. As with the key-id, we base this on the same KDF output. 418 An additional discussion of the applicability of MPLS OE is found in 419 Section 5. 421 3. MPLS Packet Encryption 423 MPLS packets may be individually encrypted according to the 424 mechanisms described in this section. 426 When an MPLS packet is encrypted, this is indicated by the insertion 427 of a new special purpose label [ID.ietf-mpls-special-purpose-labels] 428 in the label stack. This is referred to as the Opportunistic 429 Encryption Label (OEL). The format of the OEL is described in 430 Section 3.1. 432 The OEL MUST have the bottom of stack bit (the S bit) set and MUST be 433 followed by a pseudowire control word [RFC4385]. The format of the 434 control word is described in Section 3.2. 436 The remainder of the MPLS packet is encrypted and cannot be parsed 437 without decryption. Implementations MUST support the 438 AEAD_AES_GCM_128 encryption algorithm, as specified in Section 5.1 439 of [RFC5116], which is the default as described in Section 4.2 of 440 this document. 442 Note that it is critical that a new nonce is used for every 443 encryption. The nonce is an implicit packet counter. The initial 444 nonce value is derived from the HKDF output at key agreement time and 445 the counter is incremented by one for each packet encrypted on the 446 sending side and by one for each packet successfully decrypted on the 447 receiver side. 449 Although the nonce is not transmitted with the packets, a 16-bit 450 counter carried in the control Word indicates the nonce value modulo 451 65536. This feature allows a receiving node to quickly spot that a 452 packet has been dropped and resynch its own counter in order to be 453 able to continue to decrypt received packets. In the event that the 454 counter cannot be resynchronized or that more than 65536 packet are 455 lost in one batch the receiver will encounter a decryption error. In 456 this case the receiver may report a general decryption error or may 457 attempt to resynchronize by advancing its own counter in units of 458 65536 according to the modulo value in the received packet. Note 459 that incrementing the counter in order to test for decryption failure 460 does generate a potential DoS if, e.g., an attacker decrements the 461 nonce-mod-65536 value. Implementations that do such tests SHOULD 462 maintain a small maximum window size beyond which they will cease 463 attempting to decrypt. It could be that throwing an error might 464 be the more effective response if the packet loss rates are 465 expected to be low enough. 467 It should also be noted that the output from encryption will be 16 468 octets longer than the input. 470 The bottom of stack bit is set in the OEL to stop implementations 471 continuing to search down the label stack (which is encrypted) and 472 attempting to use the data as though it was a valid label stack. The 473 control word is needed because many implementations that find the 474 bottom of stack expect the next bytes to be a control word or 475 protocol indicator. 477 The position of the OEL and control word depend on whether hop-by-hop 478 or end-to-end encryption is being applied. 480 Figure 1 illustrates the format of an example MPLS packet before and 481 after hop-by-hop opportunistic encryption. The left hand part of the 482 figure shows a normal MPLS packet with a label stack and payload. 483 The bottom label in the stack has the S bit set. The payload is the 484 data carried by the MPLS packet (such as IP) and may be prefixed by a 485 control word. 487 The right hand part of Figure 1 shows the same packet after it has 488 been encrypted. The top of stack is the OEL with the S bit set. The 489 OEL is followed by a control word. Everything that follows the 490 control word is the entire original MPLS packet encrypted. 492 ----------- . 493 | Top Label | . 494 +-----------+ . ----------- 495 | Label | . | OEL S=1 | 496 +-----------+ . +-----------+ 497 | Label S=1 | .| Ctrl Word | 498 +-----------+ +-----------+ 499 | | | | 500 ~ Payload ~ ~ Encrypted ~ 501 | | | | 502 -----------........----------- 504 Figure 1 : The Use of the OEL for Hop-by-Hop Opportunistic Encryption 506 Figure 2 illustrates the format of an example MPLS packet before and 507 after end-to-end opportunistic encryption. The left hand part of the 508 figure shows a normal MPLS packet with a label stack and payload. 509 The bottom label in the stack has the S bit set and the payload may 510 be prefixed by a control word. The right hand part of the figure 511 shows how the top two labels (or however many labels are needed for 512 end-to-end delivery) remain at the top of the label stack. Then 513 follows the OEL with S bit set, and a control word. The remainder of 514 the packet is encrypted and contains the rest of the label stack and 515 the payload. 517 ----------- 518 | Top Label | 519 +-----------+ ----------- 520 | Label | | Top Label | 521 +-----------+. +-----------+ 522 | Label | . | Label | 523 +-----------+ . +-----------+ 524 | Label | . | OEL S=1 | 525 +-----------+ . +-----------+ 526 | Label S=1 | .| Ctrl Word | 527 +-----------+ +-----------+ 528 | | | | 529 ~ Payload ~ ~ Encrypted ~ 530 | | | | 531 -----------........----------- 533 Figure 2 : The Use of the OEL for End-to-End Opportunistic Encryption 535 3.1. Opportunistic Encryption Label 537 The Opportunistic Encryption Label (OEL) is a normal label stack 538 entry carrying a special purpose label with value TBD1 to be assigned 539 by IANA. The format of the label stack entry is defined in [RFC3032] 540 and shown in Figure 3. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Label | TC |S| TTL | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 3 : Format of the OEL Label Stack Entry 550 Label: Set to TBD1 to indicate this is an OEL 551 TC: SHOULD be copied from the TC of the first encrypted label. 552 S: MUST be set to one. 553 TTL: SHOULD be set to zero to prevent encrypted packets being 554 accidentally forwarded beyond the point of intended 555 decryption. 557 The sending LSR MAY choose different values for the TTL and TC fields 558 if it is known that the OEL will not be exposed as the top label at 559 any point along the LSP (for example, by penultimate hop popping). 561 3.2. Control Word 563 The control word is inserted after the OEL as described in Section 3. 564 The S bit set to one in the OEL and the presence of the control word 565 helps protect against transit nodes that may perform hashing or 566 inspection of the label stack and payload packet headers when 567 forwarding MPLS packets (for example, to enable ECMP). The control 568 word indicates that the payload is not a protocol that can be 569 meaningfully hashed or inspected. 571 The format of the control word is defined in [RFC4385] and shown in 572 Figure 4. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |0 0 0 0| Flags |FRG| Length | Sequence Number | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 4: Control Word for Opportunistically Encrypted MPLS 582 Flags: The Flags field is treated as a four-bit number. It 583 contains the key-id that identifies the algorithm 584 and key as established through configuration or 585 dynamic key exchange as described in Section 4. 586 FRG: Must be sent as 0, and ignored on receipt. 587 Fragmentation is not used. 588 Length: MUST be sent as 0, and ignored on receipt. 589 Sequence Number: This field contains the packet counter (nonce) for 590 the encryption algorithm and key currently in use 591 modulo 65536. It can be used by a receiver to 592 quickly check that the value of the nonce being used 593 for decryption is likely to be correct. 595 3.3. Considerations for ECMP 597 As previously stated, the S bit set in the OEL and the presence of 598 the control word prevent implementations from attempting to use the 599 encrypted MPLS packet and its payload to determine a hash value for 600 uses such as ECMP. However, the resultant label stack shown in 601 Figure 2 will probably not provide sufficient entropy for ECMP 602 purposes. 604 In order to increase the entropy, an implementation that inserts an 605 OEL and OEL MAY also insert an Entropy Label Indicator (ELI) and 606 Entropy Label (EL) as defined in [RFC6790] ELI and EL are positioned 607 in the label stack before the OEL as shown in Figure 5. The setting 608 of the fields in the ELI and EL label stack entries are as described 609 in [RFC6790]. 611 The ELI and EL will normally occur immediately before the OEL, but 612 they MAY be placed higher up the label stack. 614 ----------- 615 | Top Label | 616 ----------- +-----------+ 617 | Top Label | | Label | 618 +-----------+ +-----------+ 619 | Label | | ELI | 620 +-----------+. +-----------+ 621 | Label | . | EL | 622 +-----------+ . +-----------+ 623 | Label | . | OEL S=1 | 624 +-----------+ . +-----------+ 625 | Label S=1 | .| Ctrl Word | 626 +-----------+ +-----------+ 627 | | | | 628 ~ Payload ~ ~ Encrypted ~ 629 | | | | 630 -----------........----------- 632 Figure 5 : The Use of ELI and EL with OEL 634 3.4. Backward Compatibility 636 Keys and encryption algorithms may be configured manually or 637 exchanged dynamically as described in Section 4. These mechanisms 638 provide a preliminary way to protect against a sender encrypting data 639 that the receiver cannot decrypt, however, misconfiguration may lead 640 to a sender using the OEL when the receiver does not support 641 opportunistic encryption. 643 When a node finds an unknown label at the top of the label stack it 644 must discard the packet as described in [RFC3031]. Therefore, when a 645 receiver discovers the OEL and does not support opportunistic 646 encryption it will discard the packet. The net result is that when a 647 sender uses opportunistic encryption in error, all packets that it 648 sends on the LSP will be discarded by the receiver. Note that in 649 this discussion, "the receiver" may be the next hop if single hop 650 encryption is used, or may be the end of the LSP if end-to-end 651 encryption is used. 653 Transit nodes that are not actively participating in the encryption 654 will not inspect the OEL except potentially as part of an ECMP hash, 655 and it should be noted that the use of Special Purpose Labels in 656 hashing is strongly discouraged. This means that transit nodes will 657 not encounter the OEL during normal packet processing and will not 658 discard packets. 660 3.5. MTU Considerations 662 Adding the OEL and Control Word as described above will reduce the 663 available data size by 8 octets. Furthermore, as described in in 664 Section 3, the output of the encryption algorithm is 16 octets longer 665 than the input. Therefore, the use of MPLS OE reduces the available 666 MTU by 24 octets. 668 When end-to-end OE is in use this can be considered by the ingress 669 LSR, however, when single-hop OE is in use the participating LSRs 670 need to advertise this reduction in link MTU so that the packets do 671 not overflow. MPLS packets MUST NOT be fragmented as a result of 672 OE. 674 3.6. Recursive OE 676 The use of OEL and control word described in Section 3 may be applied 677 recursively. That is, the payload of an encrypted MPLS packet may, 678 itself be an encrypted MPLS packet. This may be particularly useful 679 in the case where an MPLS VPN has native MPLS traffic. 681 There are no special considerations except to note that encryption 682 and decryption processing may be burdensome if an LSP and its payload 683 LSP have OE applied at the same LSR. Additionally, it should be 684 noted that, as described in Section 3.6, each recursive encryption 685 reduces the MTU by 24 octets. 687 4. Key Exchange For Opportunistic Encryption in MPLS 689 For encryption to be useful both ends of an encrypted session must 690 know which algorithm is in use and which key to use. The mechanism 691 described in Section 3 provides a way to indicate an index into a 692 table of algorithms and keys that can be used to decrypt an encrypted 693 MPLS packet. 695 It is possible that this table has been manually configured or set up 696 using a key exchange protocol such as Internet Key Exchange version 2 697 (IKEv2) [RFC5996]. However, such a process implies a stable security 698 association between encrypter and decrypter of MPLS packets. Such a 699 stable association is not consistent with the concept of 700 opportunistic encryption. 702 This section provides a mechanism for adjacent MPLS LSRs, or for a 703 pair of LSRs at opposite ends of an MPLS LSP, to dynamically 704 exchange keys and algorithm identifiers so that encryption may be 705 applied opportunistically. 707 The mechanism uses message exchange in the MPLS Generic Associated 708 Channel (G-ACh) [RFC5586]. This channel is in-band with an LSP and 709 may be used to carry messages between neighbors or between the end 710 points of the LSP. A type field within the common message header, 711 the Associated Channel Header (ACH), is used to indicate the type of 712 message carried. 714 Nodes that receive G-ACh messages and do not understand them, or 715 nodes that understand the G-ACh but do not recognize the ACH message 716 type drop the packets as described in [RFC5586]. 718 4.1. Associated Channel for Key Exchange 720 The Associated Channel Type value TBD2 indicates that the packet 721 contains a Key Exchange Protocol message as defined in Section 4.2. 723 Implementations that do not support key exchange in this manner will 724 discard received packets with this Associated Channel Type as 725 described in [RFC5586]. This will result in no dynamic key exchange, 726 but other key definitions are still supported (such as manual 727 configuration) and may be used to construct a table of algorithms and 728 keys that can be used to achieve MPLS encryption using the mechanisms 729 described in Section 3. 731 Note that TBD2 indicates the use of Diffie-Hellman key exchange. If 732 ECDH is added later a new value will be required. 734 [[Editor Note. An alternative to this is to embed the type of key 735 exchange within the key exchange messages.]] 737 4.2. Key Exchange Protocol 739 [[Editor note: This key exchange protocol is bidirectional, yet LSPs 740 are usually unidirectional. That means we need to establish a channel 741 for the return messages (similar to that in LSP Ping) or use a 742 different approach to Diffie-Hellman.]] 744 A session key is to be established between an initiator (Alice) and 745 a recipient (Bob). The D-H public value for Alice is g^i and for 746 Bob, g^r. The shared Diffie-Hellman value is g^ir. 748 g^ir is represented as a string of octets in big endian 749 order padded with zeros if necessary to make it the length of the 750 modulus. 752 Both g^i and g^r will be 2048 bits long, if the Diffie-Hellman 753 modulus is 2048 bits long. 755 The key exchange payload is modelled on that from Section 3.4 of 756 [RFC5996], and is shown in Figure 6. 758 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 |D| Payload Length | algorithm | Group Num | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | | 764 ~ D-H Public value ~ 765 | | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Figure 6 - Key Exchange Message 770 The flag D denotes the direction of the message, '0' indicates a 771 message from initiator (Alice) to recipient. '1' indicates the 772 reverse direction. 774 The Payload Length field contains the number of octets following the 775 payload length field (including the group number). This is 15 bits 776 wide. 778 The algorithm field is a one octet field that specifies both the KDF 779 to use and the symmetric algorithm to be used for data packet 780 encryption. A registry for values of this field is defined in 781 Section 8.3. The value 0 is used to indicate the default KDF and 782 symmetric encryption mode. 784 The Diffie-Hellman Group Num is from [RFC3526], so the group number 785 for 2048 MODP is decimal 14. Note that this is a one octet field, 786 but is two octets in the [RFC5996] equivalent. This is not an issue 787 because there are only 30 MODP groups defined at present and new 788 groups are not added frequently. 790 The D-H public value will contain g^i or g^r depending on the 791 direction (i.e., the setting of the D flag) and is in big endian 792 order. 794 The length of the Diffie-Hellman public value for MODP groups MUST be 795 equal to the length of the prime modulus over which the 796 exponentiation was performed, prepending zero bits to the value if 797 necessary. 799 Once both sides have derived g^ir they need to feed that and the 800 other inputs described in Section 2.4 into the KDF indicated by the 801 algorithm field. With the default algorithm (value zero), the KDF to 802 be used is HKDF as specified in [RFC5869]. 804 The parameters for the use of HKDF are: 806 Hash: SHA-256 808 Salt: Not used. [[Editor Note: maybe we should?]] 810 Skip: Do not skip. 812 Info: The catenation of a fixed string indicating use of MPLS OE, 813 with the value "MPLS-OE", the first 32 bits of the key 814 exchange message, with the D flag set to 0, plus the LSP 815 ID and the sender and receiver LSR IDs in that order. That 816 is: 818 MPLS-OE||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID 820 L: The output length in bits is 272. 822 The fixed string "MPLS-OE" is used as an input here to prevent 823 potential cross-protocol attacks. Those might otherwise be 824 possible if this mechanism were to be copied in other protocols. 825 (If copying this mechanism for any reason, then a different 826 fixed string value should be used.) 828 LSP-ID is a unique identifier shared between the initiator and 829 receiver (Alice and Bob) that uniquely identifies the LSP. 831 [[Editor note: This identifier is only needed if the scope of the 832 key is per LSP, but that seems a better scope given the need to 833 rotate the key after a certain number of packets have been 834 transmitted. 836 Currently the LSP-ID is known along the LSP and at the two end points 837 if RSVP-TE is used for signaling, or potentially if the LSP is 838 manually configured. It is not so clear in LSPs established using 839 LDP. Probably, however, we can use the FEC as defined for RFC 4379 840 and its extensions.]] 842 i-LSR-ID and r-LSR-ID are the LSR-IDs of the initiator and receiver 843 respectively, where an LSR-ID is the 32 bit, globally unique 844 identifier of the LSR as described in [RFC5036] and [RFC4990]. 846 The default encryption algorithm, AEAD_AES_GCM_128, specified in 847 Section 3, requires a 128 bit session key. 849 The 272-bit HKDF output is the catenation of the session key, the 850 key-id, the witness value and the high-order 16 bits of the initial 851 nonce value in that order. That is the session key is the leftmost 852 128 bits of the HKDF output. The key-id is the next 4 bits, the 853 witness value is the next 124 bits and the last 16 bits are the 16 854 most significant bits of the initial nonce value. The low order 64 855 bits of the initial nonce value are set to zero before the first 856 call to the AES-GCM encryption function. The key-id is carried in 857 encrypted packets as described in Section 3.2. 859 [[Editor note - It is assumed that a 4 bit key-id is adequate in a 860 system where, for any one LSP there is one active key and one new or 861 replaced key. There might also be more than one algorithm, and it is 862 possible that new keys need to be pipelined if roll-over is 863 frequent.]] 865 [[Editor note - we might want to consider deriving the witness value 866 from a separate invocation of the KDF that does not depend on the 867 LSP-specific inputs. The benefit from that would be that the same 868 MITM-detection infrastructure could be used for many protocols. 869 However, that would require standardizing a generic D-H MITM- 870 detection protocol, or at least formats, in order to be useful. We 871 also need to consider what additional information needs to be logged 872 with the witness value so that comparisons can easily be made at 873 scale but without creating new privacy-invasive meta-data. (That last 874 is not much of an issue for MPLS-OE, but could be elsewhere.) At 875 present we do not intend to go for the generic MITM-detection 876 approach, but it is worth considering.]] 878 4.3. Protecting the Key Exchange Protocol Messages 880 As described in Section 2.4, once one key exchange has been 881 successfully completed, further key exchanges should be protected 882 using a previous key. This is simply achieved since key exchange 883 messages are, themselves, carried in MPLS packets on the LSP and may 884 be subject to encryption exactly as any other packet. 886 5. Applicability of MPLS Opportunistic Encryption 888 MPLS OE provides another tool in the security and privacy toolkit. 889 It is not a panacea and does not solve (nor is it intended to solve) 890 all security or privacy problems. In particular, the use of MPLS OE 891 does not protect user-data end-to-end that might be better secured 892 using encryption at the IP layer or at higher layers. 894 As noted throughout this document, the intention of OE in MPLS is to 895 allow one LSR to enable encryption between itself and its neighbor, 896 or between itself and the other end of an LSP, in a dynamic and un- 897 planned way. This can have benefits in a number of scenarios where 898 the network that generates MPLS traffic transmits it over another 899 network (for example, carrier's carrier, or some deployments of 900 enterprise network). Additionally, the use of MPLS OE might allow a 901 service provider to offer a secure edge-to-edge service for a variety 902 of applications ranging from VPNs through pseudowires and where the 903 payload traffic might not always be IP. Lastly, in some non- 904 traditional carriers the user data belongs to the operator or is the 905 direct responsibility of the operator (for example, in data centers, 906 or in large-scale private networks). 908 As with all security mechanisms, there is a trade-off between a 909 number of factors. On one side is the completeness of the security 910 of the user-data, and on the other side is the complexity of 911 configuring and managing the necessary security associations. 912 Furthermore, while mechanisms closer to the end-user than MPLS OE 913 (for example, TLS and IPsec in tunnel mode) provide better security 914 for user-data by virtue of not transmitting the data across any 915 network hops without it being encrypted, such mechanisms often 916 expose more metadata for inspection by snoopers within the network. 918 Additionally, while a variety of per-link encryption mechanisms exist 919 and could be used to guard against attacks such as fiber taps, those 920 approaches do not protect against subverted nodes (i.e., routers) on 921 the path since, by definition, per-link encryption does not protect 922 packets once they come off the link. MPLS OE in the end-to-end LSP 923 mode protects packets on the links and as they cross transit routers. 925 Nevertheless, it is not the purpose of this document to recommend the 926 use of MPLS OE to the exclusion of all other encryption techniques. 927 As already mentioned, MPLS OE is offered as another tool in the tool 928 kit and users as well as network operators are strongly advised to 929 consider using a variety of tools to achieve the level of security 930 and privacy that they desire. 932 Note that, in order that OE can be used, one end of a peering 933 (neighbor or LSP end) must decide to attempt OE and the other end 934 must support it. This can be determined by the message exchanges 935 described in Section 4.2 since if one peer does not send a key 936 exchange message then encryption will not be used, and if the other 937 peer does not respond then it is unwilling or unable to decrypt 938 messages. 940 MPLS OE should be applicable to all forms of MPLS. That is, it should 941 be possible to use it in RSVP-TE systems, in LDP systems, and in 942 MPLS-TP systems (by which we mean those that have manually configured 943 LSPs). Equally, it should work for point-to-point (P2P) and 944 multipoint-to-point (MP2P) uses of MPLS because there is a simple 945 relationship between the sender (encrypter) and the receiver 946 (decrypter) in both cases. In the MP2P case, the sender's identity 947 can be extracted from the key identifier and there are considered to 948 be enough key identifiers to allow an arbitrary number of senders on 949 the LSP. There will, however, be the need for the receiver to hold OE 950 state (keys, packet counters) for each sender which may be a 951 significant amount of data for an MP2P LSP (although no more than if 952 the same LSP were replaced by multiple P2P LSPs). Additionally, it 953 should be noted that not only will each sender on an MP2P LSP have a 954 different key, but each may separately decide whether to encrypt data 955 or not. 957 At this time it is not certain whether MPLS OE can be applied to a 958 point-to-multipoint (P2MP) or a multipoint-to-multipoint LSP in its 959 entirety because packet replication cannot handle the necessary key 960 conversions for each receiver. However, MPLS OE can certainly be 961 applied to individual hops on these LSPs. Further work is needed to 962 determine whether non-branching multi-hop segments of P2MP and MP2P 963 LSPs can also be protected using MPLS OE. 965 6. Security Considerations 967 6.1. Security Improvements 969 See section 2.1. 971 6.2. Continued Vulnerabilities 973 The mechanisms described in this document do not provide protection 974 against certain types of MITM attacks. For example, the key exchange 975 protocol in Section 4.2 will not detect if key exchange messages or 976 their responses are intercepted and discarded such that the 977 initiating peer believes that encryption is not supported. 978 Similarly, those messages may be tampered with such that a receiver 979 cannot determine the correct table index to algorithm and key mapping 980 when an encrypted packet is received. Furthermore, the OEL in an 981 MPLS packet is not protected and may be overwritten such that a 982 receiver is unable to decrypt the packet. 984 See Section 7.1 for a discussion of how active MITM attacks can be 985 detected. 987 6.3. New Security Considerations 989 If a pair of LSRs do not do the key exchange before sending any data 990 packets on the LSP then those first packets will not be protected by 991 OE and hence will be available to a monitor. 993 If a MITM can prevent the OE key exchange from completing, e.g. 994 via deleting messages or changing bits in messages, and if the LSRs 995 continue to send data regardless then those data packets will be 996 available to a monitor. See Section 2.4 and Section 7 for a 997 description of how alarms should be raised in these circumstances. 999 7. Manageability Considerations 1001 As described in Section 2.4 node-wide and per-LSP behavior SHOULD be 1002 configurable to describe the action where key agreement exchange or 1003 packet decryption fails. In any case, such events MUST trigger 1004 alarms to the operator. 1006 7.1. MITM Detection 1008 Section 2.4 introduces the concept of a function of the shared 1009 secret that can be compared by two LSRs that are using OE to see 1010 whether they are victims of an active MITM attack. 1012 Section 4.2 describes how a witness value is derived for the 1013 default KDF, HKDF. 1015 The participating LSRs can simply log this value plus the LSP 1016 and LSR IDs from time to time and a management application can 1017 compare the values. If they are different for the same LSP ID, 1018 then an active MITM attack has taken place. 1020 It needs to be carefully noted that the management channel used to 1021 log or otherwise compare the witness values from the two LSRs MUST be 1022 secure. It is likely that routers use relatively high security 1023 management channels for configuration and other management 1024 operations. 1026 [[Editor note - please see the note in 4.2 about generic MITM- 1027 detection. Changes there could affect what needs to be done here.]] 1029 8. IANA Considerations 1031 8.1. Opportunistic Encryption Label Indicator 1033 IANA maintains a registry called "Multiprotocol Label Switching 1034 Architecture (MPLS) Label Values" with a single sub-registry called 1035 "Label Values". This registry is to be renamed "Special Purpose MPLS 1036 Label Values according to [ID.ietf-mpls-special-purpose-labels]. 1038 IANA is requested to assign a value from this registry as follows: 1040 Value | Description | Reference 1041 ------+-------------------------------------------------+----------- 1042 TBD1 | Opportunistic Encryption Label (OEL) | [This.ID] 1044 The value 8 is suggested. 1046 [RFC Editor is requested to replace the string "TBD1" with the value 1047 assigned by IANA throughout this document, and to remove this note.] 1049 8.2. Pseudowire Associated Channel Types 1051 IANA maintains a registry called "Pseudowire Name Spaces (PWE3)" with 1052 a sub-registry called "Pseudowire Associated Channel Types". IANA is 1053 requested to assign a value as follows: 1055 Value | Description | Reference 1056 ------+-------------------------------------------------+----------- 1057 TBD2 | Opportunistic Key Exchange Protocol for MPLS | [This.ID] 1059 The value 19 is suggested. 1061 [RFC Editor is requested to replace the string "TBD2" with the values 1062 assigned by IANA throughout this document, and to remove this note.] 1064 8.3. Key Derivation Functions and Symmetric Algorithms 1066 IANA is requested to create a new MPLS registry called the "MPLS 1067 Opportunistic Encryption Algorithms Registry". New values are to 1068 be assigned through "IETF Review" as defined in [RFC5226]. 1070 The available range is 0 - 255. 1072 IANA is requested to record the following information and create an 1073 initial entry as follows: 1075 Value | Key Derivation Function | Symmetric Algorithm | Reference 1076 ------+-------------------------+---------------------+----------- 1077 0 | HKDF | AEAD_AES_GCM_128 | [This.I-D] 1078 1-255 | Unassigned | | 1080 9. Acknowledgements 1082 Many thanks to Alia Atlas for detailed discussion of the implications 1083 and mechanisms of MPLS opportunistic encryption. Thanks also to Ron 1084 Bonica for encouraging this work, to Sean Turner and Stewart Bryant 1085 for early review, and to Jeff Haas and Ross Callon for discussions. 1086 Thanks to Andy Malis and Danny McPherson for advice about the use of 1087 the Control Word. 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 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 1142 Addresses in Generalized Multiprotocol Label Switching 1143 (GMPLS) Networks", RFC 4990, September 2007. 1145 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1146 Specification", RFC 5036, October 2007. 1148 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1149 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1150 RFC 5996, September 2010. 1152 Authors' Addresses 1154 Adrian Farrel 1155 Juniper Networks 1157 EMail: adrian@olddog.co.uk 1159 Stephen Farrell 1160 Trinity College Dublin 1161 Dublin, 2 1162 Ireland 1164 Phone: +353-1-896-2354 1165 Email: stephen.farrell@cs.tcd.ie