< draft-farrelll-mpls-opportunistic-encrypt-01.txt   draft-farrelll-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 Intended status: Standards Track
Expires: July 21, 2014 S. Farrell Expires: August 10, 2014 S. Farrell
Trinity College, Dublin Trinity College, Dublin
January 21, 2014 February 10, 2014
Opportunistic Encryption in MPLS Networks Opportunistic Encryption in MPLS Networks
draft-farrelll-mpls-opportunistic-encrypt-01.txt draft-farrelll-mpls-opportunistic-encrypt-02.txt
Abstract Abstract
This document describes a way to apply opportunistic encryption This document describes a way to apply opportunistic encryption
between adjacent nodes on an MPLS Label Switched Path (LSP) or between adjacent nodes on an MPLS Label Switched Path (LSP) or
between end points of an LSP. It explains how keys may be exchanged between end points of an LSP. It explains how keys may be exchanged
to enable the encryption, and indicates how key identifiers are to enable the encryption, and indicates how key identifiers are
exchanged in encrypted MPLS packets. Finally, this document exchanged in encrypted MPLS packets. Finally, this document
describes the applicability of opportunistic encryption in MPLS describes the applicability of opportunistic encryption in MPLS
networks with an indication of the level of improved security as well networks with an indication of the level of improved security as well
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction ................................................... 3 1. Introduction ................................................... 3
2. Principles of Opportunistic Encryption ......................... 4 2. Principles of Opportunistic Encryption ......................... 4
2.1 Why Do We Need Opportunistic Encryption? ..................... 4 2.1 Why Do We Need Opportunistic Encryption? ..................... 4
2.2 Opportunistic Encryption at 10,000ft ......................... 5 2.2 Opportunistic Encryption at 10,000ft ......................... 5
2.3 What about a Man-in-the-Middle? .............................. 6 2.3 What about a Man-in-the-Middle? .............................. 6
2.4 OE in MPLS Overview ........................................... 8 2.4 OE in MPLS Overview ........................................... 8
3. MPLS Packet Encryption ......................................... 9 3. MPLS Packet Encryption ......................................... 9
3.1. Opportunistic Encryption Label Indicator .................... 12 3.1. Opportunistic Encryption Label .............................. 12
3.2. Opportunistic Encryption Label .............................. 12 3.2. Control Word ................................................ 13
3.3. Control Word ................................................ 13 3.3. Considerations for ECMP ..................................... 13
3.4. Considerations for ECMP ..................................... 14 3.4. Backward Compatibility ...................................... 14
3.5. Backward Compatibility ...................................... 14 3.5. MTU Considerations .......................................... 15
3.6. MTU Considerations .......................................... 15 3.6. Recursive OE ................................................ 15
3.7. Recursive OE ................................................ 15 4. Key Exchange For Opportunistic Encryption in MPLS ............. 15
4. Key Exchange For Opportunistic Encryption in MPLS ............. 16
4.1. Associated Channel for Key Exchange ......................... 16 4.1. Associated Channel for Key Exchange ......................... 16
4.2. Key Exchange Protocol ....................................... 17 4.2. Key Exchange Protocol ....................................... 16
4.3. Protecting the Key Exchange Protocol Messages ............... 19 4.3. Protecting the Key Exchange Protocol Messages ............... 19
5. Applicability of MPLS Opportunistic Encryption ................ 19 5. Applicability of MPLS Opportunistic Encryption ................ 19
6. Security Considerations ....................................... 21 6. Security Considerations ....................................... 21
6.1. Security Improvements ....................................... 21 6.1. Security Improvements ....................................... 21
6.2. Continued Vulnerabilities ................................... 21 6.2. Continued Vulnerabilities ................................... 21
6.3. New Security Considerations ................................. 21 6.3. New Security Considerations ................................. 21
7. Manageability Considerations .................................. 22 7. Manageability Considerations .................................. 22
7.1. MITM Detection .............................................. 22 7.1. MITM Detection .............................................. 22
8. IANA Considerations .......................................... 22 8. IANA Considerations .......................................... 22
8.1. Opportunistic Encryption Label Indicator .................... 22 8.1. Opportunistic Encryption Label Indicator .................... 22
8.2. Pseudowire Associated Channel Types ......................... 23 8.2. Pseudowire Associated Channel Types ......................... 23
8.3. Key Derivation Functions and Symmetric Algorithms ........... 23 8.3. Key Derivation Functions and Symmetric Algorithms ........... 23
9. Acknowledgements ............................................. 23 9. Acknowledgements ............................................. 24
10. References .................................................. 24 10. References .................................................. 24
10.1. Normative References ...................................... 24 10.1. Normative References ...................................... 24
10.2. Informative References .................................... 24 10.2. Informative References .................................... 24
Authors' Addresses ............................................... 25 Authors' Addresses ............................................... 25
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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
in hand, they can easily derive a value "k" from that using any of a in hand, they can easily derive a value "k" from that using any of a
number of well-known key derivation functions (KDF). number of well-known key derivation functions (KDF).
As you can see from the above, Alice and Bob do not need to pre- As you can see from the above, Alice and Bob do not need to pre-
arrange anything other than "g" and "p", and those can be public arrange anything other than "g" and "p", and those can be public
values, that are used by everyone everywhere (or at least by all values, that are used by everyone everywhere (or at least by all
participants in a particular deployment). Yet, Alice and Bob have participants in a particular deployment). Yet, Alice and Bob have
managed to derive a common value for a key "k" that they can use to managed to derive a common value for a key "k" that they can use to
encrypt (and decrypt) "M". encrypt (and decrypt) "M".
This kind of opportunistic encryption provides strong This kind of opportunistic encryption provides strong confidentiality
confidentiality and can be built into any protocol that allows Alice and can be built into any protocol that allows Alice and Bob to
and Bob to occasionally exchange public values. occasionally exchange public values.
There are also additional advantages to key agreement when There are also additional advantages to key agreement when compared
compared to key transport. The most important of those is to key transport. The most important of those is that with key
that with key agreement we can easily ensure that k has a agreement we can easily ensure that k has a property called Perfect
property called Perfect Forward Secrecy (PFS). That means Forward Secrecy (PFS). That means that an attacker has to separately
that an attacker has to separately attack each key k. In attack each key k. In contrast, if we use the key transport
contrast, if we use the key transport approach, then an approach, then an attacker who somehow accesses Bob's private key
attacker who somehow accesses Bob's private key "Priv-b" "Priv-b" can record lots of traffic and later go back and decrypt all
can record lots of traffic and later go back and decrypt all the "E(Pub-b,k)" values that all Alice's ever sent to Bob. With key
the "E(Pub-b,k)" values that all Alice's ever sent to Bob. agreement as described, since both Alice and Bob contribute to the
With key agreement as described, since both Alice and Bob value k, and since Alice and Bob will typically periodically generate
contribute to the value k, and since Alice and Bob will new private values i and r (perhaps even for every single M),
typically periodically generate new private values i and r compromise of one party is far less catastrophic, and an attacker who
(perhaps even for every single M), compromise of one party gets access to one private value gets far less benefit.
is far less catastrophic, and an attacker 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?
But OE is not resilient to Man-in-the-Middle (MITM) attacks. The But OE is not resilient to Man-in-the-Middle (MITM) attacks. The
problem is that Alice does not know that it was really Bob's public problem is that Alice does not know that it was really Bob's public
value that she received; it could have been Charlie's public value value that she received; it could have been Charlie's public value
sent by Charlie. And Charlie could also send Bob his public value sent by Charlie. And Charlie could also send Bob his public value
pretending to be Alice. Now Charlie can share a key with Alice and pretending to be Alice. Now Charlie can share a key with Alice and
a key with Bob so that Charlie can sit between Alice and Bob a key with Bob so that Charlie can sit between Alice and Bob
decrypting what he gets from Alice and then re-encrypting it to send decrypting what he gets from Alice and then re-encrypting it to send
skipping to change at page 8, line 8 skipping to change at page 8, line 8
attack for all Alice/Bob pairs to be alerted to the problem. In attack for all Alice/Bob pairs to be alerted to the problem. In
such cases the cost of detection for Charlie may be even greater than such cases the cost of detection for Charlie may be even greater than
the cost of performing the MITM attack. the cost of performing the MITM attack.
Hence we conclude that OE can have considerable value when used in Hence we conclude that OE can have considerable value when used in
MPLS networks. MPLS networks.
2.4 OE in MPLS Overview 2.4 OE in MPLS Overview
[[Editor Note - the details here are suitable for an early revision [[Editor Note - the details here are suitable for an early revision
draft. draft. We might change to ECDH later, or to use another KDF, or
We might change to ECDH later, or to use another KDF, or symmetric symmetric cipher mode. All that is for discussion.]]
cipher mode. All that is for discussion.]]
The basic requirement for MPLS OE is that we want to provide a way The basic requirement for MPLS OE is that we want to provide a way
for two MPLS nodes to do an OE key exchange and to derive a session for two MPLS nodes to do an OE key exchange and to derive a session
key from that to use in MPLS packet encryption. key 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 [RFC5996] using essentially the Section 2.2. We model this on IKE [RFC5996] 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 key derivation function (KDF) g^ir, into a standard key derivation function (KDF) that also takes
that also takes as input the LSP identifier (LSP ID) together with as input the LSP identifier (LSP ID) together with the sending and
the sending and receiving LSR IDs - where the the sending LSR is the receiving LSR IDs - where the the sending LSR is the point of
point of encryption and the receiving LSR is the point of decryption encryption and the receiving LSR is the point of decryption such that
such that the pair of LSRs define the Security Association (SA). the pair of LSRs define the Security Association (SA). These
These additional inputs are used to ensure that we end up with additional inputs are used to ensure that we end up with different
different keys on an LSP even if the same g^i and g^r values keys on an LSP even if the same g^i and g^r values are re-used. The
are re-used. The KDF to be used here is as defined in [RFC5869]. KDF to be used here is as defined in [RFC5869].
D-H values used for MPLS OE MUST be of at least 2048-bits. D-H values used for MPLS OE MUST be of at least 2048-bits.
Implementations of MPLS OE MUST support the 2048-bit modular Implementations of MPLS OE MUST support the 2048-bit modular
exponentiation (MODP) group from Section 3 of [RFC3526] and SHOULD exponentiation (MODP) group from Section 3 of [RFC3526] and SHOULD
support the larger MODP groups from [RFC3526]. support the 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 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 is also based on the KDF output. The key will be used with a
symmetric encryption algorithm, such as AEAD_AES_GCM_128 (the symmetric encryption algorithm, such as AEAD_AES_GCM_128 (the
skipping to change at page 8, line 48 skipping to change at page 8, line 47
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 MPLS OE keys is derived using for too long. The nonce defined for MPLS OE keys is derived using
a 96 bit counter incremented by one for each encrypted packet. a 96 bit counter incremented by one for each encrypted packet.
It is critical for security that nonce values MUST NOT be re-used It is critical for security that nonce values MUST NOT be re-used
with a given key. (This is an inherent issue with how AES-GCM or any with a 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 are RECOMMENDED to change keys at least Accordingly, implementations are RECOMMENDED to change keys at least
every 2^32 packets, and MUST change keys before encrypting 2^64 every 2^32 packets, and MUST change keys before encrypting 2^64
packets. For an LSP running over a fully-busy 100Gbe interface, packets. For an LSP running over a fully-busy 100Gbe interface,
we might assume that means roughly 160 million packets per second, we might assume that means roughly 160 million packets per second,
or roughly 2^44 packets per day. The 2^64 limit therefore means 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 changing keys daily in the busiest cases of some of the largest
current links capacities. current links capacities.
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
skipping to change at page 9, line 18 skipping to change at page 9, line 18
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, and to agree a new key, two LSRs describes how two LSRs agree keys, and to agree a new key, two LSRs
simply run the same key agreement exchange, but this time protected simply run the same key agreement exchange, but this time protected
with the old session key as described in Section 4.3. This process with the old session key as described in Section 4.3. This process
can, of course, be repeated any number of times for the same LSP. It can, of 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 is RECOMMENDED that the key on an LSP be changed at least once every
day or every 10^6 packets whichever is sooner. day or every 10^6 packets whichever is sooner.
[[Editor Note: These values need considered in the light of latest [[Editor Note: These values need considered in the light of latest
cryptology advice, but also understanding that this is "best- cryptology advice, but also understanding that this is "best-effort"
effort" OE]] OE.]]
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 OE exchange, or tearing down the LSP. Note that a simple attack on OE
is to tamper with key agreement exchange messages or encrypted is to tamper with key agreement exchange messages or encrypted
packets so that OE fails. Such attacks may be intended to cause the packets so that OE 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.
skipping to change at page 9, line 50 skipping to change at page 9, line 51
Section 5. Section 5.
3. MPLS Packet Encryption 3. MPLS Packet Encryption
MPLS packets may be individually encrypted according to the MPLS packets may be individually encrypted according to the
mechanisms described in this section. mechanisms described in 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 special purpose label [ID.ietf-mpls-special-purpose-labels] of a new special purpose label [ID.ietf-mpls-special-purpose-labels]
in the label stack. This is referred to as the Opportunistic in the label stack. This is referred to as the Opportunistic
Encryption Label Indicator (OELI). The format of the OELI is Encryption Label (OEL). The format of the OEL is described in
described in Section 3.1. Section 3.1.
The OELI is followed immediately by a further label stack entry that
contains an identifier of the key and algorithm that is in use. This
label stack entry is referred to as the Opportunistic Encryption
Label (OEL). The format of the OEL is described in Section 3.2.
The OEL MUST have the bottom of stack bit (the S bit) set and MUST be The OEL 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.3. 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. Implementations MUST support the without decryption. Implementations MUST support the
AEAD_AES_GCM_128 encryption algorithm, as specified in Section 5.1 AEAD_AES_GCM_128 encryption algorithm, as specified in Section 5.1
of [RFC5116], which is the default as described in Section 4.2 of of [RFC5116], which is the default as described in Section 4.2 of
this document. 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 encryption. The nonce is an implicit packet counter. The initial
initial nonce value is derived from the HKDF output at key nonce value is derived from the HKDF output at key agreement time and
agreement time and the counter is incremented by one for the counter is incremented by one for each packet encrypted on the
each packet encrypted on the sending side and by one sending side and by one for each packet successfully decrypted on the
for each packet successfully decrypted on the receiver side. receiver side.
Although the nonce is not transmitted with the packets, a 3-bit Although the nonce is not transmitted with the packets, a 16-bit
counter indicates the nonce value modulo 8. This feature allows a counter carried in the control Word indicates the nonce value modulo
receiving node to quickly spot that a packet has been dropped and 65536. This feature allows a receiving node to quickly spot that a
resynch its own counter in order to be able to continue to decrypt packet has been dropped and resynch its own counter in order to be
received packets. In the event that more than 7 packets are lost in able to continue to decrypt received packets. In the event that the
one batch the receiver will encounter a decryption error. In this counter cannot be resynchronized or that more than 65536 packet are
case the receiver may report a general decryption error or may lost in one batch the receiver will encounter a decryption error. In
attempt to resynchronize by advancing its own counter in units of 8 this case the receiver may report a general decryption error or may
according to the modulo value in the received packet. Note that attempt to resynchronize by advancing its own counter in units of
incrementing the counter in order to test for decryption failure 65536 according to the modulo value in the received packet. Note
does generate a potential DoS if e.g. an attacker decrements the that incrementing the counter in order to test for decryption failure
nonce-mod-8 value. Implementations that do such tests SHOULD does generate a potential DoS if, e.g., an attacker decrements the
nonce-mod-65536 value. Implementations that do such tests SHOULD
maintain a small maximum window size beyond which they will cease maintain a small maximum window size beyond which they will cease
attempting to decrypt. It could be that throwing an error might attempting to decrypt. It could be that throwing an error might
be the more effective response if the packet loss rates are be the more effective response if the packet loss rates are
expected to 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 OEL to stop implementations The bottom of stack bit is set in the OEL 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 OELI, OEL, and control word depend on whether The position of the OEL and control word depend on whether hop-by-hop
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 opportunistic encryption. The left hand part of the after hop-by-hop opportunistic encryption. The left hand part of the
figure shows a normal MPLS packet with a label stack and payload. figure shows 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 The bottom 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 data 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 the OELI followed by the OEL been encrypted. The top of stack is the OEL with the S bit set. The
with the S bit set. The OEL is followed by a control word. OEL is followed by a control word. Everything that follows the
Everything that follows the control word is the entire original MPLS control word is the entire original MPLS packet encrypted.
packet encrypted.
----------- . ----------- ----------- .
| Top Label | . | OELI | | Top Label | .
+-----------+ . +-----------+ +-----------+ . -----------
| Label | . | OEL S=1 | | Label | . | OEL S=1 |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label S=1 | .| Ctrl Word | | Label S=1 | .| Ctrl Word |
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
~ Payload ~ ~ Encrypted ~ ~ Payload ~ ~ Encrypted ~
| | | | | | | |
-----------........----------- -----------........-----------
Figure 1 : The Use of the OEL for Hop-by-Hop Opportunistic Encryption Figure 1 : The Use of the OEL for Hop-by-Hop Opportunistic 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 opportunistic encryption. The left hand part of the after end-to-end opportunistic encryption. The left hand part of the
figure shows a normal MPLS packet with a label stack and payload. figure shows 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 The bottom 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 be prefixed by a control word. The right hand part of the figure
shows how the top two labels (or however many labels are needed for shows how the top two labels (or however many labels are needed for
end-to-end delivery) remain at the top of the label stack. Then end-to-end delivery) remain at the top of the label stack. Then
follows the OELI and OEL with S bit set, and a control word. The follows the OEL with S bit set, and a control word. The remainder of
remainder of the packet is encrypted and contains the rest of the the packet is encrypted and contains the rest of the label stack and
label stack and the payload. the payload.
----------- ----------- -----------
| Top Label | | Top Label | | Top Label |
+-----------+ +-----------+ +-----------+ -----------
| Label | | Label | | Label | | Top Label |
+-----------+. +-----------+ +-----------+. +-----------+
| Label | . | OELI | | Label | . | Label |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label | . | OEL S=1 | | Label | . | OEL S=1 |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label S=1 | .| Ctrl Word | | Label S=1 | .| Ctrl Word |
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
~ Payload ~ ~ Encrypted ~ ~ Payload ~ ~ Encrypted ~
| | | | | | | |
-----------........----------- -----------........-----------
Figure 2 : The Use of the OEL for End-to-End Opportunistic Encryption Figure 2 : The Use of the OEL for End-to-End Opportunistic Encryption
3.1. Opportunistic Encryption Label Indicator 3.1. Opportunistic Encryption Label
The Opportunistic Encryption Label Indicator (OELI) is a normal label The Opportunistic Encryption Label (OEL) is a normal label stack
stack entry carrying a special purpose label with value TBD1 to be entry carrying a special purpose label with value TBD1 to be assigned
assigned by IANA. The format of the label stack entry is defined in by IANA. The format of the label stack entry is defined in [RFC3032]
[RFC3032] and shown in Figure 3. 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 OELI Label Stack Entry Figure 3 : Format of the OEL Label Stack Entry
Label: Set to TBD1 to indicate this is an OELI Label: Set to TBD1 to indicate this is an OEL
TC: SHOULD be copied from the TC of the first encrypted label. TC: SHOULD be copied from the TC of the first encrypted label.
S: MUST be set to zero.
TTL: SHOULD be set to the TTL of the first encrypted label.
3.2. Opportunistic Encryption Label
The Opportunistic Encryption Label (OEL) is carried in a normal label
stack entry immediately following an OELI. The format of the label
stack entry is defined in [RFC3032] and shown in Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 : Format of the OEL Label Stack Entry
Label: Any value from 16 to 1048575 used as a look-up into a table of
encryption algorithms and keys that has been established
through configuration or dynamic key exchange as described in
Section 4.
This label MUST NOT be used for forwarding, and MUST NOT come
from the range 0 through 15.
TC: This field contains the packet counter (nonce) for the
encryption algorithm and key currently in use modulo 8. 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.
S: MUST be set to one. S: MUST be set to one.
TTL: SHOULD be set to zero to prevent encrypted packets being TTL: SHOULD be set to zero to prevent encrypted packets being
accidentally forwarded beyond the point of intended accidentally forwarded beyond the point of intended
decryption. decryption.
3.3. Control Word The sending LSR MAY choose different values for the TTL and TC fields
if it is known that the OEL will not be exposed as the top label at
any point along the LSP (for example, by penultimate hop popping).
3.2. Control Word
The control word is inserted after the OEL as described in Section 3. The control word is inserted after the OEL as described in Section 3.
The S bit set to one in the OEL and the presence of the control word The S bit set to one in the OEL 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 5. 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 1|Version| Reserved | Channel Type | |0 0 0 0| Flags |FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Control Word for Opportunistically Encrypted MPLS Figure 4: Control Word for Opportunistically Encrypted MPLS
Version: MUST be zero. Flags: The Flags field is treated as a four-bit number. It
Reserved: MUST be sent as 0, and ignored on receipt. contains the key-id that identifies the algorithm
Channel Type: Set to TBD2 to indicate that the following bytes are and key as established through configuration or
encrypted MPLS. dynamic key exchange as described in 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.
3.4. Considerations for ECMP 3.3. Considerations for ECMP
As previously stated, the S bit set in the OEL and the presence of As previously stated, the S bit set in the OEL 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
OELI and OEL MAY also insert an Entropy Label Indicator (ELI) and OEL and OEL MAY also insert an Entropy Label Indicator (ELI) and
Entropy Label (EL) as defined in [RFC6790]. The ELI and EL are Entropy Label (EL) as defined in [RFC6790] ELI and EL are positioned
positioned in the label stack before the OELI and OEL. The setting in the label stack before the OEL as shown in Figure 5. The setting
of the fields in the ELI and EL label stack entries are as described of the fields in the ELI and EL label stack entries are as described
in [RFC6790]. in [RFC6790].
The ELI and EL will normally occur immediately before the OELI, but The ELI and EL will normally occur immediately before the OEL, but
they MAY be placed higher up the label stack. they MAY be placed higher up the label stack.
----------- -----------
| Top Label | | Top Label |
+-----------+
| Label |
----------- +-----------+ ----------- +-----------+
| Top Label | | ELI | | Top Label | | Label |
+-----------+ +-----------+ +-----------+ +-----------+
| Label | | EL | | Label | | ELI |
+-----------+. +-----------+ +-----------+. +-----------+
| Label | . | OELI | | Label | . | EL |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label | . | OEL S=1 | | Label | . | OEL S=1 |
+-----------+ . +-----------+ +-----------+ . +-----------+
| Label S=1 | .| Ctrl Word | | Label S=1 | .| Ctrl Word |
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
~ Payload ~ ~ Encrypted ~ ~ Payload ~ ~ Encrypted ~
| | | | | | | |
-----------........----------- -----------........-----------
Figure 6 : The Use of ELI and EL with OEL Figure 5 : The Use of ELI and EL with OEL
3.5. 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 OELI when the receiver does not support to a sender using the OEL when the receiver does not support
opportunistic encryption. opportunistic 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 the OELI and does not support opportunistic receiver discovers the OEL and does not support opportunistic
encryption it will discard the packet. The net result is that when a encryption it will discard the packet. The net result is that when a
sender uses opportunistic encryption in error, all packets that it sender uses opportunistic encryption in error, all packets that it
sends on the LSP will be discarded by the receiver. Note that in sends on the LSP will be discarded by the receiver. Note that in
this discussion, "the receiver" may be the next hop if single hop this discussion, "the receiver" may be the next hop if single hop
encryption is used, or may be the end of the LSP if end-to-end 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 OELI except potentially as part of an ECMP hash. will not inspect the OEL except potentially as part of an ECMP hash,
This means that transit nodes will not encounter the OELI during and it should be noted that the use of Special Purpose Labels in
normal packet processing and will not discard packets. hashing is strongly discouraged. This means that transit nodes will
not encounter the OEL during normal packet processing and will not
discard packets.
3.6. MTU Considerations 3.5. MTU Considerations
Adding the OELI and OEL as described above will reduce the available Adding the OEL and Control Word as described above will reduce the
data size by 8 octets. Furthermore, as described in in Section 3, available data size by 8 octets. Furthermore, as described in in
the output of the encryption algorithm is 16 octets longer than the Section 3, the output of the encryption algorithm is 16 octets longer
input. Therefore, the use of MPLS OE reduces the available MTU by 20 than the input. Therefore, the use of MPLS OE reduces the available
octets. MTU by 24 octets.
When end-to-end OE is in use this can be considered by the ingress When end-to-end OE is in use this can be considered by the ingress
LSR, however, when single-hop OE is in use the participating LSRs LSR, however, when single-hop OE is in use the participating LSRs
need to advertise this reduction in link MTU so that the packets do need to advertise this reduction in link MTU so that the packets do
not overflow. MPLS packets MUST NOT be fragmented as a result of not overflow. MPLS packets MUST NOT be fragmented as a result of
OE. OE.
3.7. Recursive OE 3.6. Recursive OE
The use of OELI, OEL, and control word described in Section 3 may The use of OEL and control word described in Section 3 may be applied
be applied recursively. That is, the payload of an encrypted MPLS recursively. That is, the payload of an encrypted MPLS packet may,
packet may, itself be an encrypted MPLS packet. This may be itself be an encrypted MPLS packet. This may be particularly useful
particularly useful in the case where an MPLS VPN has native MPLS in the case where an MPLS VPN has native MPLS traffic.
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 OE applied at the same LSR. Additionally, it should be LSP have OE applied at the same LSR. Additionally, it should be
noted that, as described in Section 3.6, each recursive encryption noted that, as described in Section 3.6, each recursive encryption
reduces the MTU by 20 octets. reduces the MTU by 24 octets.
4. Key Exchange For Opportunistic Encryption in MPLS 4. Key Exchange For Opportunistic Encryption 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
skipping to change at page 16, line 38 skipping to change at page 16, line 20
points of the LSP. A type field within the common message header, points of the LSP. A type field within the common message header,
the Associated Channel Header (ACH), is used to indicate the type of the Associated Channel Header (ACH), is used to indicate the type of
message carried. 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].
4.1. Associated Channel for Key Exchange 4.1. Associated Channel for Key Exchange
The Associated Channel Type value TBD3 indicates that the packet The Associated Channel Type value TBD2 indicates that the packet
contains a Key Exchange Protocol message as defined in Section 4.2. contains a Key Exchange Protocol message as defined in Section 4.2.
Implementations that do not support key exchange in this manner will Implementations that do not support key exchange in this manner will
discard received packets with this Associated Channel Type as discard received packets with this Associated Channel Type as
described in [RFC5586]. This will result in no dynamic key exchange, described in [RFC5586]. This will result in no dynamic key exchange,
but other key definitions are still supported (such as manual but other key definitions are still supported (such as manual
configuration) and may be used to construct a table of algorithms and configuration) and may be used to construct a table of algorithms and
keys that can be used to achieve MPLS encryption using the mechanisms keys that can be used to achieve MPLS encryption using the mechanisms
described in Section 3. described in Section 3.
Note that TBD3 indicates the use of Diffie-Hellman key exchange. If Note that TBD2 indicates the use of Diffie-Hellman key exchange. If
ECDH is added later a new value will be required. ECDH is added later a new value will be required.
[[Editor Note. An alternative to this is to embed the type of key [[Editor Note. An alternative to this is to embed the type of key
exchange within the key exchange messages.]] exchange within the key exchange messages.]]
4.2. Key Exchange Protocol 4.2. Key Exchange Protocol
[[Editor note: This key exchange protocol is bidirectional, yet LSPs
are usually unidirectional. That means we need to establish a channel
for the return messages (similar to that in LSP Ping) or use a
different approach to Diffie-Hellman.]]
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 recipient (Bob). The D-H public value for Alice is g^i and for a recipient (Bob). The D-H public value for Alice is g^i and for
Bob, g^r. The shared Diffie-Hellman value is g^ir. Bob, g^r. The shared Diffie-Hellman value is g^ir.
g^ir is represented as a string of octets in big endian g^ir is represented as a string of octets in big endian
order padded with zeros if necessary to make it the length of the order padded with zeros if necessary to make it the length of the
modulus. modulus.
Both g^i and g^r will be 2048 bits long, if the Diffie-Hellman Both g^i and g^r will be 2048 bits long, if the Diffie-Hellman
modulus is 2048 bits long. modulus is 2048 bits long.
The key exchange payload is modelled on that from Section 3.4 of The key exchange payload is modelled on that from Section 3.4 of
[RFC5996], and is shown in Figure 7. [RFC5996], and is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Payload Length | algorithm | Group Num | |D| Payload Length | algorithm | Group Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ D-H Public value ~ ~ D-H Public value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Key Exchange Message Figure 6 - Key Exchange Message
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 Payload Length field contains the number of octets following the The Payload Length field contains the number of octets following the
payload length field (including the group number). This is 15 bits payload length field (including the group number). This is 15 bits
wide. wide.
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
skipping to change at page 18, line 24 skipping to change at page 18, line 14
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 [[Editor Note: maybe we should?]] Salt: Not used. [[Editor Note: maybe we should?]]
Skip: do not skip Skip: Do not skip.
Info: The catenation of a fixed string indicating use of MPLS OE, Info: The catenation of a fixed string indicating use of MPLS OE,
with the value "MPLS-OE", the first 32 bits of the key with the value "MPLS-OE", the first 32 bits of the key
exchange message, with the D flag set to 0, plus the LSP exchange message, with the D flag set to 0, plus the LSP
ID and the sender and receiver LSR IDs in that order. That ID and the sender and receiver LSR IDs in that order. That
is: is:
MPLS-OE||0||payloadLen||alg||group Num||LSP-ID||i-LSR-ID||r-LSR-ID MPLS-OE||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-OE" is used as an input here to prevent The fixed string "MPLS-OE" is used as an input here to prevent
potential cross-protocol attacks. Those might otherwise be potential cross-protocol attacks. Those might otherwise be
possible if this mechanism were to be copied in other protocols. possible if this mechanism were to be copied in other protocols.
(If copying this mechanism for any reason, then a different (If copying this mechanism for any reason, then a different
fixed string value should be used.) fixed string value should be used.)
The default encryption algorithm, AEAD_AES_GCM_128, specified LSP-ID is a unique identifier shared between the initiator and
in Section 3, requires a 128 bit session key. receiver (Alice and Bob) that uniquely identifies the LSP.
The 272-bit HKDF output is the catenation of the session key, the key [[Editor note: This identifier is only needed if the scope of the
id, the witness value and the high-order 16 bits of the initial nonce key is per LSP, but that seems a better scope given the need to
value in that order. That is the session key is rotate the key after a certain number of packets have been
the leftmost 128 bits of the HKDF output. The key-id is the next 16 transmitted.
bits, the witness value is the next 112 bits and the last 16 bits
are the 16 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 to the AES-GCM encryption function.
The key-id is prepended with four bits set to one and used as the Currently the LSP-ID is known along the LSP and at the two end points
label value in the OEL (see Section 3.2) so that the label does not if RSVP-TE is used for signaling, or potentially if the LSP is
take any of the values 0-15. manually configured. It is not so clear in LSPs established using
LDP. Probably, however, we can use the FEC as defined for RFC 4379
and its extensions.]]
[[Editor note - we might want to consider deriving the witness i-LSR-ID and r-LSR-ID are the LSR-IDs of the initiator and receiver
value from a separate invocation of the KDF that does not depend respectively, where an LSR-ID is the 32 bit, globally unique
on the LSP-specific inputs. The benefit from that would be identifier of the LSR as described in [RFC5036] and [RFC4990].
that the same MITM-detection infrastructure could be used for
many protocols. However, that would require standardizing a The default encryption algorithm, AEAD_AES_GCM_128, specified in
generic D-H MITM-detection protocol, or at least formats, in Section 3, requires a 128 bit session key.
order to be useful. We also need to consider what additional
information needs to be logged with the witness value so that The 272-bit HKDF output is the catenation of the session key, the
comparisons can easily be made at scale but without creating key-id, the witness value and the high-order 16 bits of the initial
new privacy-invasive meta-data. (That last is not much of an nonce value in that order. That is the session key is the leftmost
issue for MPLS-OE, but could be elsewhere.) At present we do 128 bits of the HKDF output. The key-id is the next 4 bits, the
not intend to go for the generic MITM-detection approach, but witness value is the next 124 bits and the last 16 bits are the 16
it is worth considering.]] 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 to the AES-GCM encryption function. The key-id is carried in
encrypted packets as described in Section 3.2.
[[Editor note - It is assumed 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 also be more than one algorithm, and it is
possible that new keys need to be pipelined if roll-over is
frequent.]]
[[Editor note - we might want to consider deriving the witness value
from a separate invocation of the KDF that does not depend on the
LSP-specific inputs. The benefit from that would be that the same
MITM-detection infrastructure could be used for many protocols.
However, that would require standardizing a generic D-H MITM-
detection protocol, or at least formats, in order to be useful. We
also need to consider what additional information needs to be logged
with the witness value so 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 MPLS-OE, but could be elsewhere.) At
present we do not intend to go for the generic MITM-detection
approach, but it is worth considering.]]
4.3. Protecting the Key Exchange Protocol Messages 4.3. Protecting the Key Exchange Protocol Messages
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 may
be subject to encryption exactly as any other packet. be subject to encryption exactly as any other packet.
5. Applicability of MPLS Opportunistic Encryption 5. Applicability of MPLS Opportunistic Encryption
skipping to change at page 22, line 32 skipping to change at page 22, line 39
and LSR IDs from time to time and a management application can and LSR IDs from time to time and a management application can
compare the values. If they are different for the same LSP ID, compare the values. If they are different for the same LSP ID,
then an active MITM attack has taken place. then an active 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.
[[Editor note - please see the note in 4.2 about generic [[Editor note - please see the note in 4.2 about generic MITM-
MITM-detection. Changes there could affect what needs to be detection. Changes there could affect what needs to be done here.]]
done here.]]
8. IANA Considerations 8. IANA Considerations
8.1. Opportunistic Encryption Label Indicator 8.1. Opportunistic Encryption Label Indicator
IANA maintains a registry called "Multiprotocol Label Switching IANA maintains a registry called "Multiprotocol Label Switching
Architecture (MPLS) Label Values" with a single sub-registry called Architecture (MPLS) Label Values" with a single sub-registry called
"Label Values". This registry is to be renamed "Special Purpose MPLS "Label Values". This registry is to be renamed "Special Purpose MPLS
Label Values according to [ID.ietf-mpls-special-purpose-labels]. Label Values according to [ID.ietf-mpls-special-purpose-labels].
IANA is requested to assign a value from this registry as follows: IANA is requested to assign a value from this registry as follows:
Value | Description | Reference Value | Description | Reference
------+-------------------------------------------------+----------- ------+-------------------------------------------------+-----------
TBD1 | Opportunistic Encryption Label Indicator (OELI) | [This.ID] TBD1 | Opportunistic Encryption Label (OEL) | [This.ID]
The value 8 is suggested. The value 8 is suggested.
[RFC Editor is requested to replace the string "TBD1" with the value [RFC Editor is requested to replace the string "TBD1" with the value
assigned by IANA throughout this document, and to remove this note.] assigned by IANA throughout this document, and to remove this note.]
8.2. Pseudowire Associated Channel Types 8.2. Pseudowire Associated Channel Types
IANA maintains a registry called "Pseudowire Name Spaces (PWE3)" with IANA maintains a registry called "Pseudowire Name Spaces (PWE3)" with
a sub-registry called "Pseudowire Associated Channel Types". IANA is a sub-registry called "Pseudowire Associated Channel Types". IANA is
requested to assign a value as follows: requested to assign a value as follows:
Value | Description | Reference Value | Description | Reference
------+-------------------------------------------------+----------- ------+-------------------------------------------------+-----------
TBD3 | Opportunistic Key Exchange Protocol for MPLS | [This.ID] TBD2 | Opportunistic Key Exchange Protocol for MPLS | [This.ID]
TBD2 | Opportunistically Encrypted MPLS | [This.ID]
The values 19 and 20 are suggested. It is suggested that TBD3 have The value 19 is suggested.
a value 1 smaller than TBD2.
[RFC Editor is requested to replace the string "TBD2" and "TBD3" with [RFC Editor is requested to replace the string "TBD2" with the values
the values assigned by IANA throughout this document, and to remove this assigned by IANA throughout this document, and to remove this note.]
note.]
8.3. Key Derivation Functions and Symmetric Algorithms 8.3. Key Derivation Functions and Symmetric Algorithms
IANA is requested to create a new MPLS registry called the "MPLS IANA is requested to create a new MPLS registry called the "MPLS
Opportunistic Encryption Algorithms Registry". New values are to Opportunistic Encryption Algorithms Registry". New values are to
be assigned through "IETF Review" as defined in [RFC5226]. be assigned through "IETF Review" as defined in [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
initial entry as follows: initial entry as follows:
Value | Key Derivation Function | Symmetric Algorithm | Reference Value | Key Derivation Function | Symmetric Algorithm | Reference
------+-------------------------+---------------------+----------- ------+-------------------------+---------------------+-----------
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
of MPLS opportunistic encryption. Thanks also to Ron Bonica for and mechanisms of MPLS opportunistic encryption. Thanks also to Ron
encouraging this work, to Sean Turner and Stewart Bryant for early Bonica for encouraging this work, to Sean Turner and Stewart Bryant
review, and to Jeff Haas and Ross Callon for discussions. for early review, and to Jeff Haas and Ross Callon for discussions.
Thanks to Andy Malis and Danny McPherson for advice about 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, March 1997.
[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
skipping to change at page 25, line 8 skipping to change at page 25, line 8
[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, January 2001.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
Addresses in Generalized Multiprotocol Label Switching
(GMPLS) Networks", RFC 4990, September 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Juniper Networks Juniper Networks
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
 End of changes. 74 change blocks. 
211 lines changed or deleted 218 lines changed or added

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