draft-ietf-mpls-opportunistic-encrypt-01.txt   draft-ietf-mpls-opportunistic-encrypt-02.txt 
Network Working Group A. Farrel Network Working Group A. Farrel
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track S. Farrell Intended status: Standards Track S. Farrell
Expires: September 16, 2016 Trinity College Dublin Expires: March 24, 2017 Trinity College Dublin
March 15, 2016 September 20, 2016
Opportunistic Security in MPLS Networks Opportunistic Security in MPLS Networks
draft-ietf-mpls-opportunistic-encrypt-01 draft-ietf-mpls-opportunistic-encrypt-02
Abstract Abstract
This document describes a way to apply opportunistic security between This document describes a way to apply opportunistic security between
adjacent nodes on an MPLS Label Switched Path (LSP) or between end adjacent nodes on an MPLS Label Switched Path (LSP) or between end
points of an LSP. It explains how keys may be agreed to enable points of an LSP. It explains how keys may be agreed to enable
encryption, and how key identifiers are exchanged in encrypted MPLS encryption, and how key identifiers are exchanged in encrypted MPLS
packets. Finally, this document describes the applicability of this packets. Finally, this document describes the applicability of this
approach to opportunistic security in MPLS networks with an approach to opportunistic security in MPLS networks with an
indication of the level of improved security as well as the continued indication of the level of improved security as well as the continued
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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. This Internet-Draft will expire on March 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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.
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
1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. Payload Encryption . . . . . . . . . . . . . . . . . 6
2. Principles of Opportunistic Security . . . . . . . . . . . . 6 1.2.2. Link Layer Security . . . . . . . . . . . . . . . . . 6
2.1. Why Do We Need Opportunistic Security? . . . . . . . . . 6 1.2.3. Encryption on Pseudowires . . . . . . . . . . . . . . 7
2.2. Opportunistic Security at 10,000ft . . . . . . . . . . . 7 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. What about a Man-in-the-Middle? . . . . . . . . . . . . . 9 2. Principles of Opportunistic Security . . . . . . . . . . . . 7
2.4. OS in MPLS Overview . . . . . . . . . . . . . . . . . . . 10 2.1. Why Do We Need Opportunistic Security? . . . . . . . . . 7
3. MPLS Packet Encryption . . . . . . . . . . . . . . . . . . . 12 2.2. Opportunistic Security at 10,000ft . . . . . . . . . . . 9
3.1. MPLS Encryption Label . . . . . . . . . . . . . . . . . . 15 2.3. What about a Man-in-the-Middle? . . . . . . . . . . . . . 10
3.2. Control Word . . . . . . . . . . . . . . . . . . . . . . 16 2.4. OS in MPLS Overview . . . . . . . . . . . . . . . . . . . 11
3.3. Considerations for ECMP . . . . . . . . . . . . . . . . . 16 3. MPLS Packet Encryption . . . . . . . . . . . . . . . . . . . 13
3.4. Backward Compatibility . . . . . . . . . . . . . . . . . 17 3.1. MPLS Encryption Label . . . . . . . . . . . . . . . . . . 16
3.5. MTU Considerations . . . . . . . . . . . . . . . . . . . 18 3.2. Control Word . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Recursive Encryption . . . . . . . . . . . . . . . . . . 18 3.3. Considerations for ECMP . . . . . . . . . . . . . . . . . 18
4. Key Exchange For Opportunistic Security in MPLS . . . . . . . 19 3.4. Backward Compatibility . . . . . . . . . . . . . . . . . 19
4.1. Initiating MPLS-OS . . . . . . . . . . . . . . . . . . . 19 3.5. MTU Considerations . . . . . . . . . . . . . . . . . . . 19
4.2. MPLS G-ACh Advertisement Protocol for Key Exchange . . . 20 3.6. Recursive Encryption . . . . . . . . . . . . . . . . . . 20
4.3. Key Exchange Protocol . . . . . . . . . . . . . . . . . . 20 4. Key Exchange For Opportunistic Security in MPLS . . . . . . . 20
4.3.1. Communication Channels . . . . . . . . . . . . . . . 21 4.1. Initiating MPLS-OS . . . . . . . . . . . . . . . . . . . 21
4.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 21 4.2. MPLS G-ACh Advertisement Protocol for Key Exchange . . . 21
4.3.3. Key Exchange TLV . . . . . . . . . . . . . . . . . . 22 4.3. Key Exchange Protocol . . . . . . . . . . . . . . . . . . 22
4.3.4. Encoding Errors . . . . . . . . . . . . . . . . . . . 26 4.3.1. Communication Channels . . . . . . . . . . . . . . . 22
4.4. Indicating the Return Path . . . . . . . . . . . . . . . 26 4.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 22
4.5. Protecting the Key Exchange Protocol Messages . . . . . . 27 4.3.3. Key Exchange TLV . . . . . . . . . . . . . . . . . . 23
5. Applicability of MPLS Opportunistic Security . . . . . . . . 27 4.3.4. Encoding Errors . . . . . . . . . . . . . . . . . . . 27
5.1. Tunnel MPLS Packets . . . . . . . . . . . . . . . . . . . 29 4.4. Indicating the Return Path . . . . . . . . . . . . . . . 27
5.2. Penultimate Hop Popping . . . . . . . . . . . . . . . . . 29 4.5. Protecting the Key Exchange Protocol Messages . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. Applicability of MPLS Opportunistic Security . . . . . . . . 28
6.1. Security Improvements . . . . . . . . . . . . . . . . . . 31 5.1. Tunnel MPLS Packets . . . . . . . . . . . . . . . . . . . 30
6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 31 5.2. Penultimate Hop Popping . . . . . . . . . . . . . . . . . 31
6.3. Continued Vulnerabilities . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.4. New Security Considerations . . . . . . . . . . . . . . . 31 6.1. Security Improvements . . . . . . . . . . . . . . . . . . 32
7. Manageability Considerations . . . . . . . . . . . . . . . . 32 6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 32
7.1. MITM Detection . . . . . . . . . . . . . . . . . . . . . 32 6.3. Continued Vulnerabilities . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 6.4. New Security Considerations . . . . . . . . . . . . . . . 32
8.1. GAP Key Exchange TLV . . . . . . . . . . . . . . . . . . 32 7. Manageability Considerations . . . . . . . . . . . . . . . . 33
8.2. Key Derivation Functions and Symmetric Algorithms . . . . 33 7.1. MITM Detection . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1. GAP Key Exchange TLV . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 8.2. Key Derivation Functions and Symmetric Algorithms . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . 35 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
skipping to change at page 4, line 34 skipping to change at page 4, line 38
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 of acceptable in the MPLS data plane. Additionally, the consequences 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 an The key functions of MPLS-OS described in Section 2.4 are based on 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
research and experimentation since key change is fundamental to the research and experimentation since key change is fundamental to the
skipping to change at page 5, line 23 skipping to change at page 5, line 26
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 salt 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 for MPLS-OS.
Note that this experiment uses a special-purpose MPLS label. Since Note that this experiment uses a special-purpose MPLS label
this document is experimental it makes use of an extended special- [RFC7274]. Because this document is experimental it makes use of an
purpose label from the experimental range. If this work is moved to extended special- purpose label from the experimental range. If this
be published on the standards track, it will be possible to achieve work is moved to be published on the standards track, it will be
the same function using a simple special-purpose label rather than an possible to achieve the same function using a simple special-purpose
extended special-purpose label. label rather than an 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 Several tools already exist for securing data exchanged over an MPLS
describe existing security tools for securing MPLS Data. The text data plane. These mechansisms do not provide identical function to
needs to describe the use of IPsec used for the payload of MPLS LSPs, MPLS-OS, but part of the decission about the value of MPLS-OS must
and should also cover the use of link layer security (such as include an analysis of these other approaches to determine whether
MACsec). they are good enough and whether the cost and complexity of MPLS-OS
is justified.
Consideration should also be given to the use of MACsec for As will be seen from the following sections, the existing tools and
pseudowires. Where an Ethernet service is delivered over a packet techniques provide a powerful set of encryption mechanisms that can
tunnel (such as an IP or an MPLS tunnel) then the end points may be very effective in specfic environments. Each has its plusses and
consider themselves to be just one Ethernet hop apart and could apply minusses, and some need further development to achieve a lower level
MACsec. of configuration. The biggest consideration, however, is whether the
encryption offered can be achieved to the same level for all payloads
and for all link types.
TBD 1.2.1. Payload Encryption
One way to secure data sent over an MPLS network is to encrypt it
before it is passed to the MPLS layer.
Applications can take responsibility for encrypting their own data
using techniques such as Transport Layer Security (TLS) [RFC5246],
and this is the ideal solution for the protection of user data.
However, many applications and many users do not take these
precautions. Furthermore, solutions like TLS leave some metadata
(such as the destination IP address) exposed as the packets transit
the IP network.
IPsec [RFC4302], [RFC4303]) can be applied end-to-end (between host
systems) or edge-to-edge (between routers). Applied end-to-end,
IPsec exhibits many of the same properties as TLS. Applied edge-to-
edge it allows a network operator to encrypt a stream of IP packets
before they are handed off to the MPLS network. However, not every
packet carried by an MPLS network is an IP packet: an MPLS LSP may
carry other traffic as well, such as in the case of a pseudowire.
Furthermore, IPsec has historically placed a heavy "full-mesh"
configuration burden on implmenetations although this is now ease
with the introduction of the NULL Authentication Method in the
Internet Key Exchange Protocol Version 2 [RFC7619] allows for
opportunistic key exchange to support IPsec.
1.2.2. Link Layer Security
Another approach to securing data sent over an MPLS network is to
encrypt it as it passes over the lower layer links. That is, each
router along the LSP uses layer two encryption on the link between it
and its next hop neighbour.
MACsec [IEEE-802.1AE] provides a mechanism to encrypt Ethernet frames
travelling over individual Ethernet segments or across Ethernet
networks. As such it is a valuable solution to protecting MPLS
packets flowiing between routers that are connected by Ethernet.
Where MPLS routers are connected by other link layer types, or
directly over layer one, a possible approach is to encpsulate each
packet in an Ethernet frame and apply MACsec before transmission.
An argument against link layer security is that it is hop-by-hop.
The MPLS data plane is not able to verify end-to-end encryption and
there is a chain of trust (that could also use the control plane)
that packets are forwarded encrypted and that routers have not
intercpted packets that must necessarily be decrypted at each hop.
Furthermore there s currently no standard for opportunistic security
with MACsec meaning that keys must be configured or exchanged by some
other means.
1.2.3. Encryption on Pseudowires
Some traffic sent over an MPLS network will be in the form of a
pseudowire [RFC3985]. This a "layer inversion" where lower layer
traffic is encoded in an MPLS packet to be carried over an MPLS
network.
A large amount of traffic carried over MPLS pseudowires is Ethernet.
In this case, the pseudowire provides a virtual Ethernet segment
between two Ethernet switches that can consider themselves directly
attached in the Ethernet network, and that means they can run MACsec
over the adjacency (i.e., over the pseudowire). However (of course),
this approach is only valid for Ethernet connectivity and does not
hold for pseudowires that carry other data types such as Time
Division Multiplexing (TDM).
1.3. Notation 1.3. Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Principles of Opportunistic Security 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
skipping to change at page 6, line 35 skipping to change at page 8, line 6
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
used: this is called their shared secret. used: this is called their shared secret.
In many IETF protocols, such as the common usage of Transport Layer In many IETF protocols, such as the common usage of Transport Layer
Security (TLS) S/MIME Cryptographic Message Syntax (CMS) or Pretty Security (TLS), S/MIME Cryptographic Message Syntax (CMS), or Pretty
Good Privacy (PGP), Alice simply invents a random key "k" and then Good Privacy (PGP), Alice simply invents a random key "k" and then
encrypts that under Bob's public key "Pub-b" and sends Bob both encrypts that under Bob's public key "Pub-b" and sends Bob both
E(Pub-b,k) and E(k,M). (There are lots of other details and other E(Pub-b,k) and E(k,M). (There are lots of other details and other
options for how this can be handled, but we ignore those for now.) options for how this can be handled, but we ignore those for now.)
In such cases, before Alice can send "E(k,M)", she needs to acquire In such cases, before Alice can send "E(k,M)", she needs to acquire
Bob's public key and she needs to be certain that it really is Bob's Bob's public key and she needs to be certain that it really is Bob's
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)
skipping to change at page 7, line 30 skipping to change at page 8, line 50
o the scale of configuration that is needed for a full set of o the scale of configuration that is needed for a full set of
Security Associations (SAs) between all communicating parties Security Associations (SAs) between all communicating parties
o the likelihood of configuration errors o the likelihood of configuration errors
o the security vulnerabilities associated with manual keying and o the security vulnerabilities associated with manual keying and
unsecured exchange of keys. 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 transport, 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
public and private values, where the private value can be randomly public and private values, where the private value can be randomly
generated, perhaps even once per message "M". They swap the public generated, perhaps even once per message "M". They swap the public
values, and can then, thanks to the "magic" of Diffie-Hellman, derive values, and can then, thanks to the "magic" of Diffie-Hellman, derive
skipping to change at page 9, line 40 skipping to change at page 11, line 9
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,
must engage in the D-H exchange between each pair of Alices and Bobs, he must engage in the D-H exchange between each pair of Alices and
and he must must decrypt and encrypt each packet he wants to inspect. Bobs, and he must must decrypt and encrypt each packet he wants to
This imposes a higher cost and is especially burdensome if he is inspect. This imposes a higher cost and is especially burdensome if
attempting to do it in parallel for lots of Alice/Bob pairs using he is attempting to do it in parallel for lots of Alice/Bob pairs
lots of different keys and communication sessions. using 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 Charlie to detect the presence of Charlie as a MITM. This is because Charlie
has to agree one key "kA" with Alice, and a different key "kB" with has to agree one key "kA" with Alice, and a different key "kB" with
Bob. As far as we know, Charlie cannot arrange that kA equals kB Bob. As far as we know, Charlie cannot arrange that kA equals kB
because both sides contribute to the key value in the D-H key because both sides contribute to the key value in the D-H 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
skipping to change at page 10, line 22 skipping to change at page 11, line 40
the cost of detection for Charlie may be even greater than the cost the cost of detection for Charlie may be even greater than 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 exchange 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
sending LSR is the point of encryption and the receiving LSR is the sending LSR is the point of encryption and the receiving LSR is the
point of decryption such that the pair of LSRs define the SA. These point of decryption such that the pair of LSRs define the SA. These
additional inputs are used to ensure that we end up with different additional inputs are used to ensure that we end up with different
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 an LSP is instantiated and for each new LSP [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 in MPLS-OS MUST be of at least 2048-bits.
MUST support the 2048-bit modular exponentiation (MODP) group from Implementations MUST support the 2048-bit modular exponentiation
Section 3 of [RFC3526] and SHOULD support the larger MODP groups from (MODP) group from Section 3 of [RFC3526] and SHOULD support the
[RFC3526]. larger MODP groups from [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 is for a key (the key-id) from the shared Diffie-Hellman value, which is
also based on the KDF output. The key will be used with a symmetric also based on the KDF output. The key will be used with a symmetric
encryption algorithm, such as AEAD_AES_GCM_128 (the default, encryption algorithm, such as AEAD_AES_GCM_128 (the 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 a 96 for too long. The nonce defined for these keys is derived using a 96
bit counter incremented by one for each encrypted packet. It is bit counter incremented by one for each encrypted packet. It is
skipping to change at page 11, line 17 skipping to change at page 12, line 35
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 as s used for initial key
old session key as described in Section 4.5. This process can, of exchange, but this time the exchange is protected with the 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 day RECOMMENDED that the key on an LSP be changed at least once every 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. before encrypting 2^64 packets.
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 default behavior for 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 KDF attacks [RFC7258]. As with the key-id, we base this on the same KDF
output. output.
We might want to consider deriving the witness value from a separate We might have considered 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. If such a generic MITM-
additional information needs to be logged with the witness value so detection approach was used we would also need to consider what
that comparisons can easily be made at scale but without creating new additional information needed to be logged with the witness value so
privacy-invasive meta-data. That last is not much of an issue for that comparisons could easily be made at scale, but without creating
MPLS-OS, but could be elsewhere. At present we do not intend to go new privacy-invasive meta-data. That last is not much of an issue
for the generic MITM-detection approach, but it is worth considering. for MPLS-OS, but could be a concern if the same approach were to be
used in some other protocols. The generic MITM-detection approach,
is left for future study.
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
skipping to change at page 12, line 28 skipping to change at page 13, line 48
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. Figure 1
and 2 should make this point clear. and Figure 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.3) 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 resynchcronize its own counter in order packet has been dropped and to resynchronize its own counter in order
to be able to continue to decrypt received packets. In the event to be able to continue to decrypt received packets. In the event
that the counter cannot be resynchronized or that more than 65536 that the counter cannot be resynchronized or that more than 65536
packet are lost in one batch the receiver will encounter a decryption packet are lost in one batch the receiver will encounter a decryption
error. In this case the receiver may report a general decryption error. In this case the receiver may report a general decryption
error or may attempt to resynchronize by advancing its own counter in error or may attempt to resynchronize by advancing its own counter in
units of 65536 according to the modulo value in the received packet. units of 65536 according to the modulo value in the received packet.
Note that incrementing the counter in order to test for decryption Note that incrementing the counter in order to test for decryption
failure does generate a potential DoS if, e.g., an attacker failure does generate a potential Denial of Service (DoS) if, e.g.,
decrements the nonce-mod-65536 value. Implementations that do such an attacker decrements the nonce-mod-65536 value. Implementations
tests SHOULD maintain a small maximum window size beyond which they that do such tests SHOULD maintain a small maximum window size beyond
will cease attempting to decrypt. It could be that throwing an error which they will cease attempting to decrypt. It could be that
might be the more effective response if the packet loss rates are throwing an error might be the more effective response if the packet
expected to be low enough. loss rates are 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.
skipping to change at page 13, line 38 skipping to change at page 15, line 12
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. The payload is the data label in the stack has the S bit set. The payload is the 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 |
+-----------+ +-----------+ +-----------+ +-----------+
skipping to change at page 17, line 15 skipping to change at page 18, line 30
In order to increase the entropy, an implementation that inserts an In order to increase the entropy, an implementation that inserts an
MEL and control word MAY also insert an Entropy Label Indicator (ELI) MEL and control word MAY also insert an Entropy Label Indicator (ELI)
and Entropy Label (EL) as defined in [RFC6790] ELI and EL are and Entropy Label (EL) as defined in [RFC6790] ELI and EL are
positioned in the label stack before the MEL as shown in Figure 5. positioned in the label stack before the MEL as shown in Figure 5.
The setting of the fields in the ELI and EL label stack entries are The setting of the fields in the ELI and EL label stack entries are
as described 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
receiver discovers label 15 and does not support extended special- receiver discovers label 15 and does not support extended special-
purpose labels it will discard the packet. Similarly when a receiver purpose labels it will discard the packet. Similarly when a receiver
that supports extended special-purpose labels, but does not support that supports extended special-purpose labels, but does not support
the MEL (i.e., does not support encryption) it will discard the the MEL (i.e., does not support encryption) it will discard the
packet. (Note that care must be taken if multiple experiments are packet. (Note that care must be taken if multiple experiments are
skipping to change at page 19, line 38 skipping to change at page 20, line 51
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 (for
using encrypted messages. example, for key change) can be made 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 sends the or a pair of LSP end points). That is, the upstream LSR sends the
first G-ACh message that initiates key exchange. The key that is first G-ACh message that initiates key exchange. The key that is
generated after the exchange is used to encrypt traffic travelling in generated after the exchange is used to encrypt traffic travelling in
the 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
either one, or both of the directions of traffic flow for the LSP. neither, either one, or both of the directions of traffic flow for
But it is important to note that the keys used are different in each the LSP. But it is important to note that the keys used are
direction, each being generated and exchanged through a separate different in each direction, each being generated and exchanged
instance of the procedures described in this document. Note that the through a separate instance of the procedures described in this
input parameters for key derivation listed in Section 4.3.3 show LSP document. Note that the input parameters for key derivation listed
identifier, initiator LSR identifier, and responder LSR identifier as in Section 4.3.3 show LSP identifier, initiator LSR identifier, and
three of the ordered list of pieces of information used by the key responder LSR identifier as three of the ordered list of pieces of
derivation function. In the case of a bidirectional LSP, the LSP information used by the key derivation function. In the case of a
identifier will be the same in each direction, and the two LSR bidirectional LSP, the LSP identifier will be the same in each
identifiers will be the same, but the LSR identifiers will be used in direction, and the two LSR identifiers will be the same, but the LSR
the reverse order at the two end points of the MPLS-OS exchange and identifiers will be used in the reverse order at the two end points
this will reduce the chance of the same key being used in each of the MPLS-OS exchange and this will reduce the chance of the same
direction. key being used in each 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 the 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.
skipping to change at page 21, line 16 skipping to change at page 22, line 25
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 similar to that used to indicate a Ping ([RFC4379] and [RFC7110]), and similar to that used to indicate
return path for MPLS performance measurement in a return path for MPLS performance measurement in [RFC7876]. That
[I-D.ietf-mpls-rfc6374-udp-return-path]. That is, the forward is, the forward message is sent on the LSP and includes the identity
message is sent on the LSP and includes the identity of the return of the return path communication channel. The return path may be
path communication channel. The return path may be indicated as a indicated as a UDP communication over IP, as an LSP running in the
UDP communication over IP, as an LSP running in the opposite opposite direction, or as the reverse direction of a bidirectional
direction, or as the reverse direction of a bidirectional LSP. 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
skipping to change at page 25, line 26 skipping to change at page 26, line 35
mechanism for any reason, then a different fixed string value should mechanism for any reason, then a different 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 LSP and at the two end points. Similarly, the LSP-ID is known if the LSP
is manually configured. [[It is not so clear how the LSP-ID is known is manually configured. [[It is not so clear how the LSP-ID is known
for LSPs established using LDP, although possibly we could use the for LSPs established using LDP, although possibly we could use the
FEC as defined for RFC 4379 and its extensions.]] FEC as defined for RFC 4379 and its extensions. Note that LSPs
established using LDP are essentially multpoint-to-point, but the
securiity relationship is one-to-one between a sender and the
receiver.]]
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].
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 call bits of the initial nonce value are set to zero before the first 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
skipping to change at page 27, line 47 skipping to change at page 29, line 8
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 networks). 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 center
or in large-scale private networks). interconnect, 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 expose network hops without it being encrypted, such mechanisms often 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.
As already mentioned, MPLS-OS is offered as another tool in the tool As already mentioned, MPLS-OS is offered as another tool in the
kit and users as well as network operators are strongly advised to toolkit and users as well as network operators are strongly advised
consider using a variety of tools to achieve the level of security to consider using a variety of tools to achieve the level of security
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 MPLS-OS should be applicable to all forms of MPLS. That is, it
should be possible to use it in RSVP-TE systems, in LDP systems, and should be possible to use it in RSVP-TE systems, in LDP systems, and
in MPLS-TP systems (by which we mean those that have manually in MPLS-TP systems (by which we mean those that have manually
configured LSPs). Equally, it should work for point-to-point (P2P) configured LSPs). Equally, it should work for point-to-point (P2P)
and 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 the LSP. There will, however, be the need for the receiver to hold
OE state (keys, packet counters) for each sender which may be a OS 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 and nonce, but each may separately decide whether to
or not. encrypt data 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 to a multipoint-to-multipoint LSP in
entirety because packet replication cannot handle the necessary key its entirety because packet replication cannot handle the necessary
conversions for each receiver. However, MPLS-OS can certainly be key 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:
o The payload of the encapsulation (i.e., the entire MPLS packet) o The payload of the encapsulation (i.e., the entire MPLS packet)
can be encypted using the mechanisms described in this document can be encypted using the mechanisms described in this document
without any changes. Any payload identifier in the encapsulation without any changes. Any payload identifier in the encapsulation
header can remain set to "MPLS" since the encrypted packet is header can remain set to "MPLS" since the encrypted packet is
always just an MPLS packet. always just an MPLS packet.
o 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 the 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
skipping to change at page 30, line 21 skipping to change at page 31, line 31
may encounter the MEL as the top label. This has implications for may encounter the MEL as the top label. This has implications for
the setting of the TC and TTL fields in the MEL label stack entry as the setting of the TC and TTL fields in the MEL label stack entry as
described in Section 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:
o 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
skipping to change at page 31, line 47 skipping to change at page 32, line 52
monitor. This is not a new security vulnerability per se since the monitor. This is not a new security vulnerability per se since the
situation without OS is that those packets are not protected. situation without OS is that those packets are not protected.
However, the presence of OS (i.e., the configuration to support OS on However, the presence of OS (i.e., the configuration to support OS on
the LSP) may give the false impression that all packets are the LSP) may give the false impression that all packets are
protected. An implementation might reasonably be designed to not protected. An implementation might reasonably be designed to not
allow transmission of payload packets on an LSP for which OS is allow transmission of payload packets on an LSP for which OS is
configured until OS is established and ready for use. configured until OS is established and ready for use.
If a MITM can prevent the OS key exchange from completing, e.g. via If a MITM can prevent the OS key exchange from completing, e.g. 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 running no 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 has been previously noted, OS is not a cure for all ills or
prevention against all attacks, but it does offer a way to increase a 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
skipping to change at page 35, line 7 skipping to change at page 36, line 12
RFC 7212, DOI 10.17487/RFC7212, June 2014, RFC 7212, DOI 10.17487/RFC7212, June 2014,
<http://www.rfc-editor.org/info/rfc7212>. <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,
DOI 10.17487/RFC7274, June 2014, DOI 10.17487/RFC7274, June 2014,
<http://www.rfc-editor.org/info/rfc7274>. <http://www.rfc-editor.org/info/rfc7274>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mpls-rfc6374-udp-return-path] [IEEE-802.1AE]
Bryant, S., Sivabalan, S., and S. Soni, "RFC6374 UDP IEEE Computer Society, "IEEE 802.1AE Media Access Control
Return Path", draft-ietf-mpls-rfc6374-udp-return-path-04 (MAC) Security", August 2006.
(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, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <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, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>. <http://www.rfc-editor.org/info/rfc3032>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>. <http://www.rfc-editor.org/info/rfc3270>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>. <http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
skipping to change at page 36, line 9 skipping to change at page 37, line 19
[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, DOI 10.17487/RFC4990, (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990,
September 2007, <http://www.rfc-editor.org/info/rfc4990>. September 2007, <http://www.rfc-editor.org/info/rfc4990>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell [RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell
(SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011, (SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011,
<http://www.rfc-editor.org/info/rfc6239>. <http://www.rfc-editor.org/info/rfc6239>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, [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, DOI 10.17487/RFC7110, January 2014, RFC 7110, DOI 10.17487/RFC7110, January 2014,
<http://www.rfc-editor.org/info/rfc7110>. <http://www.rfc-editor.org/info/rfc7110>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
skipping to change at page 36, line 46 skipping to change at page 38, line 15
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>. <http://www.rfc-editor.org/info/rfc7510>.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<http://www.rfc-editor.org/info/rfc7551>. <http://www.rfc-editor.org/info/rfc7551>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<http://www.rfc-editor.org/info/rfc7619>.
[RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path
for Packet Loss and Delay Measurement for MPLS Networks",
RFC 7876, DOI 10.17487/RFC7876, July 2016,
<http://www.rfc-editor.org/info/rfc7876>.
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. 54 change blocks. 
163 lines changed or deleted 262 lines changed or added

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