draft-ietf-mpls-opportunistic-encrypt-00.txt   draft-ietf-mpls-opportunistic-encrypt-01.txt 
Network Working Group A. Farrel Network Working Group A. Farrel
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Experimental S. Farrell Intended status: Standards Track S. Farrell
Expires: January 23, 2016 Trinity College, Dublin Expires: September 16, 2016 Trinity College Dublin
July 23, 2015 March 15, 2016
Opportunistic Security in MPLS Networks Opportunistic Security in MPLS Networks
draft-ietf-mpls-opportunistic-encrypt-00.txt draft-ietf-mpls-opportunistic-encrypt-01
Abstract Abstract
This document describes a way to apply opportunistic security This document describes a way to apply opportunistic security between
between adjacent nodes on an MPLS Label Switched Path (LSP) or adjacent nodes on an MPLS Label Switched Path (LSP) or between end
between end points of an LSP. It explains how keys may be agreed points of an LSP. It explains how keys may be agreed to enable
to enable encryption, and how key identifiers are exchanged in encryption, and how key identifiers are exchanged in encrypted MPLS
encrypted MPLS packets. Finally, this document describes the packets. Finally, this document describes the applicability of this
applicability of this approach to opportunistic security in MPLS approach to opportunistic security in MPLS networks with an
networks with an indication of the level of improved security as indication of the level of improved security as well as the continued
well as the continued vulnerabilities. vulnerabilities.
This document does not describe security for MPLS control plane This document does not describe security for MPLS control plane
protocols. protocols.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction ................................................... 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Experimental Status .......................................... 4 1.1. Experimental Status . . . . . . . . . . . . . . . . . . . 4
1.2. Existing Security Tools for MPLS Data ........................ 5 1.2. Existing Security Tools for MPLS Data . . . . . . . . . . 5
2. Principles of Opportunistic Security ........................... 5 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Why Do We Need Opportunistic Security? ....................... 5 2. Principles of Opportunistic Security . . . . . . . . . . . . 6
2.2. Opportunistic Security at 10,000ft ........................... 7 2.1. Why Do We Need Opportunistic Security? . . . . . . . . . 6
2.3. What about a Man-in-the-Middle? .............................. 8 2.2. Opportunistic Security at 10,000ft . . . . . . . . . . . 7
2.4. OS in MPLS Overview .......................................... 9 2.3. What about a Man-in-the-Middle? . . . . . . . . . . . . . 9
3. MPLS Packet Encryption ........................................ 11 2.4. OS in MPLS Overview . . . . . . . . . . . . . . . . . . . 10
3.1. MPLS Encryption Label ....................................... 14 3. MPLS Packet Encryption . . . . . . . . . . . . . . . . . . . 12
3.2. Control Word ................................................ 14 3.1. MPLS Encryption Label . . . . . . . . . . . . . . . . . . 15
3.3. Considerations for ECMP ..................................... 15 3.2. Control Word . . . . . . . . . . . . . . . . . . . . . . 16
3.4. Backward Compatibility ...................................... 16 3.3. Considerations for ECMP . . . . . . . . . . . . . . . . . 16
3.5. MTU Considerations .......................................... 17 3.4. Backward Compatibility . . . . . . . . . . . . . . . . . 17
3.6. Recursive Encryption ........................................ 17 3.5. MTU Considerations . . . . . . . . . . . . . . . . . . . 18
4. Key Exchange For Opportunistic Security in MPLS ............... 17 3.6. Recursive Encryption . . . . . . . . . . . . . . . . . . 18
4.1. Initiating MPLS-OS .......................................... 18 4. Key Exchange For Opportunistic Security in MPLS . . . . . . . 19
4.2. MPLS G-ACh Advertisement Protocol for Key Exchange .......... 19 4.1. Initiating MPLS-OS . . . . . . . . . . . . . . . . . . . 19
4.3. Key Exchange Protocol ....................................... 19 4.2. MPLS G-ACh Advertisement Protocol for Key Exchange . . . 20
4.4. Indicating the Return Path .................................. 24 4.3. Key Exchange Protocol . . . . . . . . . . . . . . . . . . 20
4.5. Protecting the Key Exchange Protocol Messages ............... 25 4.3.1. Communication Channels . . . . . . . . . . . . . . . 21
5. Applicability of MPLS Opportunistic Security ................. 25 4.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 21
5.1. Tunnel MPLS Packets ......................................... 27 4.3.3. Key Exchange TLV . . . . . . . . . . . . . . . . . . 22
5.2. Penultimate Hop Popping ..................................... 28 4.3.4. Encoding Errors . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations ....................................... 29 4.4. Indicating the Return Path . . . . . . . . . . . . . . . 26
6.1. Security Improvements ....................................... 29 4.5. Protecting the Key Exchange Protocol Messages . . . . . . 27
6.2. Applicability ............................................... 29 5. Applicability of MPLS Opportunistic Security . . . . . . . . 27
6.3. Continued Vulnerabilities ................................... 29 5.1. Tunnel MPLS Packets . . . . . . . . . . . . . . . . . . . 29
6.4. New Security Considerations ................................. 29 5.2. Penultimate Hop Popping . . . . . . . . . . . . . . . . . 29
7. Manageability Considerations .................................. 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7.1. MITM Detection .............................................. 30 6.1. Security Improvements . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations .......................................... 30 6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 31
8.1. GAP Key Exchange TLV ........................................ 30 6.3. Continued Vulnerabilities . . . . . . . . . . . . . . . . 31
8.2. Key Derivation Functions and Symmetric Algorithms ........... 31 6.4. New Security Considerations . . . . . . . . . . . . . . . 31
9. Acknowledgements ............................................. 31 7. Manageability Considerations . . . . . . . . . . . . . . . . 32
10. References .................................................. 31 7.1. MITM Detection . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References ...................................... 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References .................................... 32 8.1. GAP Key Exchange TLV . . . . . . . . . . . . . . . . . . 32
Authors' Addresses ............................................... 34 8.2. Key Derivation Functions and Symmetric Algorithms . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
MPLS is an established data plane protocol in the Internet. It is MPLS is an established data plane protocol in the Internet. It is
found in the majority of core service provider networks and most end- found in the majority of core service provider networks and most end-
to-end traffic in the Internet will be carried over MPLS at some to-end traffic in the Internet will be carried over MPLS at some
point in its path. The MPLS data plane is defined by [RFC3031] and point in its path. The MPLS data plane is defined by [RFC3031] and
[RFC3032]. [RFC3032].
Data security (e.g., confidentiality) in MPLS has previously relied Data security (e.g., confidentiality) in MPLS has previously relied
on just two features: on just two features:
- Physical isolation of MPLS networks has been used to ensure that o Physical isolation of MPLS networks has been used to ensure that
interception of MPLS traffic was not possible. interception of MPLS traffic was not possible.
- Higher-layer protocol security (such as IPsec [RFC4302], [RFC4303]) o Higher-layer protocol security (such as IPsec [RFC4302],
has been used whenever a particular flow has determined that [RFC4303]) has been used whenever a particular flow has determined
security was desirable. that security was desirable.
These features have a number of significant vulnerabilities: These features have a number of significant vulnerabilities:
- Networks are increasingly easily compromised physically such that o Networks are increasingly easily compromised physically such that
"taps" may be inserted in links between routers [RFC7258]. "taps" may be inserted in links between routers [RFC7258].
- Routers may be compromised either in their entirety or through o Routers may be compromised either in their entirety or through the
the management/control plane (or misconfiguration). This may management/control plane (or misconfiguration). This may result
result in packets being diverted to transit inspection points on in packets being diverted to transit inspection points on their
their way to their destination. way to their destination.
- The increased support for point-to-multipoint (P2MP) MPLS means o The increased support for point-to-multipoint (P2MP) MPLS means
that routers can easily be configured (or misconfigured) to make a that routers can easily be configured (or misconfigured) to make a
copy of data and to send it to an additional destination. copy of data and to send it to an additional destination.
- End-to-end payload security may be hard to manage and operate and o End-to-end payload security may be hard to manage and operate and
is not turned on by default by many users. While this form of is not turned on by default by many users. While this form of
security is desirable, the network should also improve the security security is desirable, the network should also improve the
of data transfer that it offers. security of data transfer that it offers.
The concept of Opportunistic Security (OS) is introduced in The concept of Opportunistic Security (OS) is introduced in
[RFC7435]. This document describes an OS design pattern for the MPLS [RFC7435]. This document describes an OS design pattern for the MPLS
data plane. It shows what part of an MPLS packet may be encrypted data plane. It shows what part of an MPLS packet may be encrypted
and provides a way to indicate that the packet is encrypted as well and provides a way to indicate that the packet is encrypted as well
as to carry a key identifier with each packet. as a way to carry a key identifier with each packet.
MPLS opportunistic security can be achieved between adjacent Label MPLS opportunistic security can be achieved between adjacent Label
Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and
also between end points of an LSP. also between end points of an LSP.
This document also provides a mechanism for keys to be exchanged to This document also provides a mechanism for keys to be exchanged to
facilitate encryption. Finally, this document describes the facilitate encryption. Finally, this document describes the improved
applicability of OS in MPLS networks with an indication of the level security level achieved with OS in MPLS networks and lists the
of improved security as well as the continued vulnerabilities. continued vulnerabilities.
This document does not describe security for MPLS control plane This document does not describe security for MPLS control plane
protocols. protocols.
Please note that a discussion of the applicability of MPLS Please note that a discussion of the applicability of MPLS
opportunistic security is provided in Section 5. opportunistic security is provided in Section 5.
1.1. Experimental Status 1.1. Experimental Status
This document is presented as experimental. Before advancing this This document is presented as experimental. Before advancing this
work on the IETF's Standards Track, it is important to get experience work on the IETF's Standards Track, it is important to get experience
of the practicality of the mechanisms described. In particular of the practicality of the mechanisms described. In particular
whether it is practical to achieve these mechanisms in existing whether it is practical to achieve these mechanisms in existing
hardware, and whether the imposition of additional MPLS labels is hardware, and whether the imposition of additional MPLS labels is
acceptable in the MPLS data plane. Additionally, the consequences acceptable in the MPLS data plane. Additionally, the consequences of
of the reduced MTU caused by inserting the additional MPLS label and the reduced MTU caused by inserting the additional MPLS label and
control word as well as the fact that the encrypted packet will be control word as well as the fact that the encrypted packet will be
larger than the unencrypted packet need to be investigated. larger than the unencrypted packet need to be investigated.
It is currently believed that MPLS OS can be deployed progressively It is currently believed that MPLS OS can be deployed progressively
without the need to negotiate capabilities outside the key exchange without the need to negotiate capabilities outside the key exchange
mechanisms described here. This means that no specific walled garden mechanisms described here. This means that no specific walled garden
needs to be described in this document. needs to be described in this document.
Experimentation and further investigation of the security aspects of Experimentation and further investigation of the security aspects of
these mechanisms are encouraged especially with regard to mitigation these mechanisms are encouraged especially with regard to mitigation
of man-in-the-middle attacks. Consideration of the impact of MPLS OS of man-in-the-middle attacks. Consideration of the impact of MPLS OS
on MPLS Operations, Administration, and Management (OAM) and other on MPLS Operations, Administration, and Management (OAM) and other
MPLS management techniques also needs further exploration. MPLS management techniques also needs further exploration.
The key functions of MPLS OS described in Section 2.4 are based on The key functions of MPLS OS described in Section 2.4 are based on an
an initial set of choices that may be adequate for MPLS OS. However, initial set of choices that may be adequate for MPLS OS. However,
security knowledge is evolving and it may be advisable to "upgrade" security knowledge is evolving and it may be advisable to "upgrade"
for example to Elliptic Curve Diffie-Hellman (ECDH) [RFC6239], using for example to Elliptic Curve Diffie-Hellman (ECDH) [RFC6239], using
NIST curves or new curves (such as 25519). Furthermore, alternative NIST curves or new curves (such as 25519). Furthermore, alternative
key derivation functions could be chosen, or symmetric cipher mode key derivation functions could be chosen, or symmetric cipher mode
could be used. Note that changing to a symmetric cipher that is could be used. Note that changing to a symmetric cipher that is
faster in software, but less likely to be available in hardware would faster in software, but less likely to be available in hardware would
not be a good change. not be a good change.
Section 2.4 also describes the frequency with which keys should be Section 2.4 also describes the frequency with which keys should be
changed. The values described here should be subject to more changed. The values described here should be subject to more
skipping to change at page 5, line 14 skipping to change at page 5, line 21
Section 4.3.3 defines the input parameters to the key derivation Section 4.3.3 defines the input parameters to the key derivation
function and includes the LSP identifier. This identifier is only function and includes the LSP identifier. This identifier is only
needed if the scope of the key is per LSP. This document is written needed if the scope of the key is per LSP. This document is written
on that assumption because of the need to rotate the key after a on that assumption because of the need to rotate the key after a
certain number of packets have been transmitted. However, this could certain number of packets have been transmitted. However, this could
be the subject of some investigation since dropping the LSP be the subject of some investigation since dropping the LSP
identifier would simplify the TLV and the computation. It would also identifier would simplify the TLV and the computation. It would also
address the issue of identifying the LSP in the case of LDP. address the issue of identifying the LSP in the case of LDP.
Section 4.3.3 also specifies that the alt is not used. Further Section 4.3.3 also specifies that the salt is not used. Further
investigation is needed to see whether this input parameter would add investigation is needed to see whether this input parameter would add
value. value.
Note that this experiment uses a special-purpose MPLS label. Since Note that this experiment uses a special-purpose MPLS label. Since
this document is experimental it makes use of an extended special- this document is experimental it makes use of an extended special-
purpose label from the experimental range. If this work is moved to purpose label from the experimental range. If this work is moved to
be published on the standards track, it will be possible to achieve be published on the standards track, it will be possible to achieve
the same function using a simple special-purpose label rather than an the same function using a simple special-purpose label rather than an
extended special-purpose label. extended special-purpose label.
1.2. Existing Security Tools for MPLS Data 1.2. Existing Security Tools for MPLS Data
This section is a placeholder for text that needs to be added to This section is a placeholder for text that needs to be added to
describe existing security tools for securing MPLS Data. The text describe existing security tools for securing MPLS Data. The text
needs to describe the use of IPsec used for the payload of MPLS LSPs, needs to describe the use of IPsec used for the payload of MPLS LSPs,
and should also cover the use of link layer security (such as and should also cover the use of link layer security (such as
MACsec). MACsec).
>>> TBD Consideration should also be given to the use of MACsec for
pseudowires. Where an Ethernet service is delivered over a packet
tunnel (such as an IP or an MPLS tunnel) then the end points may
consider themselves to be just one Ethernet hop apart and could apply
MACsec.
2. Principles of Opportunistic Security TBD
1.3. Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Principles of Opportunistic Security
This section provides an overview of opportunistic security in the This section provides an overview of opportunistic security in the
context of MPLS. Readers are advised to familiarize themselves with context of MPLS. Readers are advised to familiarize themselves with
some of the attack vectors discussed in [RFC7258] and with the more some of the attack vectors discussed in [RFC7258] and with the more
general description of opportunistic security as described in general description of opportunistic security as described in
[RFC7435]. The text here is intended for the consumption of MPLS [RFC7435]. The text here is intended for the consumption of MPLS
experts who may not have a background in security: it is, therefore, experts who may not have a background in security: it is, therefore,
tutorial and simplistic in nature. tutorial and simplistic in nature.
2.1. Why Do We Need Opportunistic Security? 2.1. Why Do We Need Opportunistic Security?
To introduce this discussion we start from a basic view of how To introduce this discussion we start from a basic view of how
encryption is typically used in IETF protocols. encryption is typically used in IETF protocols.
Say we have two protocol entities, Alice and Bob, and they would like Say we have two protocol entities, Alice and Bob, and they would like
some message "M" sent from Alice to Bob to have confidentiality. some message "M" sent from Alice to Bob to have confidentiality.
Alice needs to send M encrypted with algorithm "E" under some Alice needs to send M encrypted with algorithm "E" under some
symmetric (e.g., AES) key, "k". Thus Alice wants to send Bob symmetric (e.g., AES) key, "k". Thus Alice wants to send Bob
"E(k,M)", but for Bob to be able to understand (i.e., decrypt) the "E(k,M)", but for Bob to be able to understand (i.e., decrypt) the
message Alice and Bob both need to agree on the key that will be message Alice and Bob both need to agree on the key that will be
skipping to change at page 6, line 27 skipping to change at page 6, line 52
public key and not Charlie's. That knowledge requires some long-term public key and not Charlie's. That knowledge requires some long-term
key management, which is often done using a Public Key Infrastructure key management, which is often done using a Public Key Infrastructure
(PKI) so that Alice actually stores the public key (Pub-ca) of a (PKI) so that Alice actually stores the public key (Pub-ca) of a
Certification Authority (CA), and Bob gets his public key (Pub-b) Certification Authority (CA), and Bob gets his public key (Pub-b)
"certified" by the CA, which means the CA creates a digitally signed "certified" by the CA, which means the CA creates a digitally signed
data structure "Cert(Pub-ca,Pub-b)". The crucial thing is that data structure "Cert(Pub-ca,Pub-b)". The crucial thing is that
Alice, Bob, and a CA need to co-ordinate before Alice and Bob can Alice, Bob, and a CA need to co-ordinate before Alice and Bob can
agree on a key "k", and that process imposes a key-management burden. agree on a key "k", and that process imposes a key-management burden.
Doing such key management is clearly quite possible, since TLS and Doing such key management is clearly quite possible, since TLS and
IPsec and other well-deployed technologies depend on it. But, in IPsec and other well-deployed technologies depend on it. But, in the
the case of HTTP/TLS on the public web, we see that only roughly 30% case of HTTP/TLS on the public web, we see that only roughly 30% of
of web sites actually take on this burden, even though the software web sites actually take on this burden, even though the software
required is ubiquitous and, at least for 2nd level DNS domains in required is ubiquitous and, at least for 2nd level DNS domains in
.com for example, there are CAs who offer free domain-validated .com for example, there are CAs who offer free domain-validated
certificates. While some of the 70% who don't set up certificates certificates. While some of the 70% who don't set up certificates
might not actually want confidentiality, there are certainly some who might not actually want confidentiality, there are certainly some who
would and arguably many that would benefit from confidentiality, if would and arguably many that would benefit from confidentiality, if
it just happened out of the box, without an administrator having to it just happened out of the box, without an administrator having to
do anything. And there are also arguably many other protocols where do anything. And there are also arguably many other protocols where
the same is true. the same is true.
An alternative to the PKI is manual configuration of keys at Alice An alternative to the PKI is manual configuration of keys at Alice
and Bob. Manual configuration is used in a large number of cases in and Bob. Manual configuration is used in a large number of cases in
deployments, however it has a set of issues that make it problematic. deployments, however it has a set of issues that make it problematic.
These issues include: These issues include:
- the scale of configuration that is needed for a full set of
Security Associations (SAs) between all communicating parties o the scale of configuration that is needed for a full set of
- the likelihood of configuration errors Security Associations (SAs) between all communicating parties
- the security vulnerabilities associated with manual keying and
unsecured exchange of keys. o the likelihood of configuration errors
o the security vulnerabilities associated with manual keying and
unsecured exchange of keys.
Opportunistic Security (OS) is a protocol design pattern to achieve Opportunistic Security (OS) is a protocol design pattern to achieve
encryption between Alice and Bob without requiring key-management encryption between Alice and Bob without requiring key-management
through CAs and without relying on manual configuration of keys. through CAs and without relying on manual configuration of keys.
2.2. Opportunistic Security at 10,000ft 2.2. Opportunistic Security at 10,000ft
Instead of the "key transport" mechanisms described in Section 2.1, Instead of the "key transport" mechanisms described in Section 2.1,
OS aims to use "key agreement". With key management, Alice invents OS aims to use "key agreement". With key management, Alice invents
"k" and safely transports it to Bob encrypted with Bob's public key "k" and safely transports it to Bob encrypted with Bob's public key
as "E(Pub-b,k)". With key agreement, both Alice and Bob contribute as "E(Pub-b,k)". With key agreement, both Alice and Bob contribute
to calculating "k" as follows. to calculating "k" as follows.
Assume that Alice and Bob are using some protocol where they can Assume that Alice and Bob are using some protocol where they can
exchange a few messages in order to agree on the key "k" to use. exchange a few messages in order to agree on the key "k" to use.
With a Diffie-Hellman key agreement ("D-H") both Alice and Bob have With a Diffie-Hellman key agreement ("D-H") both Alice and Bob have
skipping to change at page 7, line 31 skipping to change at page 8, line 11
In this way Alice sends Bob "Pub-a" and Bob sends Alice "Pub-b" and In this way Alice sends Bob "Pub-a" and Bob sends Alice "Pub-b" and
at that point both of them can safely calculate a shared secret "k" at that point both of them can safely calculate a shared secret "k"
from those values. And after that Alice can send Bob "E(k,M)". from those values. And after that Alice can send Bob "E(k,M)".
From here on, we change the terminology slightly and refer to Alice From here on, we change the terminology slightly and refer to Alice
as the initiator, with private key "i" and Bob as the recipient, with as the initiator, with private key "i" and Bob as the recipient, with
private key "r" so that our notation is closer to that used in private key "r" so that our notation is closer to that used in
IPsec's Internet Key Exchange Protocol (IKE) on which we model our IPsec's Internet Key Exchange Protocol (IKE) on which we model our
use of OS. use of OS.
D-H works as follows: Let "p" be well-known large prime number that D-H works as follows: Let "p" be well-known large prime number that
we use for all modular arithmetic (meaning that "a^b" is actually we use for all modular arithmetic (meaning that "a^b" is actually
"(a^b) mod p"), and let "g" be another well-known value (called a "(a^b) mod p"), and let "g" be another well-known value (called a
generator for the group determined by "p"). Also let Alice and Bob's generator for the group determined by "p"). Also let Alice and Bob's
private values be "i" and "r" respectively. Now, if Alice sends Bob private values be "i" and "r" respectively. Now, if Alice sends Bob
"g^i" as her public value, and Bob similarly sends Alice "g^r" then "g^i" as her public value, and Bob similarly sends Alice "g^r" then
both of them can easily calculate "g^(i*r)" or "g^ir" but nobody else both of them can easily calculate "g^(i*r)" or "g^ir" but nobody else
can, since calculating "x" when only given "g^x" is a computationally can, since calculating "x" when only given "g^x" is a computationally
hard problem for any "x". Once both Alice and Bob have the value hard problem for any "x". Once both Alice and Bob have the value
"g^ir" in hand, they can easily derive a value "k" from that using "g^ir" in hand, they can easily derive a value "k" from that using
any of a number of well-known key derivation functions (KDFs) such any of a number of well-known key derivation functions (KDFs) such
skipping to change at page 8, line 20 skipping to change at page 9, line 5
attack each key k. In contrast, if we use the key transport attack each key k. In contrast, if we use the key transport
approach, then an attacker who somehow accesses Bob's private key approach, then an attacker who somehow accesses Bob's private key
"Priv-b" can record lots of traffic and later go back and decrypt all "Priv-b" can record lots of traffic and later go back and decrypt all
the "E(Pub-b,k)" values that all Alices have ever sent to Bob. With the "E(Pub-b,k)" values that all Alices have ever sent to Bob. With
key agreement as described, since both Alice and Bob contribute to key agreement as described, since both Alice and Bob contribute to
the value k, and since Alice and Bob will typically periodically the value k, and since Alice and Bob will typically periodically
generate new private values i and r (perhaps even for every single generate new private values i and r (perhaps even for every single
M), compromise of one party is far less catastrophic, and an attacker M), compromise of one party is far less catastrophic, and an attacker
who gets access to one private value gets far less benefit. who gets access to one private value gets far less benefit.
2.3. What about a Man-in-the-Middle? 2.3. What about a Man-in-the-Middle?
OS as described so far is vulnerable to Man-in-the-Middle (MITM) OS as described so far is vulnerable to Man-in-the-Middle (MITM)
attacks. The problem is that Alice does not know that it was attacks. The problem is that Alice does not know that it was really
really Bob's public value that she received; it could have been Bob's public value that she received; it could have been Charlie's
Charlie's public value sent by Charlie. And Charlie could also public value sent by Charlie. And Charlie could also send Bob his
send Bob his public value pretending to be Alice. Now Charlie public value pretending to be Alice. Now Charlie can share a key
can share a key with Alice and a key with Bob so that Charlie with Alice and a key with Bob so that Charlie can sit between Alice
can sit between Alice and Bob decrypting what he gets from Alice and Bob decrypting what he gets from Alice and then re-encrypting it
and then re-encrypting it to send to Bob. Neither Alice nor to send to Bob. Neither Alice nor Bob can tell that Charlie is
Bob can tell that Charlie is present as a "Man-in-the-Middle" present as a "Man-in-the-Middle" and both Alice and Bob think they
and both Alice and Bob think they are safely exchanging encrypted are safely exchanging encrypted messages.
messages.
A MITM attack like that is bad and making a protocol proof against A MITM attack like that is bad and making a protocol proof against
such attacks comes at the cost of the key-management burden described such attacks comes at the cost of the key-management burden described
in Section 2.1. Most IETF protocols to date require that such MITM in Section 2.1. Most IETF protocols to date require that such MITM
attacks not be feasible. attacks not be feasible.
However, despite its potential vulnerability to MITM attacks, OS However, despite its potential vulnerability to MITM attacks, OS
still has value. This value arises because of the difficulty of still has value. This value arises because of the difficulty of
inserting a MITM actor, and the cost of processing for the MITM inserting a MITM actor, and the cost of processing for the MITM in
in the case of a very large number of relationships. In the case of a very large number of relationships. In particular,
particular, where the choice is between no encryption (as has been where the choice is between no encryption (as has been the case for
the case for MPLS to date) and OS, it is clear that using OS offers MPLS to date) and OS, it is clear that using OS offers better
better (although not the best) security. (although not the best) security.
Consider the case where an attacker taps a link on the path between Consider the case where an attacker taps a link on the path between
Alice and Bob. In this case, the attacker can capture every packet Alice and Bob. In this case, the attacker can capture every packet
between the two parties, and if there is no encryption, can read between the two parties, and if there is no encryption, can read
every message. Furthermore, consider that the attacker could tap a every message. Furthermore, consider that the attacker could tap a
fiber in the core of the network and so capture every packet between fiber in the core of the network and so capture every packet between
a large number of Alices and their corresponding Bobs. In these a large number of Alices and their corresponding Bobs. In these
cases, Charlie can operate as a "passive MITM" since all he has to do cases, Charlie can operate as a "passive MITM" since all he has to do
is watch the packets. is watch the packets.
With OS in use, Charlie is forced to be an "active MITM". That is he With OS in use, Charlie is forced to be an "active MITM". That is he
must engage in the D-H exchange between each pair of Alices and Bobs, must engage in the D-H exchange between each pair of Alices and Bobs,
and he must must decrypt and encrypt each packet he wants to inspect. and he must must decrypt and encrypt each packet he wants to inspect.
This imposes a higher cost and is especially burdensome if he is This imposes a higher cost and is especially burdensome if he is
attempting to do it in parallel for lots of Alice/Bob pairs using attempting to do it in parallel for lots of Alice/Bob pairs using
lots of different keys and communication sessions. lots of different keys and communication sessions.
Furthermore, when D-H is in use for OS, management tools can be used Furthermore, when D-H is in use for OS, management tools can be used
to detect the presence of Charlie as a MITM. This is because to detect the presence of Charlie as a MITM. This is because Charlie
Charlie has to agree one key "kA" with Alice, and a different key has to agree one key "kA" with Alice, and a different key "kB" with
"kB" with Bob. As far as we know, Charlie cannot arrange that kA Bob. As far as we know, Charlie cannot arrange that kA equals kB
equals kB because both sides contribute to the key value in the D-H because both sides contribute to the key value in the D-H key
key agreement. That means that if Alice and Bob can check with each agreement. That means that if Alice and Bob can check with each
other what value of "k" they are using and the values do not match, other what value of "k" they are using and the values do not match,
then they know that Charlie is present. What is more, Alice and Bob then they know that Charlie is present. What is more, Alice and Bob
can make this check on the value of "k" for any of the "E(k,M)" they can make this check on the value of "k" for any of the "E(k,M)" they
ever exchanged. ever exchanged.
Thus, in the case of a fiber tap where many Alice/Bob pairs are Thus, in the case of a fiber tap where many Alice/Bob pairs are being
being monitored, it only takes one Alice and Bob to detect the MITM monitored, it only takes one Alice and Bob to detect the MITM attack
attack for all Alice/Bob pairs to be alerted to the problem. In for all Alice/Bob pairs to be alerted to the problem. In such cases
such cases the cost of detection for Charlie may be even greater than the cost of detection for Charlie may be even greater than the cost
the cost of performing the MITM attack. of performing the MITM attack.
Hence we conclude that OS can have considerable value when used in Hence we conclude that OS can have considerable value when used in
MPLS networks. MPLS networks.
2.4. OS in MPLS Overview 2.4. OS in MPLS Overview
The basic requirement for MPLS-OS is that we want to provide a way The basic requirement for MPLS-OS is that we want to provide a way
for two MPLS nodes to do a key exchange and to derive a session key for two MPLS nodes to do a key exchange and to derive a session key
from that to use in MPLS packet encryption. from that to use in MPLS packet encryption.
To do that we use a Diffie-Hellman key exchange as outlined in To do that we use a Diffie-Hellman key exchange as outlined in
Section 2.2. We model this on IKE [RFC7296] using essentially the Section 2.2. We model this on IKE [RFC7296] using essentially the
same parameters. We feed the shared Diffie-Hellman value, which is same parameters. We feed the shared Diffie-Hellman value, which is
g^ir, into a standard KDF that also takes as input an LSP identifier g^ir, into a standard KDF that also takes as input an LSP identifier
(LSP ID) together with the sending and receiving LSR IDs - where the (LSP ID) together with the sending and receiving LSR IDs - where the
skipping to change at page 10, line 11 skipping to change at page 10, line 42
keys on an LSP even if the same g^i and g^r values are re-used, keys on an LSP even if the same g^i and g^r values are re-used,
however it is RECOMMENDED that fresh values of i and r are used each however it is RECOMMENDED that fresh values of i and r are used each
time [RFC4086]. The KDF to be used here is as defined in [RFC5869]. time [RFC4086]. The KDF to be used here is as defined in [RFC5869].
The D-H values used MUST be of at least 2048-bits. Implementations The D-H values used MUST be of at least 2048-bits. Implementations
MUST support the 2048-bit modular exponentiation (MODP) group from MUST support the 2048-bit modular exponentiation (MODP) group from
Section 3 of [RFC3526] and SHOULD support the larger MODP groups from Section 3 of [RFC3526] and SHOULD support the larger MODP groups from
[RFC3526]. [RFC3526].
This document also defines the mechanism used to derive an identifier This document also defines the mechanism used to derive an identifier
for a key (the key-id) from the shared Diffie-Hellman value, which for a key (the key-id) from the shared Diffie-Hellman value, which is
is also based on the KDF output. The key will be used with a also based on the KDF output. The key will be used with a symmetric
symmetric encryption algorithm, such as AEAD_AES_GCM_128 (the encryption algorithm, such as AEAD_AES_GCM_128 (the default,
default, following [RFC5116]). following [RFC5116]).
As with any symmetric block cipher, one should not use the same key As with any symmetric block cipher, one should not use the same key
for too long. The nonce defined for these keys is derived using for too long. The nonce defined for these keys is derived using a 96
a 96 bit counter incremented by one for each encrypted packet. bit counter incremented by one for each encrypted packet. It is
It is critical for security that nonce values MUST NOT be re-used critical for security that nonce values MUST NOT be re-used with a
with a given key. (This is an inherent issue with how AES-GCM or any given key. (This is an inherent issue with how AES-GCM or any
counter mode achieves high performance.) counter mode achieves high performance.)
Accordingly, implementations MUST support mechanisms for key change. Accordingly, implementations MUST support mechanisms for key change.
To support key change, this document defines a way for two LSRs using To support key change, this document defines a way for two LSRs using
a key on an LSP to agree a new key and to switch over to using that a key on an LSP to agree a new key and to switch over to using that
key when desired. That means that implementations MUST be able to key when desired. That means that implementations MUST be able to
handle at least two keys (old and new) for a given LSP. Once a new handle at least two keys (old and new) for a given LSP. Once a new
key has been agreed then it should be used for sending packets; once key has been agreed then it should be used for sending packets; once
encrypted data packets protected with the new key have been encrypted data packets protected with the new key have been
successfully received, the old key SHOULD be discarded. Section 4 successfully received, the old key SHOULD be discarded. Section 4
describes how two LSRs agree keys: to agree a new key two LSRs simply describes how two LSRs agree keys: to agree a new key two LSRs simply
run the same key agreement exchange, but this time protected with the run the same key agreement exchange, but this time protected with the
old session key as described in Section 4.5. This process can, of old session key as described in Section 4.5. This process can, of
course, be repeated any number of times for the same LSP. It is course, be repeated any number of times for the same LSP. It is
RECOMMENDED that the key on an LSP be changed at least once every RECOMMENDED that the key on an LSP be changed at least once every day
day or every 10^6 packets whichever is sooner, and MUST change keys or every 10^6 packets whichever is sooner, and MUST change keys
before encrypting 2^64 packets. For an LSP running over a fully- before encrypting 2^64 packets.
busy 100Gbe interface, we might assume that means roughly 160
million packets per second, or roughly 2^44 packets per day. The
2^64 limit therefore means changing keys daily in the busiest cases
of some of the largest current links capacities.
In the event of a key agreement exchange or decryption failure, an In the event of a key agreement exchange or decryption failure, an
alarm MUST be raised to the operator. Default (i.e., node-wide) and alarm MUST be raised to the operator. Default (i.e., node-wide) and
per-LSP behavior SHOULD be configurable in this case: actions may per-LSP behavior SHOULD be configurable in this case: actions may
include reverting to non-encrypted traffic, re-attempting key include reverting to non-encrypted traffic, re-attempting key
exchange, or tearing down the LSP. Note that a simple attack on OS exchange, or tearing down the LSP. Note that a simple attack on OS
is to tamper with key agreement exchange messages or encrypted is to tamper with key agreement exchange messages or encrypted
packets so that OS fails. Such attacks may be intended to cause the packets so that OS fails. Such attacks may be intended to cause the
LSP to operate without encryption, so an operator should consider LSP to operate without encryption, so an operator should consider
this when setting the behavior in this case. this when setting the behavior in this case.
Section 7.1 also discusses a mechanism that allows a pair of LSRs Section 7.1 also discusses a mechanism that allows a pair of LSRs
using OS on an LSP to detect that a MITM attack has happened. For using OS on an LSP to detect that a MITM attack has happened. For
this, we simply define a function of the shared secret, which can be this, we simply define a function of the shared secret, which can be
logged and later compared. Note that logging a sample of these logged and later compared. Note that logging a sample of these
"witness" values will likely be sufficient to detect pervasive MITM "witness" values will likely be sufficient to detect pervasive MITM
attacks [RFC7258]. As with the key-id, we base this on the same attacks [RFC7258]. As with the key-id, we base this on the same KDF
KDF output. output.
We might want to consider deriving the witness value from a separate We might want to consider deriving the witness value from a separate
invocation of the KDF that does not depend on the LSP-specific invocation of the KDF that does not depend on the LSP-specific
inputs. The benefit from that would be that the same MITM-detection inputs. The benefit from that would be that the same MITM-detection
infrastructure could be used for many protocols. However, that would infrastructure could be used for many protocols. However, that would
require standardizing a generic D-H MITM-detection protocol, or at require standardizing a generic D-H MITM-detection protocol, or at
least formats, in order to be useful. We also need to consider what least formats, in order to be useful. We also need to consider what
additional information needs to be logged with the witness value so additional information needs to be logged with the witness value so
that comparisons can easily be made at scale but without creating new that comparisons can easily be made at scale but without creating new
privacy-invasive meta-data. That last is not much of an issue for privacy-invasive meta-data. That last is not much of an issue for
MPLS-OS, but could be elsewhere. At present we do not intend to go MPLS-OS, but could be elsewhere. At present we do not intend to go
for the generic MITM-detection approach, but it is worth considering. for the generic MITM-detection approach, but it is worth considering.
An additional discussion of the applicability of MPLS-OS is found in An additional discussion of the applicability of MPLS-OS is found in
Section 5. Section 5.
3. MPLS Packet Encryption 3. MPLS Packet Encryption
MPLS packets are encrypted according to the mechanisms described in MPLS packets are encrypted according to the mechanisms described in
this section. this section.
When an MPLS packet is encrypted, this is indicated by the insertion When an MPLS packet is encrypted, this is indicated by the insertion
of a new extended special-purpose label [RFC7274] in the label stack. of a new extended special-purpose label [RFC7274] in the label stack.
This is referred to as the MPLS Encryption Label (MEL). The format This is referred to as the MPLS Encryption Label (MEL). The format
of the MEL is described in Section 3.1. of the MEL is described in Section 3.1.
The MEL MUST have the bottom of stack bit (the S bit) set and MUST be The MEL MUST have the bottom of stack bit (the S bit) set and MUST be
followed by a pseudowire control word [RFC4385]. The format of the followed by a pseudowire control word [RFC4385]. The format of the
control word is described in Section 3.2. control word is described in Section 3.2.
The remainder of the MPLS packet is encrypted and cannot be parsed The remainder of the MPLS packet is encrypted and cannot be parsed
without decryption. It needs to be understood, therefore, that the without decryption. It needs to be understood, therefore, that the
phrase "bottom of stack" refers to the parsable label stack (i.e., phrase "bottom of stack" refers to the parsable label stack (i.e.,
those label stack entries that have not been encrypted) and does not those label stack entries that have not been encrypted) and does not
indicate the full label stack of the unencrypted packet. Figures 1 indicate the full label stack of the unencrypted packet. Figures 1
and 2 should make this point clear. and 2 should make this point clear.
Implementations MUST support the AEAD_AES_GCM_128 encryption Implementations MUST support the AEAD_AES_GCM_128 encryption
algorithm, as specified in Section 5.1 of [RFC5116], which is the algorithm, as specified in Section 5.1 of [RFC5116], which is the
default algorithm as described in Section 4.3 of this document. default algorithm as described in Section 4.3 of this document.
Note that it is critical that a new nonce is used for every Note that it is critical that a new nonce is used for every
encryption. The nonce is an implicit packet counter. The initial encryption. The nonce is an implicit packet counter. The initial
nonce value is derived from the HMAC-based Key Derivation Function nonce value is derived from the HMAC-based Key Derivation Function
(HKDF) output (see Section 4.3.2) at key agreement time and the (HKDF) output (see Section 4.3.2) at key agreement time and the
counter is incremented by one for each packet encrypted on the counter is incremented by one for each packet encrypted on the
sending side and by one for each packet successfully decrypted on the sending side and by one for each packet successfully decrypted on the
receiver side. receiver side.
Although the nonce is not transmitted with the packets, a 16-bit Although the nonce is not transmitted with the packets, a 16-bit
counter carried in the control Word indicates the nonce value modulo counter carried in the control Word indicates the nonce value modulo
65536. This feature allows a receiving node to quickly spot that a 65536. This feature allows a receiving node to quickly spot that a
packet has been dropped and resynch its own counter in order to be packet has been dropped and resynchcronize its own counter in order
able to continue to decrypt received packets. In the event that the to be able to continue to decrypt received packets. In the event
counter cannot be resynchronized or that more than 65536 packet are that the counter cannot be resynchronized or that more than 65536
lost in one batch the receiver will encounter a decryption error. In packet are lost in one batch the receiver will encounter a decryption
this case the receiver may report a general decryption error or may error. In this case the receiver may report a general decryption
attempt to resynchronize by advancing its own counter in units of error or may attempt to resynchronize by advancing its own counter in
65536 according to the modulo value in the received packet. Note units of 65536 according to the modulo value in the received packet.
that incrementing the counter in order to test for decryption failure Note that incrementing the counter in order to test for decryption
does generate a potential DoS if, e.g., an attacker decrements the failure does generate a potential DoS if, e.g., an attacker
nonce-mod-65536 value. Implementations that do such tests SHOULD decrements the nonce-mod-65536 value. Implementations that do such
maintain a small maximum window size beyond which they will cease tests SHOULD maintain a small maximum window size beyond which they
attempting to decrypt. It could be that throwing an error might be will cease attempting to decrypt. It could be that throwing an error
the more effective response if the packet loss rates are expected to might be the more effective response if the packet loss rates are
be low enough. expected to be low enough.
It should also be noted that the output from encryption will be 16 It should also be noted that the output from encryption will be 16
octets longer than the input. octets longer than the input.
The bottom of stack bit is set in the MEL to stop implementations The bottom of stack bit is set in the MEL to stop implementations
continuing to search down the label stack (which is encrypted) and continuing to search down the label stack (which is encrypted) and
attempting to use the data as though it was a valid label stack. The attempting to use the data as though it was a valid label stack. The
control word is needed because many implementations that find the control word is needed because many implementations that find the
bottom of stack expect the next bytes to be a control word or bottom of stack expect the next bytes to be a control word or
protocol indicator. protocol indicator.
The position of the MEL and control word depend on whether hop-by-hop The position of the MEL and control word depend on whether hop-by-hop
or end-to-end encryption is being applied. or end-to-end encryption is being applied.
Figure 1 illustrates the format of an example MPLS packet before and Figure 1 illustrates the format of an example MPLS packet before and
after hop-by-hop encryption. The left hand part of the after hop-by-hop encryption. The left hand part of the figure shows
figure shows a normal MPLS packet with a label stack and payload. a normal MPLS packet with a label stack and payload. The bottom
The bottom label in the stack has the S bit set. The payload is the label in the stack has the S bit set. The payload is the data
data carried by the MPLS packet (such as IP) and may be prefixed by a carried by the MPLS packet (such as IP) and may be prefixed by a
control word. control word.
The right hand part of Figure 1 shows the same packet after it has The right hand part of Figure 1 shows the same packet after it has
been encrypted. The top of stack is a label with value 15 that been encrypted. The top of stack is a label with value 15 that
indicates that an extended special-purpose label follows. Next comes indicates that an extended special-purpose label follows. Next comes
the MEL with the S bit set. The label value of the MEL is from the the MEL with the S bit set. The label value of the MEL is from the
experimental range 240-255 and is selected according to the scope of experimental range 240-255 and is selected according to the scope of
the MPLS OS experiment being run. The MEL is followed by a control the MPLS OS experiment being run. The MEL is followed by a control
word. Everything that follows the control word is the entire word. Everything that follows the control word is the entire
original MPLS packet encrypted. original MPLS packet encrypted.
----------- . ----------- ----------- . -----------
| Top Label | . | Label 15 | | Top Label | . | Label 15 |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label | . | MEL S=1 | | Label | . | MEL S=1 |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label S=1 | .| Ctrl Word | | Label S=1 | .| Ctrl Word |
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
~ Payload ~ ~ Encrypted ~ ~ Payload ~ ~ Encrypted ~
| | | | | | | |
-----------........----------- -----------........-----------
Figure 1 : The Use of the MEL for Hop-by-Hop Encryption Figure 1: The Use of the MEL for Hop-by-Hop Encryption
Figure 2 illustrates the format of an example MPLS packet before and Figure 2 illustrates the format of an example MPLS packet before and
after end-to-end encryption. The left hand part of the figure shows after end-to-end encryption. The left hand part of the figure shows
a normal MPLS packet with a label stack and payload. The bottom a normal MPLS packet with a label stack and payload. The bottom
label in the stack has the S bit set and the payload may be prefixed label in the stack has the S bit set and the payload may be prefixed
by a control word. The right hand part of the figure shows how the by a control word. The right hand part of the figure shows how the
top two labels (or however many labels are needed for end-to-end top two labels (or however many labels are needed for end-to-end
delivery) remain at the top of the label stack. Then follows label delivery) remain at the top of the label stack. Then follows label
15 to indicate that an extended special-purpose label follows, then 15 to indicate that an extended special-purpose label follows, then
----------- -----------
| Top Label | | Top Label |
+-----------+ +-----------+
| Label | | Label |
+-----------+. +-----------+
| Label | . | Label 15 |
+-----------+ . +-----------+
| Label | . | MEL S=1 |
+-----------+ . +-----------+
| Label S=1 | .| Ctrl Word |
+-----------+ +-----------+
| | | |
~ Payload ~ ~ Encrypted ~
| | | |
-----------........-----------
Figure 2 : The Use of the MEL for End-to-End Encryption
comes the MEL with S bit set, and a control word. The remainder of comes the MEL with S bit set, and a control word. The remainder of
the packet is encrypted and contains the rest of the label stack and the packet is encrypted and contains the rest of the label stack and
the payload. the payload.
3.1. MPLS Encryption Label ----------- -----------
| Top Label | | Top Label |
+-----------+ +-----------+
| Label | | Label |
+-----------+. +-----------+
| Label | . | Label 15 |
+-----------+ . +-----------+
| Label | . | MEL S=1 |
+-----------+ . +-----------+
| Label S=1 | .| Ctrl Word |
+-----------+ +-----------+
| | | |
~ Payload ~ ~ Encrypted ~
| | | |
-----------........-----------
Figure 2: The Use of the MEL for End-to-End Encryption
3.1. MPLS Encryption Label
The MPLS Encryption Label (MEL) is a normal label stack entry The MPLS Encryption Label (MEL) is a normal label stack entry
carrying an extended special-purpose label with a value from the carrying an extended special-purpose label with a value from the
experimental range 240-255. The format of the label stack entry is experimental range 240-255. The format of the label stack entry is
defined in [RFC3032] and shown in Figure 3. defined in [RFC3032] and shown in Figure 3.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 : Format of the MEL Label Stack Entry Figure 3: Format of the MEL Label Stack Entry
Label: The value of MEL for this experiment Label: The value of MEL for this experiment. Note that no special
TC: For end-to-end encryption, the value of the TC field SHOULD purpose label value is assigned by IANA and implementations
be set to the value of the unencrypted label stack entry that participating in this experiment must agree amongst themselves
immediately precedes the MEL. In the case of hop-by-hop what value to use. The value MUST be selected from the
encryption, the value of the TC SHOULD be copied from the TC Experimental range (240-255).
of the first encrypted label if there is a label stack
present. Otherwise this field SHOULD be set to all zero
(0b000).
S: MUST be set to one.
TTL: SHOULD be set to two to prevent encrypted packets being
accidentally forwarded too far beyond the point of intended
decryption. Note that setting to zero might cause a
receiver to discard the packet when the MEL becomes top of
stack, and setting to one might cause the packet to be sent
to the slow path when the MEL becomes the top of the stack
even though decryption should be a fast-path function.
The sending LSR MAY choose different values for the TTL and TC fields TC: For end-to-end encryption, the value of the TC field SHOULD be
if it is known that label 15 or the MEL will not be exposed as the set to the value of the unencrypted label stack entry that
top label at any point along the LSP (for example, by penultimate hop immediately precedes the MEL. In the case of hop-by-hop
popping - but see Section 5 for a discussion of MPLS tunnels and encryption, the value of the TC SHOULD be copied from the TC of
penultimate hop popping). the first encrypted label if there is a label stack present.
Otherwise this field SHOULD be set to all zero (0b000).
3.2. Control Word S: MUST be set to one.
TTL: SHOULD be set to two to prevent encrypted packets being
accidentally forwarded too far beyond the point of intended
decryption. Note that setting to zero might cause a receiver to
discard the packet when the MEL becomes top of stack, and setting
to one might cause the packet to be sent to the slow path when the
MEL becomes the top of the stack even though decryption should be
a fast-path function.
The sending LSR MAY choose different values for the TTL and TC
fields if it is known that label 15 or the MEL will not be exposed
as the top label at any point along the LSP (for example, by
penultimate hop popping - but see Section 5 for a discussion of
MPLS tunnels and penultimate hop popping).
3.2. Control Word
The control word is inserted after the MEL as described in Section 3. The control word is inserted after the MEL as described in Section 3.
The S bit set to one in the MEL and the presence of the control word The S bit set to one in the MEL and the presence of the control word
helps protect against transit nodes that may perform hashing or helps protect against transit nodes that may perform hashing or
inspection of the label stack and payload packet headers when inspection of the label stack and payload packet headers when
forwarding MPLS packets (for example, to enable ECMP). The control forwarding MPLS packets (for example, to enable ECMP). The control
word indicates that the payload is not a protocol that can be word indicates that the payload is not a protocol that can be
meaningfully hashed or inspected. meaningfully hashed or inspected.
The format of the control word is defined in [RFC4385] and shown in The format of the control word is defined in [RFC4385] and shown in
Figure 4. Figure 4.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |FRG| Length | Sequence Number | |0 0 0 0| Flags |FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Control Word for Encrypted MPLS Figure 4: Control Word for Encrypted MPLS
Flags: The Flags field is treated as a four-bit number. It Flags: The Flags field is treated as a four-bit number. It contains
contains the key-id that identifies the algorithm the key-id that identifies the algorithm and key as established
and key as established through configuration or through configuration or dynamic key exchange as described in
dynamic key exchange as described in Section 4. Section 4.
FRG: Must be sent as 0, and ignored on receipt.
Fragmentation is not used.
Length: MUST be sent as 0, and ignored on receipt.
Sequence Number: This field contains the packet counter (nonce) for
the encryption algorithm and key currently in use
modulo 65536. It can be used by a receiver to
quickly check that the value of the nonce being used
for decryption is likely to be correct as described
in Section 3.
3.3. Considerations for ECMP FRG: Must be sent as 0, and ignored on receipt. Fragmentation is
not used.
Length: MUST be sent as 0, and ignored on receipt.
Sequence Number: This field contains the packet counter (nonce) for
the encryption algorithm and key currently in use modulo 65536.
It can be used by a receiver to quickly check that the value of
the nonce being used for decryption is likely to be correct as
described in Section 3.
3.3. Considerations for ECMP
As previously stated, the S bit set in the MEL and the presence of As previously stated, the S bit set in the MEL and the presence of
the control word prevent implementations from attempting to use the the control word prevent implementations from attempting to use the
encrypted MPLS packet and its payload to determine a hash value for encrypted MPLS packet and its payload to determine a hash value for
uses such as ECMP. However, the resultant label stack shown in uses such as ECMP. However, the resultant label stack shown in
Figure 2 will probably not provide sufficient entropy for ECMP Figure 2 will probably not provide sufficient entropy for ECMP
purposes. purposes.
In order to increase the entropy, an implementation that inserts an In order to increase the entropy, an implementation that inserts an
MEL and MEL MAY also insert an Entropy Label Indicator (ELI) and MEL and control word MAY also insert an Entropy Label Indicator (ELI)
Entropy Label (EL) as defined in [RFC6790] ELI and EL are positioned and Entropy Label (EL) as defined in [RFC6790] ELI and EL are
in the label stack before the MEL as shown in Figure 5. The setting positioned in the label stack before the MEL as shown in Figure 5.
of the fields in the ELI and EL label stack entries are as described The setting of the fields in the ELI and EL label stack entries are
in [RFC6790]. as described in [RFC6790].
The ELI and EL will normally occur immediately before the label 15 The ELI and EL will normally occur immediately before the label 15
and MEL pair, but they MAY be placed higher up the label stack. and MEL pair, but they MAY be placed higher up the label stack.
----------- -----------
| Top Label | | Top Label |
+-----------+ +-----------+
| Label | | Label |
----------- +-----------+ ----------- +-----------+
| Top Label | | ELI | | Top Label | | ELI |
+-----------+ +-----------+ +-----------+ +-----------+
| Label | | EL | | Label | | EL |
+-----------+. +-----------+ +-----------+. +-----------+
| Label | . | Label 15 | | Label | . | Label 15 |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label | . | MEL S=1 | | Label | . | MEL S=1 |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label S=1 | .| Ctrl Word | | Label S=1 | .| Ctrl Word |
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
~ Payload ~ ~ Encrypted ~ ~ Payload ~ ~ Encrypted ~
| | | | | | | |
-----------........----------- -----------........-----------
Figure 5 : The Use of ELI and EL with MEL Figure 5: The Use of ELI and EL with MEL
3.4. Backward Compatibility 3.4. Backward Compatibility
Keys and encryption algorithms may be configured manually or Keys and encryption algorithms may be configured manually or
exchanged dynamically as described in Section 4. These mechanisms exchanged dynamically as described in Section 4. These mechanisms
provide a preliminary way to protect against a sender encrypting data provide a preliminary way to protect against a sender encrypting data
that the receiver cannot decrypt, however, misconfiguration may lead that the receiver cannot decrypt, however, misconfiguration may lead
to a sender using the MEL when the receiver does not support to a sender using the MEL when the receiver does not support
encryption. encryption.
When a node finds an unknown label at the top of the label stack it When a node finds an unknown label at the top of the label stack it
must discard the packet as described in [RFC3031]. Therefore, when a must discard the packet as described in [RFC3031]. Therefore, when a
skipping to change at page 17, line 9 skipping to change at page 18, line 21
hop encryption is used, or may be the end of the LSP if end-to-end hop encryption is used, or may be the end of the LSP if end-to-end
encryption is used. encryption is used.
Transit nodes that are not actively participating in the encryption Transit nodes that are not actively participating in the encryption
will not inspect the MEL except potentially as part of an ECMP hash, will not inspect the MEL except potentially as part of an ECMP hash,
and it should be noted that the use of Special Purpose Labels in and it should be noted that the use of Special Purpose Labels in
hashing is strongly discouraged (see Section 2.4.5.1 of [RFC7325]). hashing is strongly discouraged (see Section 2.4.5.1 of [RFC7325]).
This means that transit nodes will not encounter the MEL during This means that transit nodes will not encounter the MEL during
normal packet processing and will not discard packets. normal packet processing and will not discard packets.
3.5. MTU Considerations 3.5. MTU Considerations
Adding label 15, the MEL, and the Control Word as described above Adding label 15, the MEL, and the Control Word as described above
will reduce the available data size by 12 octets. Furthermore, as will reduce the available data size by 12 octets. Furthermore, as
described in Section 3, the output of the encryption algorithm is described in Section 3, the output of the encryption algorithm is at
at least 16 octets longer than the input. Therefore, the use of least 16 octets longer than the input. Therefore, the use of
encryption reduces the available MTU by at least 28 octets. Other encryption reduces the available MTU by at least 28 octets. Other
encryption algorithms may result in even greater reductions in the encryption algorithms may result in even greater reductions in the
available MTU. available MTU.
When end-to-end encryption is in use this can be considered by the When end-to-end encryption is in use this can be considered by the
ingress LSR, however, when single-hop encryption is in use the ingress LSR, however, when single-hop encryption might be used the
participating LSRs need to advertise this reduction in link MTU participating LSRs need to advertise this reduced link MTU so that
so that the packets do not overflow. MPLS packets MUST NOT be the packets do not overflow. MPLS packets MUST NOT be fragmented as
fragmented as a result of encryption. a result of encryption.
3.6. Recursive Encryption 3.6. Recursive Encryption
The use of MEL and control word described in Section 3 may be applied The use of MEL and control word described in Section 3 may be applied
recursively. That is, the payload of an encrypted MPLS packet may, recursively. That is, the payload of an encrypted MPLS packet may,
itself be an encrypted MPLS packet. This may be particularly useful itself be an encrypted MPLS packet. This may be particularly useful
in the case where an MPLS VPN has native MPLS traffic. in the case where an MPLS VPN has native MPLS traffic.
There are no special considerations except to note that encryption There are no special considerations except to note that encryption
and decryption processing may be burdensome if an LSP and its payload and decryption processing may be burdensome if an LSP and its payload
LSP have encryption applied at the same LSR. Additionally, it LSP have encryption applied at the same LSR. Additionally, it should
should be noted that, as described in Section 3.6, each recursive be noted that, as described in Section 3.5, each recursive encryption
encryption reduces the MTU by 28 octets. reduces the MTU by at least 28 octets.
4. Key Exchange For Opportunistic Security in MPLS 4. Key Exchange For Opportunistic Security in MPLS
For encryption to be useful both ends of an encrypted session must For encryption to be useful both ends of an encrypted session must
know which algorithm is in use and which key to use. The mechanism know which algorithm is in use and which key to use. The mechanism
described in Section 3 provides a way to indicate an index into a described in Section 3 provides a way to indicate an index into a
table of algorithms and keys that can be used to decrypt an encrypted table of algorithms and keys that can be used to decrypt an encrypted
MPLS packet. MPLS packet.
It is possible that this table has been manually configured or set up It is possible that this table has been manually configured or set up
using a key exchange protocol such as Internet Key Exchange version 2 using a key exchange protocol such as Internet Key Exchange version 2
(IKEv2) [RFC7296]. However, such a process implies a stable security (IKEv2) [RFC7296]. However, such a process implies a stable security
association between encrypter and decrypter of MPLS packets. While association between encrypter and decrypter of MPLS packets. While
such a stable association is entirely consistent with the concept of such a stable association is entirely consistent with the concept of
OS, OS nonetheless calls for a more dynamic key agreement method. OS, OS nonetheless calls for a more dynamic key agreement method.
This section provides a mechanism for adjacent MPLS LSRs, or for a This section provides a mechanism for adjacent MPLS LSRs, or for a
pair of LSRs at opposite ends of an MPLS LSP, to dynamically pair of LSRs at opposite ends of an MPLS LSP, to dynamically exchange
exchange keys and algorithm identifiers so that encryption may be keys and algorithm identifiers so that encryption may be applied
applied opportunistically. opportunistically.
The mechanism uses message exchanges in the MPLS Generic Associated The mechanism uses message exchanges in the MPLS Generic Associated
Channel (G-ACh) [RFC5586] as part of the MPLS Generic Associated Channel (G-ACh) [RFC5586] as part of the MPLS Generic Associated
Channel (G-ACh) Advertisement Protocol (GAP) [RFC7212]. This channel Channel (G-ACh) Advertisement Protocol (GAP) [RFC7212]. This channel
is in-band with an LSP and may be used to carry messages between is in-band with an LSP and may be used to carry messages between
neighbors or between the end points of the LSP. A type field within neighbors or between the end points of the LSP. A type field within
the common message header, the Associated Channel Header (ACH), is the common message header, the Associated Channel Header (ACH), is
used to indicate the type of message carried. used to indicate the type of message carried.
Nodes that receive G-ACh messages and do not understand them, or Nodes that receive G-ACh messages and do not understand them, or
nodes that understand the G-ACh but do not recognize the ACH message nodes that understand the G-ACh but do not recognize the ACH message
type drop the packets as described in [RFC5586]. type drop the packets as described in [RFC5586].
Note that this mechanism may benefit from encryption that is already Note that this mechanism may benefit from encryption that is already
in use on an LSP. Thus key changes using this mechanism can be made in use on an LSP. Thus key changes using this mechanism can be made
using encrypted messages. using encrypted messages.
4.1. Initiating MPLS-OS 4.1. Initiating MPLS-OS
This document assumes that the use of MPLS-OS is initiated by the This document assumes that the use of MPLS-OS is initiated by the
upstream of a pair of LSRs (either a pair of adjacent LSRs on an LSP, upstream of a pair of LSRs (either a pair of adjacent LSRs on an LSP,
or a pair of LSP end points). That is, the upstream LSR send the or a pair of LSP end points). That is, the upstream LSR sends the
first G-ACh that initiates key exchange. The key that is generated first G-ACh message that initiates key exchange. The key that is
after the exchange is then used to encrypt traffic travelling in the generated after the exchange is used to encrypt traffic travelling in
direction between initiating and responding LSRs: that is, from the direction between initiating and responding LSRs: that is, from
upstream to downstream LSR. upstream to downstream LSR.
In the case of a bidirectional LSP, each direction is treated In the case of a bidirectional LSP, each direction is treated
separately. That is, "upstream" refers to the direction of traffic separately. That is, "upstream" refers to the direction of traffic
flow, and not to any signaling that is used to establish the LSP. flow, and not to any signaling that is used to establish the LSP.
Thus, it is possible that a bidirectional LSP uses MPLS-OS on none, Thus, it is possible that a bidirectional LSP uses MPLS-OS on none,
either one, or both of the directions of traffic flow for the LSP. either one, or both of the directions of traffic flow for the LSP.
But it is important to note that the keys used are different in each But it is important to note that the keys used are different in each
direction, each being generated and exchanged through a separate direction, each being generated and exchanged through a separate
instance of the procedures described in this document. Note that the instance of the procedures described in this document. Note that the
skipping to change at page 19, line 13 skipping to change at page 20, line 28
direction. direction.
Note also that in the case of a pair of unidirectional LSPs in Note also that in the case of a pair of unidirectional LSPs in
reverse directions between a pair of LSRs there should be no reverse directions between a pair of LSRs there should be no
relationship between the keys used on each LSP even if there is a relationship between the keys used on each LSP even if there is a
tight coupling between the LSPs such as might be the case for tight coupling between the LSPs such as might be the case for
associated bidirectional LSPs [RFC7551]. The key derivation function associated bidirectional LSPs [RFC7551]. The key derivation function
will use different LSP identifiers as well as using the LSR will use different LSP identifiers as well as using the LSR
identifiers in a different order. identifiers in a different order.
4.2. MPLS G-ACh Advertisement Protocol for Key Exchange 4.2. MPLS G-ACh Advertisement Protocol for Key Exchange
GAP defines messages exchanged in G-ACh on a common Associated GAP defines messages exchanged in G-ACh on a common Associated
Channel Type code point (0x0059) [RFC7212]. The application for Channel Type code point (0x0059) [RFC7212]. The application for
which the messages are exchanged is defined by the Application ID which the messages are exchanged is defined by the Application ID
field carried in the Applications Data Block (ADB). MPLS OS field carried in the Applications Data Block (ADB). MPLS OS
capability notification and key exchange uses the GAP Application ID capability notification and key exchange uses the GAP Application ID
(0x0000) defined by [RFC7212] and a new ADB TLV for MPLS OS. (0x0000) defined by [RFC7212] and a new ADB TLV for MPLS OS.
Implementations that do not support GAP will discard received packets Implementations that do not support GAP will discard received packets
with this Associated Channel Type as described in [RFC5586]. with this Associated Channel Type as described in [RFC5586].
Implementations that support GAP but that do not support key exchange Implementations that support GAP but that do not support key exchange
will discard received packets with this ADB TLV as described in will discard received packets with this ADB TLV as described in
[RFC7212]. Either of these discards will result in no dynamic key [RFC7212]. Either of these discards will result in no dynamic key
exchange, but other key definitions are still supported (such as exchange, but other key definitions are still supported (such as
manual configuration) and may be used to construct a table of manual configuration) and may be used to construct a table of
algorithms and keys that can be used to achieve MPLS encryption using algorithms and keys that can be used to achieve MPLS encryption using
the mechanisms described in Section 3. the mechanisms described in Section 3.
4.3. Key Exchange Protocol 4.3. Key Exchange Protocol
4.3.1. Communication Channels
4.3.1. Communication Channels
The key exchange protocol described in this document uses a D-H The key exchange protocol described in this document uses a D-H
exchange that assumes a bidirectional communication channel. GAP is exchange that assumes a bidirectional communication channel. GAP is
designed to run over a unidirectional channel and uses normal IP designed to run over a unidirectional channel and uses normal IP
forwarding for return path messages with an optimization to use the forwarding for return path messages with an optimization to use the
return path of a bidirectional LSP. However, LSPs in packet networks return path of a bidirectional LSP. However, LSPs in packet networks
are usually unidirectional. That means that, while the key exchange are usually unidirectional. That means that, while the key exchange
messages can be sent on the LSP in one direction, a channel needs to messages can be sent on the LSP in one direction, a channel needs to
be established for the return messages. be established for the return messages.
This document uses a process similar to that defined for MPLS LSP This document uses a process similar to that defined for MPLS LSP
Ping [RFC4379] and [RFC7110], and that described to indicate a return Ping [RFC4379] and [RFC7110], and similar to that used to indicate a
path for MPLS performance measurement in return path for MPLS performance measurement in
[I-D.ietf-mpls-pm-udp-return]. That is, the forward message is sent [I-D.ietf-mpls-rfc6374-udp-return-path]. That is, the forward
on the LSP and includes the identity of the return path communication message is sent on the LSP and includes the identity of the return
channel. The return path may be indicated as a UDP communication path communication channel. The return path may be indicated as a
over IP, as an LSP running in the opposite direction, or as the UDP communication over IP, as an LSP running in the opposite
reverse direction of a bidirectional LSP. direction, or as the reverse direction of a bidirectional LSP.
Note that the GAP messages defined in [RFC7212] include a TLV that Note that the GAP messages defined in [RFC7212] include a TLV that
enables authentication. This feature SHOULD be used if possible, but enables authentication. This feature SHOULD be used if possible, but
it is in the nature of opportunistic security that the necessary it is in the nature of opportunistic security that the necessary
security association might not exist. In this case the ability to security association might not exist. In this case the ability to
tamper with the instructions that select a return path may provide a tamper with the instructions that select a return path may provide a
mechanism that makes MITM attacks easier. An implementation that mechanism that makes MITM attacks easier. An implementation that
initiates key exchange for MPLS Opportunistic Security MUST verify initiates key exchange for MPLS Opportunistic Security MUST verify
that the response messages are received on the expected return path that the response messages are received on the expected return path
channel and SHOULD raise an operator alert if the channel is channel and SHOULD raise an operator alert if the channel is
unexpected. unexpected.
4.3.2. Key Exchange Messages 4.3.2. Key Exchange Messages
The format of a GAP message is described in [RFC7212]. When used for The format of a GAP message is described in [RFC7212]. When used for
key exchange the GAP message includes an ADB with the fields set as key exchange the GAP message includes an ADB with the fields set as
follows. follows.
Application ID is set to 0x0000. Application ID is set to 0x0000.
Element Length is set to the total length in octets of this ADB Element Length is set to the total length in octets of this ADB
including the Application ID and this field. including the Application ID and this field.
Lifetime field SHOULD be set to zero and MUST be ignored. Lifetime field SHOULD be set to zero and MUST be ignored.
A key exchange ADB MUST include a Key Exchange TLV as shown in A key exchange ADB MUST include a Key Exchange TLV as shown in
Section 4.3.3. The ADB and MAY also include an Authentication TLV as Section 4.3.3. The ADB MAY also include an Authentication TLV as
described in [RFC7212] to provide authentication and integrity described in [RFC7212] to provide authentication and integrity
validation for a GAP message (see Section 4.5). Additionally, the validation for a GAP message (see Section 4.5). Additionally, the
ADB MAY include a Source TLV as described in [RFC7212] and discussed ADB MAY include a Source TLV as described in [RFC7212] and discussed
in Section 4.4. in Section 4.4.
4.3.3. Key Exchange TLV 4.3.3. Key Exchange TLV
A session key is to be established between an initiator (Alice) and A session key is to be established between an initiator (Alice) and a
a recipient (Bob). The D-H public value for Alice is g^i and for recipient (Bob). The D-H public value for Alice is g^i and for Bob,
Bob, g^r. The shared Diffie-Hellman value is g^ir. g^ir is g^r. The shared Diffie-Hellman value is g^ir. g^ir is represented
represented as a string of octets in big endian order padded with as a string of octets in big endian order padded with zeros if
zeros if necessary to make it the length of the modulus. Both g^i necessary to make it the length of the modulus. Both g^i and g^r
and g^r will be 2048 bits long, if the Diffie-Hellman modulus is 2048 will be 2048 bits long, if the Diffie-Hellman modulus is 2048 bits
bits long. long.
The Key Exchange TLV is modelled on that from Section 3.4 of The Key Exchange TLV is modelled on that from Section 3.4 of
[RFC7296] with the addition of information to identify the LSP and [RFC7296] with the addition of information to identify the LSP and
its return path, and is encoded as shown in Figure 6. its return path, and is encoded as shown in Figure 6.
1 2 3 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|Rsvd | Return| Path Identifier | |D|Rsvd | Return| Path Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-ID | | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Group Num | | | Algorithm | Group Num | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
~ D-H Public Value ~ ~ D-H Public Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Key Exchange Message TLV Figure 6: Key Exchange Message TLV
Type is set to TBD1 to indicate that this is a Key Exchange TLV Type is set to TBD1 to indicate that this is a Key Exchange TLV.
The Reserved and Length fields are defined in [RFC7212]. The Reserved and Length fields are defined in [RFC7212].
The flag D denotes the direction of the message, '0' indicates a The flag D denotes the direction of the message, '0' indicates a
message from initiator (Alice) to recipient. '1' indicates the message from initiator (Alice) to recipient. '1' indicates the
reverse direction. reverse direction.
The Rsvd bits are reserved. They SHOULD be set to zero and ignored The Rsvd bits are reserved. They SHOULD be set to zero and ignored
on receipt. on receipt.
The Return field is used on a message from the initiator to indicate The Return field is used on a message from the initiator to indicate
the type of return path to be used for messages from the responder. the type of return path to be used for messages from the responder.
The Path Identifier field is interpreted in this context. Possible The Path Identifier field is interpreted in this context. Possible
values are as follows: values are as follows:
0 The reverse path of a bidirectional LSP is to be used for the 0 The reverse path of a bidirectional LSP is to be used for the
response. Used on a message from an initiator. response.
1 The reverse path messages are to be sent encapsulated in UDP.
Used on a message from an initiator.
2 Any LSP between the recipient and the initiator may be used.
3 Any LSP between the recipient and the initiator that is already
using MPLS-OS may be used.
4 The reverse path messages are to be sent on a specific LSP.
All other values are undefined and MUST be processed as an 1 The reverse path messages are to be sent encapsulated in UDP.
encoding error as described in Section 4.3.4. Similarly, if the
value zero is used on a unidirectional LSP then it MUST be handled 2 Any LSP between the recipient and the initiator may be used.
as an encoding error.
3 Any LSP between the recipient and the initiator that is already
using MPLS-OS may be used.
4 The reverse path messages are to be sent on a specific LSP.
All other values are undefined and MUST be processed as an encoding
error as described in Section 4.3.4. Similarly, if a value indicates
an unavailable return path (such as a request for the reverse path of
a bidirectional LSP when the LSP is actually unidirectional) then it
MUST be handled as an encoding error.
The Path Identifier is interpreted in the context of the Return The Path Identifier is interpreted in the context of the Return
field. The field only has meaning on messages from the initiator and field. The field only has meaning on messages from the initiator and
SHOULD be ignored on responses. If the Return is set to the SHOULD be ignored on responses. If the Return field is set to the
following values, the Path Identifier has the following meaning: following values, the Path Identifier has the following meaning:
0 In this case the Path Identifier field has no meaning and SHOULD 0 In this case the Path Identifier field has no meaning and SHOULD
be ignored. be ignored.
1 The Path Identifier field contains a UDP port number from the
dynamic port range that the initiator will listen on for a 1 The Path Identifier field contains a UDP port number from the
response. dynamic port range that the initiator will listen on for a
2 In this case the Path Identifier field has no meaning and SHOULD response.
be ignored.
3 In this case the Path Identifier field has no meaning and SHOULD 2 In this case the Path Identifier field has no meaning and SHOULD
be ignored. be ignored.
4 The Path Identifier field contains an LSP-ID that must be used
for reverse path messages. 3 In this case the Path Identifier field has no meaning and SHOULD
be ignored.
4 The Path Identifier field contains an LSP-ID that must be used for
reverse path messages.
See Section 4.4 for more discussion of return paths. See Section 4.4 for more discussion of return paths.
The LSP-ID parameter indicates the LSP to which this key exchange The LSP-ID parameter indicates the LSP to which this key exchange
applies. On messages from initiator to recipient this field MUST be applies. On messages from initiator to recipient this field MUST be
set to the LSP on which the message flows and any mismatch MUST be set to the LSP on which the message flows and any mismatch MUST be
treated as an encoding error (Section 4.3.4). On messages from treated as an encoding error (Section 4.3.4). On messages from
recipient to initiator, this value MUST be copied from the received recipient to initiator, this value MUST be copied from the received
message and an initiator that cannot match the message and LSP-ID to message and an initiator that cannot match the message and LSP-ID to
a message that it previously sent MUST treat the situation as an a message that it previously sent MUST treat the situation as an
encoding error. encoding error.
The Algorithm field is a one octet field that specifies both the KDF The Algorithm field is a one octet field that specifies both the KDF
to use and the symmetric algorithm to be used for data packet to use and the symmetric algorithm to be used for data packet
encryption. A registry for values of this field is defined in encryption. A registry for values of this field is defined in
Section 8.2. The value 0 is used to indicate the default KDF and Section 8.2. The value 0 is used to indicate the default KDF and
symmetric encryption mode. An implementation receiving a value for symmetric encryption mode. An implementation receiving a value for
an Algorithm it does not support MUST treat the case as an encoding an Algorithm it does not support MUST treat the case as an encoding
error as described in Section 4.3.4. All implementations MUST error as described in Section 4.3.4. All implementations MUST
support the default KDF. Note that since implementation of support the default KDF. Note that since implementation of
encryption and decryption is likely to be implemented in hardware for encryption and decryption is likely to be supported in hardware for
reasons of data throughput performance, the introduction of new reasons of data throughput performance, the introduction of new
algorithms may be bound by firmware or even hardware upgrades. algorithms may be bound by firmware or even hardware upgrades.
The Diffie-Hellman Group Num is from [RFC3526], so the group number The Diffie-Hellman Group Num is from [RFC3526], so the group number
for 2048 MODP is decimal 14. Note that this is a one octet field, for 2048 MODP is decimal 14. Note that this is a one octet field but
but is two octets in the [RFC7296] equivalent. This is not an issue is two octets in the [RFC7296] equivalent. This is not an issue
because there are only 30 MODP groups defined at present and new because there are only 30 MODP groups defined at present, new groups
groups are not added frequently. are not added frequently, and values are assigned sequentially.
The D-H public value will contain g^i or g^r depending on the The D-H public value will contain g^i or g^r depending on the
direction (i.e., the setting of the D flag) and is in big endian direction (i.e., the setting of the D flag) and is in big endian
order. order.
The length of the Diffie-Hellman public value for MODP groups MUST be The length of the Diffie-Hellman public value for MODP groups MUST be
equal to the length of the prime modulus over which the equal to the length of the prime modulus over which the
exponentiation was performed, prepending zero bits to the value if exponentiation was performed, prepending zero bits to the value if
necessary. necessary.
Once both sides have derived g^ir they need to feed that and the Once both sides have derived g^ir they need to feed that and the
other inputs described in Section 2.4 into the KDF indicated by the other inputs described in Section 2.4 into the KDF indicated by the
algorithm field. With the default algorithm (value zero), the KDF to algorithm field. With the default algorithm (value zero), the KDF to
be used is HKDF as specified in [RFC5869]. be used is HKDF as specified in [RFC5869].
The parameters for the use of HKDF are: The parameters for the use of HKDF are:
Hash: SHA-256 Hash: SHA-256
Salt: Not used
Skip: Do not skip Salt: Not used
Info: The catenation of a fixed string indicating use of MPLS-OS, Skip: Do not skip
with the value "MPLS-OS", the first 32 bits of the key Info: The catenation of a fixed string indicating use of MPLS-OS
exchange message, with the D flag set to 0, plus the LSP with the value "MPLS-OS", the first 32 bits of the key exchange
ID and the sender and receiver LSR IDs in that order. That message with the D flag set to 0, plus the LSP ID and the sender
is: and receiver LSR IDs in that order. That is:
MPLS-OS||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID MPLS-OS||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID
L: The output length in bits is 272. L: The output length in bits is 272.
The fixed string "MPLS-OS" is used as an input here to prevent The fixed string "MPLS-OS" is used as an input to prevent potential
potential cross-protocol attacks. Those might otherwise be cross-protocol attacks. Those might otherwise be possible if this
possible if this mechanism were to be copied in other protocols. mechanism were to be copied in other protocols. (If copying this
(If copying this mechanism for any reason, then a different mechanism for any reason, then a different fixed string value should
fixed string value should be used.) be used.)
LSP-ID is a unique identifier shared between the initiator and LSP-ID is a unique identifier shared between the initiator and
receiver (Alice and Bob) that uniquely identifies the LSP. receiver (Alice and Bob) that uniquely identifies the LSP.
[[If RSVP-TE is used for signaling, the LSP-ID is known along the LSP If RSVP-TE is used for signaling, the LSP-ID is known along the LSP
and at the two end points. Similarly, the LSP-ID is known if the and at the two end points. Similarly, the LSP-ID is known if the LSP
LSP is manually configured. It is not so clear how the LSP-ID is is manually configured. [[It is not so clear how the LSP-ID is known
known for LSPs established using LDP, although possibly we could use for LSPs established using LDP, although possibly we could use the
the FEC as defined for RFC 4379 and its extensions.]] FEC as defined for RFC 4379 and its extensions.]]
i-LSR-ID and r-LSR-ID are the LSR-IDs of the initiator and receiver i-LSR-ID and r-LSR-ID are the LSR-IDs of the initiator and receiver
respectively (Alice and Bob), where an LSR-ID is the 32 bit, globally respectively (Alice and Bob), where an LSR-ID is the 32 bit, globally
unique identifier of the LSR as described in [RFC5036] and [RFC4990]. unique identifier of the LSR as described in [RFC5036] and [RFC4990].
superior security.
The default encryption algorithm, AEAD_AES_GCM_128, specified in The default encryption algorithm, AEAD_AES_GCM_128, specified in
Section 3, requires a 128 bit session key. Section 3, requires a 128 bit session key.
The 272-bit HKDF output is the catenation of the session key, the The 272-bit HKDF output is the catenation of the session key, the
key-id, the witness value and the high-order 16 bits of the initial key-id, the witness value and the high-order 16 bits of the initial
nonce value in that order. That is the session key is the leftmost nonce value in that order. That is, the session key is the leftmost
128 bits of the HKDF output. The key-id is the next 4 bits, the 128 bits of the HKDF output. The key-id is the next 4 bits, the
witness value is the next 124 bits and the last 16 bits are the 16 witness value is the next 124 bits, and the last 16 bits are the 16
most significant bits of the initial nonce value. The low order 64 most significant bits of the initial nonce value. The low order 64
bits of the initial nonce value are set to zero before the first bits of the initial nonce value are set to zero before the first call
call to the AES-GCM encryption function. The key-id is carried in to the AES-GCM encryption function. The key-id is carried in
encrypted packets as described in Section 3.2. encrypted packets as described in Section 3.2.
Note that a 4 bit key-id is adequate in a system where, for any one Note that a 4 bit key-id is adequate in a system where, for any one
LSP there is one active key and one new or replaced key. There might LSP there is one active key and one new or replaced key. There might
also be more than one algorithm, and it is possible that new keys also be more than one algorithm, and it is possible that new keys
need to be pipelined if roll-over is frequent. In the case that a need to be pipelined if roll-over is frequent. In the case that a
newly-generated key-id is already in use, the key-id value is newly-generated key-id is already in use, the key-id value is
repeatedly incremented (modulo 16) until an unused value is found. repeatedly incremented (modulo 16) until an unused value is found.
If all 16 values are already in use, the key derivation function If all 16 values are already in use, the key derivation function
should not be executed. SHOULD NOT be executed.
4.3.4. Encoding Errors 4.3.4. Encoding Errors
Unknown values in received key Exchange TLVs MUST be treated as Unknown values in received key Exchange TLVs MUST be treated as
encoding errors. All messages that constitute encoding errors MUST encoding errors. All messages that constitute encoding errors MUST
be silently discarded. That is, such errors MUST NOT cause response be silently discarded. That is, such errors MUST NOT cause response
messages to be sent since those messages could be used as part of an messages to be sent since those messages could be used as part of an
attack to determine the capabilities of an LSR. attack to determine the capabilities of an LSR.
An LSR SHOULD log such errors and notify the operator. However, care An LSR SHOULD log such errors and notify the operator because
is needed even in these actions since they may be externally visible. encoding errors represent a failed attempt to communicate and might
indicate some form of attack. However, care is needed with these
actions since they may be externally visible. Furthermore, such
logging and reporting could consume local resources and might be used
as a way to overload or congest parts of the system. Therefore all
implementations that offer logging and notification of encoding
errors MUST include throttling mechanisms and MUST allow logging and
notification to be disabled through configuration.
4.4. Indicating the Return Path 4.4. Indicating the Return Path
The key exchange for MPLS-OS requires a two-way exchange of messages. The key exchange for MPLS-OS requires a two-way exchange of messages.
The Return field of the Key Exchange TLV indicates the reverse path The Return field of the Key Exchange TLV indicates the reverse path
to use for key exchange messages relevant to a particular LSP. to use for key exchange messages relevant to a particular LSP.
Whenever the LSP being secured is bidirectional, the same LSP SHOULD Whenever the LSP being secured is bidirectional, the same LSP SHOULD
be used for reverse path messages. Otherwise, the initiator selects be used for reverse path messages. Otherwise, the initiator selects
the communication channel as described in Section 4.3.3. the communication channel as described in Section 4.3.3.
If UDP is being used and it may be unclear to what address the If UDP is being used and it may be unclear to what address the
messages should be sent, the initiator MUST include a Source Address messages should be sent, the initiator MUST include a Source Address
TLV [RFC7212] to provide this information. TLV [RFC7212] to provide this information.
Operators should consider the security implications of the return Operators should consider the security implications of the return
path. The use of an already-secured LSP (Return type 3) may provide path. The use of an already-secured LSP (Return type 3) may provide
a preferable path because it will help to secure the GAP messages.
Implementations MUST make the choice of return path request sent by Implementations MUST make the choice of return path request sent by
an initiator available as a configuration option. As noted in an initiator available as a configuration option. As noted in
Section 4.3.1, the fact that the the initial GAP messages might not Section 4.3.1, the fact that the the initial GAP messages might not
be protected means that there is the potential to tamper with the be protected means that there is the potential to tamper with the
instructions that select a return path. This could be used as a instructions that select a return path. This could be used as a
vector for MITM attacks. To protect against this, an implementation vector for MITM attacks. To protect against this, an implementation
that initiates key exchange for MPLS Opportunistic Security MUST that initiates key exchange for MPLS Opportunistic Security MUST
verify that the response messages are received on the expected return verify that the response messages are received on the expected return
path channel and SHOULD raise an operator alert if the channel is path channel and SHOULD raise an operator alert if the channel is
unexpected. In these circumstances an implementation MAY be unexpected. In these circumstances an implementation MAY be
configured to abort establishment of MPLS-OS although, since that in configured to abort establishment of MPLS-OS although, since that in
itself is an attack vector, it is RECOMMENDED that implementations itself is an attack vector, it is RECOMMENDED that implementations
continue toward the use of MPLS-OS while notifying the operator. continue toward the use of MPLS-OS while notifying the operator.
4.5. Protecting the Key Exchange Protocol Messages 4.5. Protecting the Key Exchange Protocol Messages
GAP includes an Authentication TLV that can be used to protect GAP GAP includes an Authentication TLV that can be used to protect GAP
messages as described in [RFC7212]. If there is already an SA messages as described in [RFC7212]. If there is already an SA
between the initiator and recipient this TLV SHOULD be used. between the initiator and recipient this TLV SHOULD be used.
However, it is probable with MPLS-OS that no such SA exists and the However, it is probable with MPLS-OS that no such SA exists and the
point of the mechanisms described in this document is to exchange point of the mechanisms described in this document is to exchange
keys in that case, therefore, it is quite likely that the keys in that case, therefore, it is quite likely that the
Authentication TLV cannot be used on the first GAP exchanges. Authentication TLV cannot be used on the first GAP exchanges.
As described in Section 2.4, once one key exchange has been As described in Section 2.4, once one key exchange has been
successfully completed, further key exchanges should be protected successfully completed, further key exchanges should be protected
using a previous key. This is simply achieved since key exchange using a previous key. This is simply achieved since key exchange
messages are, themselves, carried in MPLS packets on the LSP and may messages are, themselves, carried in MPLS packets on the LSP and are
be subject to encryption exactly as any other packet. subject to encryption exactly as any other packet.
Furthermore, once keys have been established, they may also be used Furthermore, once keys have been established, they may also be used
in the GAP Authentication TLV. in the GAP Authentication TLV.
5. Applicability of MPLS Opportunistic Security 5. Applicability of MPLS Opportunistic Security
MPLS-OS provides another tool in the security and privacy toolkit. MPLS-OS provides another tool in the security and privacy toolkit.
It is not a panacea and does not solve (nor is it intended to solve) It is not a panacea and does not solve (nor is it intended to solve)
all security or privacy problems. In particular, the use of MPLS-OS all security or privacy problems. In particular, the use of MPLS-OS
does not protect user-data end-to-end that might be better secured does not protect user-data end-to-end that might be better secured
using encryption at the IP layer or at higher layers. using encryption at the IP layer or at higher layers.
As noted throughout this document, the intention of OS in MPLS is to As noted throughout this document, the intention of OS in MPLS is to
allow one LSR to enable encryption between itself and its neighbor, allow one LSR to enable encryption between itself and its neighbor,
or between itself and the other end of an LSP, in a dynamic and un- or between itself and the other end of an LSP, in a dynamic and un-
planned way. This can have benefits in a number of scenarios where planned way. This can have benefits in a number of scenarios where
the network that generates MPLS traffic transmits it over another the network that generates MPLS traffic transmits it over another
network (for example, carrier's carrier, or some deployments of network (for example, carrier's carrier, or some deployments of
enterprise network). Additionally, the use of MPLS-OS might allow a enterprise networks). Additionally, the use of MPLS-OS might allow a
service provider to offer a secure edge-to-edge service for a variety service provider to offer a secure edge-to-edge service for a variety
of applications ranging from VPNs through pseudowires and where the of applications ranging from VPNs through pseudowires and where the
payload traffic might not always be IP. Lastly, in some non- payload traffic might not always be IP. Lastly, in some non-
traditional carriers the user data belongs to the operator or is the traditional carriers the user data belongs to the operator or is the
direct responsibility of the operator (for example, in data centers, direct responsibility of the operator (for example, in data centers,
or in large-scale private networks). or in large-scale private networks).
As with all security mechanisms, there is a trade-off between a As with all security mechanisms, there is a trade-off between a
number of factors. On one side is the completeness of the security number of factors. On one side is the completeness of the security
of the user-data, and on the other side is the complexity of of the user-data, and on the other side is the complexity of
configuring and managing the necessary security associations. configuring and managing the necessary security associations.
Furthermore, while mechanisms closer to the end-user than MPLS-OS Furthermore, while mechanisms closer to the end-user than MPLS-OS
(for example, TLS and IPsec in tunnel mode) provide better security (for example, TLS and IPsec in tunnel mode) provide better security
for user-data by virtue of not transmitting the data across any for user-data by virtue of not transmitting the data across any
network hops without it being encrypted, such mechanisms often network hops without it being encrypted, such mechanisms often expose
expose more metadata for inspection by snoopers within the network. more metadata for inspection by snoopers within the network.
Additionally, while a variety of per-link encryption mechanisms exist Additionally, while a variety of per-link encryption mechanisms exist
and could be used to guard against attacks such as fiber taps, those and could be used to guard against attacks such as fiber taps, those
approaches do not protect against subverted nodes (i.e., routers) on approaches do not protect against subverted nodes (i.e., routers) on
the path since, by definition, per-link encryption does not protect the path since, by definition, per-link encryption does not protect
packets once they come off the link. MPLS-OS in the end-to-end LSP packets once they come off the link. MPLS-OS in the end-to-end LSP
mode protects packets on the links and as they cross transit routers. mode protects packets on the links and as they cross transit routers.
Nevertheless, it is not the purpose of this document to recommend the Nevertheless, it is not the purpose of this document to recommend the
use of MPLS-OS to the exclusion of all other encryption techniques. use of MPLS-OS to the exclusion of all other encryption techniques.
skipping to change at page 26, line 46 skipping to change at page 28, line 34
and privacy that they desire. and privacy that they desire.
Note that, in order that OS can be used, one end of a peering Note that, in order that OS can be used, one end of a peering
(neighbor or LSP end) must decide to attempt OS and the other end (neighbor or LSP end) must decide to attempt OS and the other end
must support it. This can be determined by the message exchanges must support it. This can be determined by the message exchanges
described in Section 4.3 since if one peer does not send a key described in Section 4.3 since if one peer does not send a key
exchange message then encryption will not be used, and if the other exchange message then encryption will not be used, and if the other
peer does not respond then it is unwilling or unable to decrypt peer does not respond then it is unwilling or unable to decrypt
messages. messages.
MPLS-OS should be applicable to all forms of MPLS. That is, it should MPLS-OS should be applicable to all forms of MPLS. That is, it
be possible to use it in RSVP-TE systems, in LDP systems, and in should be possible to use it in RSVP-TE systems, in LDP systems, and
MPLS-TP systems (by which we mean those that have manually configured in MPLS-TP systems (by which we mean those that have manually
LSPs). Equally, it should work for point-to-point (P2P) and configured LSPs). Equally, it should work for point-to-point (P2P)
multipoint-to-point (MP2P) uses of MPLS because there is a simple and multipoint-to-point (MP2P) uses of MPLS because there is a simple
relationship between the sender (encrypter) and the receiver relationship between the sender (encrypter) and the receiver
(decrypter) in both cases. In the MP2P case, the sender's identity (decrypter) in both cases. In the MP2P case, the sender's identity
can be extracted from the key identifier and there are considered to can be extracted from the key identifier and there are considered to
be enough key identifiers to allow an arbitrary number of senders on be enough key identifiers to allow an arbitrary number of senders on
the LSP. There will, however, be the need for the receiver to hold OE the LSP. There will, however, be the need for the receiver to hold
state (keys, packet counters) for each sender which may be a OE state (keys, packet counters) for each sender which may be a
significant amount of data for an MP2P LSP (although no more than if significant amount of data for an MP2P LSP (although no more than if
the same LSP were replaced by multiple P2P LSPs). Additionally, it the same LSP were replaced by multiple P2P LSPs). Additionally, it
should be noted that not only will each sender on an MP2P LSP have a should be noted that not only will each sender on an MP2P LSP have a
different key, but each may separately decide whether to encrypt data different key, but each may separately decide whether to encrypt data
or not. or not.
At this time it is not certain whether MPLS-OS can be applied to a At this time it is not certain whether MPLS-OS can be applied to a
point-to-multipoint (P2MP) or a multipoint-to-multipoint LSP in its point-to-multipoint (P2MP) or a multipoint-to-multipoint LSP in its
entirety because packet replication cannot handle the necessary key entirety because packet replication cannot handle the necessary key
conversions for each receiver. However, MPLS-OS can certainly be conversions for each receiver. However, MPLS-OS can certainly be
applied to individual hops on these LSPs. Further work is needed to applied to individual hops on these LSPs. Further work is needed to
determine whether non-branching multi-hop segments of P2MP and MP2P determine whether non-branching multi-hop segments of P2MP and MP2P
LSPs can also be protected using MPLS-OS. LSPs can also be protected using MPLS-OS.
5.1. Tunnel MPLS Packets 5.1. Tunnel MPLS Packets
Note that in the case of tunneling of MPLS packets in another Note that in the case of tunneling of MPLS packets in another
technology (such as MPLS-in-UDP [RFC7510]) there are two approaches technology (such as MPLS-in-UDP [RFC7510]) there are two approaches
that are viable: that are viable:
- The payload of the encapsulation (i.e., the entire MPLS packet) can o The payload of the encapsulation (i.e., the entire MPLS packet)
be encypted using the mechanisms described in this document without can be encypted using the mechanisms described in this document
any changes. Any payload identifier in the encapsulation header without any changes. Any payload identifier in the encapsulation
can remain set to "MPLS" since the encrypted packet is always just header can remain set to "MPLS" since the encrypted packet is
an MPLS packet. always just an MPLS packet.
- The encryption mechanisms present in the encapsulating technology o The encryption mechanisms present in the encapsulating technology
can be used without any need to use the mechanisms described in can be used without any need to use the mechanisms described in
this document. this document.
In some cases that processing of one label on the label stack depends In some cases that processing of one label on the label stack depends
on the values contained in the previous label stack entry. For on the values contained in the previous label stack entry. For
example, in the "Pipe Model" [RFC3270], the Diff-Serv treatment of example, in the "Pipe Model" [RFC3270], the Diff-Serv treatment of
the packet that is forwarded beyond the end of the tunnel depends on the packet that is forwarded beyond the end of the tunnel depends on
the setting of the TC field in the previous label stack entry. This the setting of the TC field in the previous label stack entry. This
requires that when a label is popped, the value of the TC field in requires that when a label is popped, the value of the TC field in
the label stack entry is cached for use while forwarding. In the the label stack entry is cached for use while forwarding. In the
case that the next label on the stack is the MEL, decryption of the case that the next label on the stack is the MEL, decryption of the
rest of the packet is required, and this caching would be a little rest of the packet is required, and this caching would be a little
more complicated to implement. This situation is mitigated by more complicated to implement. This situation is mitigated by
setting the TC field of the label stack entry that contains the MEL setting the TC field of the label stack entry that contains the MEL
to the value from the preceding label stack entry as described in to the value from the preceding label stack entry as described in
Section 3.1. Section 3.1.
The "Short Pipe Model" [RFC3270] can be handled using a combination The "Short Pipe Model" [RFC3270] can be handled using a combination
of the above technique and the procedures described in the next of the above technique and the procedures described in the next
section. section.
5.2. Penultimate Hop Popping 5.2. Penultimate Hop Popping
In penultimate hop popping (PHP) a label is removed from the label In penultimate hop popping (PHP) a label is removed from the label
stack of a packet one hop before the end of the LSP. The packet is stack of a packet one hop before the end of the LSP. The packet is
forwarded as though it was still carried on the LSP, but the label forwarded as though it was still carried on the LSP, but the label
stack entry for the LSP is removed. Sometimes we say that packet uses stack entry for the LSP is removed. Sometimes we say that packet
the "implicit null label". uses the "implicit null label" [RFC3032].
When there are additional subsequent labels on the label stack, this When there are additional subsequent labels on the label stack, this
has no impact on the use of the mechanisms described in this has no impact on the use of the mechanisms described in this
document. It is possible that after PHP the MEL will become the top document. It is possible that after PHP the MEL will become the top
label in the stack meaning that the received packet may encounter the label in the stack meaning that the next hop receiver of the packet
MEL as te top label. This has implications for the setting of the TC may encounter the MEL as the top label. This has implications for
and TTL fields in the MEL label stack entry as described in Section the setting of the TC and TTL fields in the MEL label stack entry as
3.1. described in Section 3.1.
However, in some cases of PHP the popped label is the bottom of the However, in some cases of PHP the popped label is the bottom of the
label stack and the packet after the popped label is some non-MPLS label stack and the packet after the popped label is some non-MPLS
payload protocol (such as IPv6). PHP is used specifically because payload protocol (such as IPv6). PHP is used specifically because
the receiving interface does not have MPLS capabilities in the the receiving interface does not have MPLS capabilities in the
forwarding plane. In this situation the packet is identified within forwarding plane. In this situation the packet is identified within
the link encapsulation on the final hop by its payload protocol type the link encapsulation on the final hop by its payload protocol type
(such as IPv6). If MPLS-OS is used this situation will change (such as IPv6). If MPLS-OS is used this situation will change
because even when the final label is stripped using PHP there will because even when the final label is stripped using PHP there will
remain a MEL entry in the label stack. Therefore the packet will remain a MEL entry in the label stack. Therefore the packet will
need to be identified as "MPLS" in the link encapsulation on the need to be identified as "MPLS" in the link encapsulation on the
final hop, yet the receiver might not be capable of handling MPLS final hop, yet the receiver might not be capable of handling MPLS
packets. packets.
This problem can be approached in two ways: This problem can be approached in two ways:
- The penultimate hop may note the presence of the MEL during PHP o The penultimate hop may note the presence of the MEL during PHP
and attempt to remove the MEL as well. This is unlikely to be and attempt to remove the MEL as well. This is unlikely to be
successful as the encryption negotiation has been conducted successful as the encryption negotiation has been conducted
between the end points of the LSP and the penultimate hop is not between the end points of the LSP and the penultimate hop is not
aware of the keys or algorithms needed for decryption. aware of the keys or algorithms needed for decryption.
Furthermore, this approach would leave the packet unencrypted on
Furthermore, this approach would leave the packet unencrypted on its final hop which may be counter to the intent of the LSP end
its final hop which may be counter to the intent of the LSP end points.
points.
- The end point of the LSP should recognize that it cannot have both o The end point of the LSP should recognize that it cannot have both
MPLS-OS and PHP. Indeed, in agreeing to the use of MPLS-OS the end MPLS-OS and PHP. Indeed, in agreeing to the use of MPLS-OS the
point is making a statement about its ability to handle the MEL and end point is making a statement about its ability to handle the
so it can choose: MEL and so it can choose:
- to request PHP and allow the penultimate hop to set the payload * to request PHP and allow the penultimate hop to set the payload
indicator of the link encapsulation header to "MPLS"; or indicator of the link encapsulation header to "MPLS"; or
- to not request PHP. * to not request PHP.
6. Security Considerations 6. Security Considerations
6.1. Security Improvements 6.1. Security Improvements
See Section 2.1. See Section 2.1.
6.2. Applicability 6.2. Applicability
See Section 5. See Section 5.
6.3. Continued Vulnerabilities 6.3. Continued Vulnerabilities
The mechanisms described in this document do not provide protection The mechanisms described in this document do not provide protection
against certain types of MITM attacks. For example, the key exchange against certain types of MITM attacks. For example, the key exchange
protocol in Section 4.3 will not detect if key exchange messages or protocol in Section 4.3 will not detect if key exchange messages or
their responses are intercepted and discarded such that the their responses are intercepted and discarded such that the
initiating peer believes that encryption is not supported. initiating peer believes that encryption is not supported.
Similarly, those messages may be tampered with such that a receiver Similarly, those messages may be tampered with such that a receiver
cannot determine the correct mapping of table index to algorithm and cannot determine the correct mapping of table index to algorithm and
key when an encrypted packet is received. Furthermore, the MEL in an key when an encrypted packet is received. Furthermore, the MEL in an
MPLS packet is not protected and may be overwritten such that a MPLS packet is not protected and may be overwritten such that a
receiver is unable to decrypt the packet. receiver is unable to decrypt the packet.
See Section 7.1 for a discussion of how active MITM attacks can be See Section 7.1 for a discussion of how active MITM attacks can be
detected. detected.
6.4. New Security Considerations 6.4. New Security Considerations
If a pair of LSRs do not do the key exchange before sending any data If a pair of LSRs do not do the key exchange before sending any data
packets on the LSP then those first packets will not be protected by packets on the LSP (for example, if data transmission starts as soon
OS and hence will be available to a monitor. as the LSP is set up and while OS is being enabled) then those first
packets will not be protected by OS and hence will be available to a
monitor. This is not a new security vulnerability per se since the
situation without OS is that those packets are not protected.
However, the presence of OS (i.e., the configuration to support OS on
the LSP) may give the false impression that all packets are
protected. An implementation might reasonably be designed to not
allow transmission of payload packets on an LSP for which OS is
configured until OS is established and ready for use.
If a MITM can prevent the OS key exchange from completing, e.g. If a MITM can prevent the OS key exchange from completing, e.g. via
via deleting messages or changing bits in messages, and if the LSRs deleting messages or changing bits in messages, and if the LSRs
continue to send data regardless then those data packets will be continue to send data regardless then those data packets will be
available to a monitor. That is, in simple terms, a MITM attacker is available to a monitor. That is, in simple terms, a MITM attacker is
able to prevent OS from being used through a very simple attack, and able to prevent OS from being used through a very simple attack, and
the only options for the end points in this situation are to send no the only options for the end points in this situation are to send no
data or to send data in the clear. Again, it should be pointed out data or to send data in the clear. Again, it should be pointed out
that this occurrence is not worse than not running OS at all, but has that this occurrence is not worse than not running OS at all, but has
the benefit of being detectable by end points. See Section 2.4 and the benefit of being detectable by end points. See Section 2.4 and
Section 7.1 for a description of how alarms should be raised in these Section 7.1 for a description of how alarms should be raised in these
circumstances. Furthermore, Section 4.3.1 and Section 4 describe how circumstances. Furthermore, Section 4.3.1 and Section 4 describe how
the return path for key exchange messages might be hijacked to better the return path for key exchange messages might be hijacked to better
facilitate MITM attacks and indicates how the initiator of MPLS-OS facilitate MITM attacks and indicates how the initiator of MPLS-OS
can detect this and what actions it should take. can detect this and what actions it should take.
Thus, as been previously noted, OS is not a cure for all ills or a Thus, as been previously noted, OS is not a cure for all ills or a
prevention against all attacks, but it does offer a way to increase prevention against all attacks, but it does offer a way to increase
security in some circumstances. security in some circumstances.
7. Manageability Considerations 7. Manageability Considerations
As described in Section 2.4 node-wide and per-LSP behavior SHOULD be As described in Section 2.4 node-wide and per-LSP behavior SHOULD be
configurable to describe the action where key agreement exchange or configurable to describe the action where key agreement exchange or
packet decryption fails. In any case, such events MUST trigger packet decryption fails. In any case, such events MUST trigger
alarms to the operator. alarms to the operator.
7.1. MITM Detection 7.1. MITM Detection
Section 2.4 introduces the concept of a function of the shared Section 2.4 introduces the concept of a function of the shared secret
secret that can be compared by two LSRs that are using OS to see that can be compared by two LSRs that are using OS to see whether
whether they are victims of an active MITM attack. they are victims of an active MITM attack.
Section 4.3 describes how a witness value is derived for the Section 4.3 describes how a witness value is derived for the default
default KDF, HKDF. KDF, HKDF.
The participating LSRs can simply log this value plus the LSP The participating LSRs can simply log this value plus the LSP and LSR
and LSR IDs from time to time and a management application can IDs from time to time and a management application can compare the
compare the values. If they are different for the same LSP ID, values. If they are different for the same LSP ID, then an active
then an active MITM attack has taken place. MITM attack has taken place.
It needs to be carefully noted that the management channel used to It needs to be carefully noted that the management channel used to
log or otherwise compare the witness values from the two LSRs MUST be log or otherwise compare the witness values from the two LSRs MUST be
secure. It is likely that routers use relatively high security secure. It is likely that routers use relatively high security
management channels for configuration and other management management channels for configuration and other management
operations. operations.
8. IANA Considerations 8. IANA Considerations
8.1. GAP Key Exchange TLV 8.1. GAP Key Exchange TLV
IANA maintains a registry called "Generic Associated Channel (G-ACh) IANA maintains a registry called "Generic Associated Channel (G-ACh)
Parameters" with a sub-registry called "G-ACh Advertisement Protocol Parameters" with a sub-registry called "G-ACh Advertisement Protocol
Application Registry" from which new assignments may be made through Application Registry" from which new assignments may be made through
the "IETF review" allocation policy [RFC5226]. IANA is requested to the "IETF review" allocation policy [RFC5226]. IANA is requested to
make a new allocation as follows: make a new allocation as follows:
Value | Description | Reference Value | Description | Reference
------+-------------------------------------------------+----------- ------+-------------------------------------------------+-----------
TBD1 | Opportunistic Key Exchange Protocol for MPLS | [This.ID] TBD1 | Opportunistic Key Exchange Protocol for MPLS | [This.ID]
8.2. Key Derivation Functions and Symmetric Algorithms 8.2. Key Derivation Functions and Symmetric Algorithms
IANA maintains a registry called "Generic Associated Channel (G-ACh) IANA maintains a registry called "Generic Associated Channel (G-ACh)
Parameters". IANA is requested to create a new sub-registry called Parameters". IANA is requested to create a new sub-registry called
"G-ACh Advertisement Protocol: MPLS Encryption Algorithms Registry" "G-ACh Advertisement Protocol: MPLS Encryption Algorithms Registry"
with new values to be assigned through "IETF Review" as defined in with new values to be assigned through "IETF Review" as defined in
[RFC5226]. [RFC5226].
The available range is 0 - 255. The available range is 0 - 255.
IANA is requested to record the following information and create an IANA is requested to record the following information and create an
skipping to change at page 31, line 34 skipping to change at page 33, line 34
0 | HKDF | AEAD_AES_GCM_128 | [This.I-D] 0 | HKDF | AEAD_AES_GCM_128 | [This.I-D]
1-255 | Unassigned | | 1-255 | Unassigned | |
9. Acknowledgements 9. Acknowledgements
Many thanks to Alia Atlas for detailed discussion of the implications Many thanks to Alia Atlas for detailed discussion of the implications
and mechanisms of MPLS opportunistic security. Thanks also to Ron and mechanisms of MPLS opportunistic security. Thanks also to Ron
Bonica for encouraging this work, to Sean Turner and Stewart Bryant Bonica for encouraging this work, to Sean Turner and Stewart Bryant
for early review, and to Jeff Haas, Eric Rosen, and Ross Callon for for early review, and to Jeff Haas, Eric Rosen, and Ross Callon for
discussions. Thanks for MPLS Review Team comments from Mach Chen and discussions. Thanks for MPLS Review Team comments from Mach Chen and
Lizhong Jin, and to Charlie Kaufman for review comments. Lizhong Jin, and to Charlie Kaufman and George Swallow for review
comments.
Additional thanks to Andy Malis and Danny McPherson for advice about Additional thanks to Andy Malis and Danny McPherson for advice about
the use of the Control Word. the use of the Control Word.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3526] Kivinen, T., and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, DOI 10.17487/RFC3526, May 2003,
<http://www.rfc-editor.org/info/rfc3526>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC5116] D. McGrew, "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
Associated Channel", RFC 5586, June 2009. "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010. Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>.
[RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic
Associated Channel (G-ACh) Advertisement Protocol", RFC Associated Channel (G-ACh) Advertisement Protocol",
7212, June 2014. RFC 7212, DOI 10.17487/RFC7212, June 2014,
<http://www.rfc-editor.org/info/rfc7212>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels" RFC 7274, and Retiring Special-Purpose MPLS Labels", RFC 7274,
June 2014. DOI 10.17487/RFC7274, June 2014,
<http://www.rfc-editor.org/info/rfc7274>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mpls-pm-udp-return] [I-D.ietf-mpls-rfc6374-udp-return-path]
Bryant, S., Sivabalan, S., and S. Soni, "MPLS Performance Bryant, S., Sivabalan, S., and S. Soni, "RFC6374 UDP
Measurement UDP Return Path", draft-ietf-mpls-pm-udp- Return Path", draft-ietf-mpls-rfc6374-udp-return-path-04
return, work in progress. (work in progress), August 2015.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
[RFC3270] Le Faucheur, F. (Ed), "Multi-Protocol Label Switching [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
(MPLS) Support of Differentiated Services", RFC 3207, May P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
2002. Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
Requirements for Security", BCP 106, RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
2005. DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures" RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
Addresses in Generalized Multiprotocol Label Switching Addresses in Generalized Multiprotocol Label Switching
(GMPLS) Networks", RFC 4990, September 2007. (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990,
September 2007, <http://www.rfc-editor.org/info/rfc4990>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Specification", RFC 5036, October 2007. "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC6239] K. Igoe, "Suite B Cryptographic Suites for Secure Shell [RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell
(SSH)", RFC 6239, May 2011. (SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011,
<http://www.rfc-editor.org/info/rfc6239>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and Delord, S., [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping", "Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, January 2014. RFC 7110, DOI 10.17487/RFC7110, January 2014,
<http://www.rfc-editor.org/info/rfc7110>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Is an Attack", BCP 188, RFC 7258, May 2014. Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
T. Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, October 2014. (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7325] C. Villamizar, Ed., "MPLS Forwarding Compliance and [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
Performance Requirements", RFC 7325, August 2014. and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <http://www.rfc-editor.org/info/rfc7325>.
[RFC7435] V. Dukhovni, "Opportunistic Security: Some Protection Most [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
of the Time", RFC 7435, December 2014. Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7510] X. Xu et al., "Encapsulating MPLS in UDP", RFC 7510, April [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
2015. "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>.
[RFC7551] Zhang, F., Jing, R., and R. Gandhi, "RSVP-TE Extensions [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
for Associated Bidirectional Label Switched Paths (LSPs)", Extensions for Associated Bidirectional Label Switched
RFC 7551, May 2015. Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<http://www.rfc-editor.org/info/rfc7551>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Juniper Networks Juniper Networks
EMail: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Stephen Farrell Stephen Farrell
Trinity College Dublin Trinity College Dublin
Dublin, 2 Dublin 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
 End of changes. 167 change blocks. 
495 lines changed or deleted 568 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/