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