draft-ietf-mpls-ldp-hello-crypto-auth-04.txt   draft-ietf-mpls-ldp-hello-crypto-auth-05.txt 
Network Working Group L. Zheng Network Working Group L. Zheng
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: September 30, 2014 M. Bhatia Expires: November 5, 2014 M. Bhatia
Alcatel-Lucent Alcatel-Lucent
March 29, 2014 May 4, 2014
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
draft-ietf-mpls-ldp-hello-crypto-auth-04.txt draft-ietf-mpls-ldp-hello-crypto-auth-05.txt
Abstract Abstract
This document introduces a new optional Cryptographic Authentication This document introduces a new optional Cryptographic Authentication
TLV that LDP can use to secure its Hello messages. It secures the TLV that LDP can use to secure its Hello messages. It secures the
Hello messages against spoofing attacks and some well known attacks Hello messages against spoofing attacks and some well known attacks
against the IP header. This document describes a mechanism to secure against the IP header. This document describes a mechanism to secure
the LDP Hello messages using National Institute of Standards and the LDP Hello messages using National Institute of Standards and
Technology (NIST) Secure Hash Standard family of algorithms. Technology (NIST) Secure Hash Standard family of algorithms.
Requirements Language Requirements Language
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].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 30, 2014. This Internet-Draft will expire on November 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . . 6 2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
2.1. Optional Parameter for Hello Message . . . . . . . . . . . 6 2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
2.2. LDP Security Association . . . . . . . . . . . . . . . . . 6 2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 8 2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8
2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 9 3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 8
3. Cryptographic Authentication Procedure . . . . . . . . . . . . 10 5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . . 11 5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 10
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 12 6. Processing Hello Message Using Cryptographic Authentication . 10
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 12 6.1. Transmission Using Cryptographic Authentication . . . . . 10
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . . 13 6.2. Receipt Using Cryptographic Authentication . . . . . . . 11
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Processing Hello Message Using Cryptographic Authentication . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Transmission Using Cryptographic Authentication . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Receipt Using Cryptographic Authentication . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions
that run between LDP peers. The peers could either be directly that run between LDP peers. The peers could either be directly
connected at the link level or could be multiple hops away. An LDP connected at the link level or could be multiple hops away. An LDP
Label Switching Router (LSR) could either be configured with the Label Switching Router (LSR) could either be configured with the
identity of its peers or could discover them using LDP Hello identity of its peers or could discover them using LDP Hello
messages. These messages are sent encapsulated in UDP addressed to messages. These messages are sent encapsulated in UDP addressed to
"all routers on this subnet" or to a specific IP address. Periodic "all routers on this subnet" or to a specific IP address. Periodic
Hello messages are also used to maintain the relationship between LDP Hello messages are also used to maintain the relationship between LDP
peers necessary to keep the LDP session active. peers necessary to keep the LDP session active.
Since the Hello messages are sent using UDP and not TCP, these Since the Hello messages are sent using UDP and not TCP, these
messages cannot use the security mechanisms defined for TCP messages cannot use the security mechanisms defined for TCP
[RFC5926]. While some configuration guidance is given in [RFC5036] [RFC5926]. While some configuration guidance is given in [RFC5036]
to help protect against false discovery messages, it does not provide to help protect against false discovery messages, it does not provide
an explicit security mechanism to protect the Hello messages an explicit security mechanism to protect the Hello messages.
Spoofing a Hello packet for an existing adjacency can cause the valid Spoofing a Hello packet for an existing adjacency can cause the valid
adjacency to time out and in turn can result in termination of the adjacency to time out and in turn can result in termination of the
associated session. This can occur when the spoofed Hello specifies associated session. This can occur when the spoofed Hello specifies
a smaller Hold Time, causing the receiver to expect Hellos within a smaller Hold Time, causing the receiver to expect Hellos within
this smaller interval, while the true neighbor continues sending this smaller interval, while the true neighbor continues sending
Hellos at the previously agreed lower frequency. Spoofing a Hello Hellos at the previously agreed lower frequency. Spoofing a Hello
packet can also cause the LDP session to be terminated directly, packet can also cause the LDP session to be terminated directly,
which can occur when the spoofed Hello specifies a different which can occur when the spoofed Hello specifies a different
Transport Address, other than the previously agreed one between Transport Address, other than the previously agreed one between
neighbors. Spoofed Hello messages have been observed and reported as neighbors. Spoofed Hello messages have been observed and reported as
a real problem in production networks [RFC6952]. a real problem in production networks [RFC6952].
[RFC5036] states that the threat of spoofed Hellos can be reduced by For Link Hello, [RFC5036] states that the threat of spoofed Hellos
accepting Hellos only on interfaces to which LSRs that can be trusted can be reduced by accepting Hellos only on interfaces to which LSRs
are directly connected, and ignoring Hellos not addressed to the "all that can be trusted are directly connected, and ignoring Hellos not
routers on this subnet" multicast group. Spoofing attacks via addressed to the "all routers on this subnet" multicast group. The
Targeted Hellos are a potentially more serious threat. An LSR can Generalized TTL Security Mechanism (GTSM) provides a simple and
reduce the threat of spoofed Targeted Hellos by filtering them and reasonably robust defense mechanism for Link Hello [RFC6720], but it
accepting only those originating at sources permitted by an access does not secure against packet spoofing attack or replay
list. However, filtering using access lists requires LSR resource, attack[RFC5082].
and does not prevent IP-address spoofing.
Spoofing attacks via Targeted Hellos are a potentially more serious
threat. [RFC5036] states that an LSR can reduce the threat of
spoofed Targeted Hellos by filtering them and accepting only those
originating at sources permitted by an access list. However,
filtering using access lists requires LSR resource, and does not
prevent IP-address spoofing.
This document introduces a new Cryptographic Authentication TLV which This document introduces a new Cryptographic Authentication TLV which
is used in LDP Hello messages as an optional parameter. It enhances is used in LDP Hello messages as an optional parameter. It enhances
the authentication mechanism for LDP by securing the Hello message the authentication mechanism for LDP by securing the Hello message
against spoofing attack. It also introduces a cryptographic sequence against spoofing attack. It also introduces a cryptographic sequence
number carried in the Hello messages that can be used to protect number carried in the Hello messages that can be used to protect
against replay attacks. The LSRs could be configured to only accept against replay attacks. The LSRs could be configured to only accept
Hello messages from specific peers when authentication is in use. Hello messages from specific peers when authentication is in use.
Using this Cryptographic Authentication TLV, one or more secret keys Using this Cryptographic Authentication TLV, one or more secret keys
(with corresponding key IDs) are configured in each system. For each (with corresponding Security Association (SA) IDs) are configured in
LDP Hello message, the key is used to generate and verify a HMAC Hash each system. For each LDP Hello message, the key is used to generate
that is stored in the LDP Hello message. For cryptographic hash and verify a HMAC Hash that is stored in the LDP Hello message. For
function, this document proposes to use SHA-1, SHA-256, SHA-384, and cryptographic hash function, this document proposes to use SHA-1,
SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3]. SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard
The HMAC authentication mode defined in NIST FIPS 198 is used (SHS) [FIPS-180-3]. The HMAC authentication mode defined in NIST
[FIPS-198]. Of the above, implementations MUST include support for FIPS 198 is used [FIPS-198]. Of the above, implementations MUST
at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and include support for at least HMAC-SHA-256 and SHOULD include support
MAY include support for either of HMAC-SHA-384 or HMAC-SHA-512. for HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or
HMAC-SHA-512.
2. Cryptographic Authentication TLV 2. Cryptographic Authentication TLV
2.1. Optional Parameter for Hello Message 2.1. Optional Parameter for Hello Message
[RFC5036] defines the encoding for the Hello message. Each Hello [RFC5036] defines the encoding for the Hello message. Each Hello
message contains zero or more Optional Parameters, each encoded as a message contains zero or more Optional Parameters, each encoded as a
TLV. Three Optional Parameters are defined by [RFC5036]. This TLV. Three Optional Parameters are defined by [RFC5036]. This
document defines a new Optional Parameter: the Cryptographic document defines a new Optional Parameter: the Cryptographic
Authentication parameter. Authentication parameter.
Optional Parameter Type Optional Parameter Type
------------------------------- -------- ------------------------------- --------
IPv4 Transport Address 0x0401 (RFC5036) IPv4 Transport Address 0x0401 (RFC5036)
Configuration Sequence Number 0x0402 (RFC5036) Configuration Sequence Number 0x0402 (RFC5036)
IPv6 Transport Address 0x0403 (RFC5036) IPv6 Transport Address 0x0403 (RFC5036)
Cryptographic Authentication 0x0404 (this document, TBD by IANA) Cryptographic Authentication 0x0404 (this document, TBD1 by IANA)
The Cryptographic Authentication TLV Encoding is described in section The Cryptographic Authentication TLV Encoding is described in section
2.2. 2.3.
2.2. LDP Security Association 2.2. LDP Security Association
An LDP Security Association (SA) contains a set of parameters shared An LDP Security Association (SA) contains a set of parameters shared
between any two legitimate LDP speakers. between any two legitimate LDP speakers.
Parameters associated with an LDP SA are as follows: Parameters associated with an LDP SA are as follows:
o Security Association Identifier (SA ID) o Security Association Identifier (SA ID)
This is a 32-bit unsigned integer used to uniquely identify an LDP This is a 32-bit unsigned integer used to uniquely identify an LDP
SA, as manually configured by the network operator. SA between two LDP peers, as manually configured by the network
operator (or, in the future, possibly by some key management
protocol specified by the IETF) .
The receiver determines the active SA by looking at the SA ID The receiver determines the active SA by looking at the SA ID
field in the incoming Hello message. field in the incoming Hello message.
The sender, based on the active configuration, selects an SA to The sender, based on the active configuration, selects an SA to
use and puts the correct Key ID value associated with the SA in use and puts the correct SA ID value associated with the SA in the
the LDP Hello message. If multiple valid and active LDP SAs exist LDP Hello message. If multiple valid and active LDP SAs exist for
for a given interface, the sender may use any of those SAs to a given interface, the sender may use any of those SAs to protect
protect the packet. the packet.
Using SA IDs makes changing keys while maintaining protocol Using SA IDs makes changing keys while maintaining protocol
operation convenient. Each SA ID specifies two independent parts, operation convenient. Each SA ID specifies two independent parts,
the authentication algorithm and the authentication key, as the authentication algorithm and the authentication key, as
explained below. explained below.
Normally, an implementation would allow the network operator to Normally, an implementation would allow the network operator to
configure a set of keys in a key chain, with each key in the chain configure a set of keys in a key chain, with each key in the chain
having fixed lifetime. The actual operation of these mechanisms having fixed lifetime. The actual operation of these mechanisms
is outside the scope of this document. is outside the scope of this document.
skipping to change at page 7, line 33 skipping to change at page 5, line 42
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
o Authentication Key o Authentication Key
This value denotes the cryptographic authentication key associated This value denotes the cryptographic authentication key associated
with the LDP SA. The length of this key is variable and depends with the LDP SA. The length of this key is variable and depends
upon the authentication algorithm specified by the LDP SA. upon the authentication algorithm specified by the LDP SA.
o KeyStartAccept o KeyStartAccept
The time that this OSPFv3 router will accept packets that have The time that this LDP router will accept packets that have been
been created with this OSPFv3 Security Association. created with this LDP Security Association.
o KeyStartGenerate o KeyStartGenerate
The time that this LDP router will begin using this LDP Security The time that this LDP router will begin using this LDP Security
Association for LDP Hello message generation. Association for LDP Hello message generation.
o KeyStopGenerate o KeyStopGenerate
The time that this LDP router will stop using this LDP Security The time that this LDP router will stop using this LDP Security
Association for LDP Hello message generation. Association for LDP Hello message generation.
o KeyStopAccept o KeyStopAccept
The time that this LDP router will stop accepting packets The time that this LDP router will stop accepting packets
generated with this LDP Security Association. generated with this LDP Security Association.
In order to achieve smooth key transition, KeyStartAccept SHOULD be In order to achieve smooth key transition, KeyStartAccept SHOULD be
less than KeyStartGenerate and KeyStopGenerate SHOULD be less than less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
skipping to change at page 8, line 24 skipping to change at page 6, line 33
avoid operational issues. In the event that the last key associated avoid operational issues. In the event that the last key associated
with an interface expires, it is unacceptable to revert to an with an interface expires, it is unacceptable to revert to an
unauthenticated condition, and not advisable to disrupt routing. unauthenticated condition, and not advisable to disrupt routing.
Therefore, the router SHOULD send a "last Authentication Key Therefore, the router SHOULD send a "last Authentication Key
expiration" notification to the network manager and treat the key as expiration" notification to the network manager and treat the key as
having an infinite lifetime until the lifetime is extended, the key having an infinite lifetime until the lifetime is extended, the key
is deleted by network management, or a new key is configured is deleted by network management, or a new key is configured
2.3. Cryptographic Authentication TLV Encoding 2.3. Cryptographic Authentication TLV Encoding
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| Auth (TBD) | Length | |0|0| Auth (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID | | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High Order 32 Bits) | | Cryptographic Sequence Number (High Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low Order 32 Bits) | | Cryptographic Sequence Number (Low Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Authentication Data (Variable) | | Authentication Data (Variable) |
~ ~ ~ ~
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: TBD, Cryptographic Authentication
- Type: TBD1, Cryptographic Authentication
- Length: Specifying the length in octets of the value field. - Length: Specifying the length in octets of the value field.
- Security Association ID: 32 bit field that maps to the - Security Association ID: 32 bit field that maps to the
authentication algorithm and the secret key used to create the authentication algorithm and the secret key used to create the
message digest carried in LDP payload. message digest carried in LDP payload.
Though the SA ID implies the algorithm, the HMAC output size should Though the SA ID implies the algorithm, the HMAC output size should
not be used by implementers as an implicit hint, because additional not be used by implementers as an implicit hint, because additional
algorithms may be defined in the future that have the same output algorithms may be defined in the future that have the same output
size. size.
skipping to change at page 9, line 44 skipping to change at page 8, line 9
--------------- ---------- --------------- ----------
HMAC-SHA1 20 bytes HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes HMAC-SHA-512 64 bytes
2.4. Sequence Number Wrap 2.4. Sequence Number Wrap
When incrementing the sequence number for each transmitted LDP When incrementing the sequence number for each transmitted LDP
packet, the sequence number should be treated as an unsigned 64-bit packet, the sequence number should be treated as an unsigned 64-bit
value. If the lower order 32-bit value wraps, the higher order 32- value. If the lower order 32-bit value wraps, the higher order
bit value should be incremented and saved in non-volatile storage. 32-bit value should be incremented and saved in non-volatile storage.
If the LDP router is deployed long enough that the 64-bit sequence If the LDP router is deployed long enough that the 64-bit sequence
number wraps, all keys, independent of key distribution mechanism number wraps, all keys, independent of key distribution mechanism
MUST be reset. This is done to avoid the possibility of replay MUST be reset. This is done to avoid the possibility of replay
attacks. Once the keys have been changed, the higher order sequence attacks. Once the keys have been changed, the higher order sequence
number can be reset to 0 and saved to non-volatile storage. number can be reset to 0 and saved to non-volatile storage.
3. Cryptographic Authentication Procedure 3. Cryptographic Authentication Procedure
As noted earlier, the Security Association ID maps to the As noted earlier, the Security Association ID maps to the
authentication algorithm and the secret key used to generate and authentication algorithm and the secret key used to generate and
skipping to change at page 11, line 9 skipping to change at page 8, line 43
HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC- HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC-
SHA-512. SHA-512.
Implementations of this standard MUST use HMAC-SHA-256 as the default Implementations of this standard MUST use HMAC-SHA-256 as the default
authentication algorithm. authentication algorithm.
4. Cross Protocol Attack Mitigation 4. Cross Protocol Attack Mitigation
In order to prevent cross protocol replay attacks for protocols In order to prevent cross protocol replay attacks for protocols
sharing common keys, the two octet LDP Cryptographic Protocol ID is sharing common keys, the two octet LDP Cryptographic Protocol ID is
appended to the authentication key prior to use. Other protocols appended to the authentication key prior to use (refer to Section 8).
using cryptographic authentication as specified herein MUST similarly Other protocols using the common key similarly append their own
append their respective Cryptographic Protocol IDs to their keys in Cryptographic Protocol IDs to their keys prior to use thus ensuring
this step. Refer to IANA Considerations (Section 8). that a different key value is used for each protocol.
5. Cryptographic Aspects 5. Cryptographic Aspects
In the algorithm description below, the following nomenclature, which In the algorithm description below, the following nomenclature, which
is consistent with [FIPS-198], is used: is consistent with [FIPS-198], is used:
H is the specific hashing algorithm (e.g. SHA-256). H is the specific hashing algorithm (e.g. SHA-256).
K is the Authentication Key from the LDP security association. K is the Authentication Key from the LDP security association.
Ks is a Protocol Specific Authentication Key obtained by appending Ks is a Protocol Specific Authentication Key obtained by appending
Authentication Key (K) with the two-octet LDP Cryptographic Protocol Authentication Key (K) with the two-octet LDP Cryptographic Protocol
ID appended. ID appended.
Ko is the cryptographic key used with the hash algorithm. Ko is the cryptographic key used with the hash algorithm.
B is the block size of H, measured in octets rather than bits. B is the block size of H, measured in octets rather than bits.
skipping to change at page 14, line 31 skipping to change at page 11, line 15
6.2. Receipt Using Cryptographic Authentication 6.2. Receipt Using Cryptographic Authentication
The receiving LSR applies acceptability criteria for received Hellos The receiving LSR applies acceptability criteria for received Hellos
using cryptographic authentication. If the Cryptographic using cryptographic authentication. If the Cryptographic
Authentication TLV is unknown to the receiving LSR, the received Authentication TLV is unknown to the receiving LSR, the received
packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036]. packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036].
The receiving LSR locates the LDP SA using the Security Association The receiving LSR locates the LDP SA using the Security Association
ID field carried in the message. If the SA is not found, or if the ID field carried in the message. If the SA is not found, or if the
SA is not valid for reception (i.e., current time < KeyStartAccept or SA is not valid for reception (i.e., current time < KeyStartAccept or
current time >= KeyStopAccept), LDP Hello message MUST be discarded. current time >= KeyStopAccept), LDP Hello message MUST be discarded,
and an error event SHOULD be logged.
If the cryptographic sequence number in the LDP packet is less than If the cryptographic sequence number in the LDP packet is less than
or equal to the last sequence number received from the same neighbor, or equal to the last sequence number received from the same neighbor,
the LDP message MUST be discarded, and an error event SHOULD be the LDP message MUST be discarded, and an error event SHOULD be
logged. logged.
Before the receiving LSR performs any processing, it needs to save Before the receiving LSR performs any processing, it needs to save
the values of the Authentication Data field. The receiving LSR then the values of the Authentication Data field. The receiving LSR then
replaces the contents of the Authentication Data field with Apad, replaces the contents of the Authentication Data field with Apad,
computes the Hash, using the authentication key specified by the computes the Hash, using the authentication key specified by the
received Security Association ID field, as explained in Section 3. received Security Association ID field, as explained in Section 3.
If the locally computed Hash is equal to the received value of the If the locally computed Hash is equal to the received value of the
Authentication Data field, the received packet is accepted for other Authentication Data field, the received packet is accepted for other
normal checks and processing as described in [RFC5036]. Otherwise, normal checks and processing as described in [RFC5036]. Otherwise,
if the locally computed Hash is not equal to the received value of if the locally computed Hash is not equal to the received value of
the Authentication Data field, the received packet MUST be discarded, the Authentication Data field, the received packet MUST be discarded,
and an error event SHOULD be logged. and an error event SHOULD be logged. The foresaid logging need to be
carefully rate limited, since while a LDP router is under attack of a
storm of spoofed hellos, the resource taking for logging could be
overwelming.
After the LDP Hello message has been successfully authenticated, After the LDP Hello message has been successfully authenticated,
implementations MUST store the 64-bit cryptographic sequence number implementations MUST store the 64-bit cryptographic sequence number
for the Hello message received from the neighbor. The saved for the Hello message received from the neighbor. The saved
cryptographic sequence numbers will be used for replay checking for cryptographic sequence numbers will be used for replay checking for
subsequent packets received from the neighbor. subsequent packets received from the neighbor.
7. Security Considerations 7. Security Considerations
Section 1 of this document describes the security issues arising from Section 1 of this document describes the security issues arising from
skipping to change at page 17, line 13 skipping to change at page 12, line 38
deployment, or operational complexity. deployment, or operational complexity.
8. IANA Considerations 8. IANA Considerations
The IANA is requested to as assign a new TLV from the "Multiprotocol The IANA is requested to as assign a new TLV from the "Multiprotocol
Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry. Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry.
Value Meaning Reference Value Meaning Reference
----- -------------------------------- --------- ----- -------------------------------- ---------
TBD Cryptographic Authentication TLV this document (sect 3.2) TBD1 Cryptographic Authentication TLV this document (sect 2.3)
The IANA is also requested to as assign value from the The IANA is also requested to as assign value from the
"Authentication Cryptographic Protocol ID", registry under the "Authentication Cryptographic Protocol ID", registry under the
"Keying and Authentication for Routing Protocols (KARP) Parameters" "Keying and Authentication for Routing Protocols (KARP) Parameters"
category. category.
Value Meaning Reference Value Meaning Reference
----- -------------------------------- --------- ----- -------------------------------- ---------
TBD LDP Cryptographic Protocol ID this document (sect 4) TBD2 LDP Cryptographic Protocol ID this document (sect 4)
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Liu Xuehu for his work on background The authors would like to thank Liu Xuehu for his work on background
and motivation for LDP Hello authentication. The authors also would and motivation for LDP Hello authentication. The authors also would
like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray, like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray,
Kamran Raza and Acee Lindem for their valuable comments. Kamran Raza and Acee Lindem for their valuable comments.
We would also like to thank the authors of RFC 5709 and RFC 7166 from We would also like to thank the authors of RFC 5709 and RFC 7166 from
where we have taken most of the cryptographic computation procedures where we have taken most of the cryptographic computation procedures
from. from.
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS-180-3] [FIPS-180-3]
"Secure Hash Standard (SHS), FIPS PUB 180-3", "Secure Hash Standard (SHS), FIPS PUB 180-3", October
October 2008. 2008.
[FIPS-198] [FIPS-198]
"The Keyed-Hash Message Authentication Code (HMAC), FIPS "The Keyed-Hash Message Authentication Code (HMAC), FIPS
PUB 198", March 2002. PUB 198", March 2002.
[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.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007. Authentication", RFC 4822, February 2007.
skipping to change at page 19, line 40 skipping to change at page 13, line 51
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009. Authentication", RFC 5709, October 2009.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, March 2014. Authentication Trailer for OSPFv3", RFC 7166, March 2014.
10.2. Informative References 10.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104, February
February 1997. 1997.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926, for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010. June 2010.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013. Guide", RFC 6952, May 2013.
Authors' Addresses Authors' Addresses
Lianshu Zheng Lianshu Zheng
Huawei Technologies Huawei Technologies
China China
 End of changes. 27 change blocks. 
100 lines changed or deleted 109 lines changed or added

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