draft-ietf-mpls-ldp-hello-crypto-auth-10.txt   rfc7349.txt 
Network Working Group L. Zheng Internet Engineering Task Force (IETF) L. Zheng
Internet-Draft M. Chen Request for Comments: 7349 M. Chen
Intended status: Standards Track Huawei Technologies Category: Standards Track Huawei Technologies
Expires: December 21, 2014 M. Bhatia ISSN: 2070-1721 M. Bhatia
Ionos Networks Ionos Networks
June 19, 2014 August 2014
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
draft-ietf-mpls-ldp-hello-crypto-auth-10.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 Hashed Message Authentication Code the LDP Hello messages using Hashed Message Authentication Code
(HMAC) with National Institute of Standards and Technology (NIST) (HMAC) with the National Institute of Standards and Technology (NIST)
Secure Hash Standard family of algorithms. Secure Hash Standard family of algorithms.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 21, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7349.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4 2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
2.1. Optional Parameter for Hello Message . . . . . . . . . . 4 2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
2.2. LDP Security Association . . . . . . . . . . . . . . . . 4 2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6 2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8 2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 7
3. Cryptographic Authentication Procedure . . . . . . . . . . . 8 3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 9 4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . . 8
5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 9 5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9 5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 10 5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Processing Hello Message Using Cryptographic Authentication . 10 6. Processing Hello Message Using Cryptographic Authentication . 10
6.1. Transmission Using Cryptographic Authentication . . . . . 10 6.1. Transmission Using Cryptographic Authentication . . . . . 10
6.2. Receipt Using Cryptographic Authentication . . . . . . . 11 6.2. Receipt Using Cryptographic Authentication . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . 12 7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 be multiple hops away. An LDP Label
Label Switching Router (LSR) could either be configured with the Switching Router (LSR) could either be configured with the identity
identity of its peers or could discover them using LDP Hello of its peers or could discover them using LDP Hello messages. These
messages. These messages are sent encapsulated in UDP addressed to messages are sent encapsulated in UDP addressed to "all routers on
"all routers on this subnet" or to a specific IP address. Periodic this subnet" or to a specific IP address. Periodic Hello messages
Hello messages are also used to maintain the relationship between LDP are also used to maintain the relationship between LDP peers
peers necessary to keep the LDP session active. 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 message for an existing adjacency can cause the Spoofing a Hello message for an existing adjacency can cause the
valid adjacency to time out and in turn can result in termination of valid adjacency to time out and in turn can result in termination of
the associated session. This can occur when the spoofed Hello the associated session. This can occur when the spoofed Hello
skipping to change at page 3, line 29 skipping to change at page 3, line 14
within this smaller interval, while the true neighbor continues within this smaller interval, while the true neighbor continues
sending Hellos at the previously agreed lower frequency. Spoofing a sending Hellos at the previously agreed lower frequency. Spoofing a
Hello message can also cause the LDP session to be terminated Hello message can also cause the LDP session to be terminated
directly, which can occur when the spoofed Hello specifies a directly, which can occur when the spoofed Hello specifies a
different Transport Address, other than the previously agreed one different Transport Address, other than the previously agreed one
between neighbors. Spoofed Hello messages have been observed and between neighbors. Spoofed Hello messages have been observed and
reported as a real problem in production networks [RFC6952]. reported as a real problem in production networks [RFC6952].
For Link Hello, [RFC5036] states that the threat of spoofed Hellos For Link Hello, [RFC5036] states that the threat of spoofed Hellos
can be reduced by accepting Hellos only on interfaces to which LSRs can be reduced by accepting Hellos only on interfaces to which LSRs
that can be trusted are directly connected, and ignoring Hellos not that can be trusted are directly connected and ignoring Hellos not
addressed to the "all routers on this subnet" multicast group. The addressed to the "all routers on this subnet" multicast group. The
Generalized TTL Security Mechanism (GTSM) provides a simple and Generalized TTL Security Mechanism (GTSM) provides a simple and
reasonably robust defense mechanism for Link Hello [RFC6720], but it reasonably robust defense mechanism for Link Hello [RFC6720], but it
does not secure against packet spoofing attack or replay does not secure against packet spoofing attacks or replay attacks
attack[RFC5082]. [RFC5082].
Spoofing attacks via Targeted Hellos are a potentially more serious Spoofing attacks via Targeted Hellos are a potentially more serious
threat. [RFC5036] states that an LSR can reduce the threat of threat. [RFC5036] states that an LSR can reduce the threat of
spoofed Targeted Hellos by filtering them and accepting only those spoofed Targeted Hellos by filtering them and accepting only those
originating at sources permitted by an access list. However, originating at sources permitted by an access list. However,
filtering using access lists requires LSR resource, and does not filtering using access lists requires LSR resources and does not
prevent IP-address spoofing. prevent IP-address spoofing.
This document introduces a new Cryptographic Authentication TLV which This document introduces a new Cryptographic Authentication TLV that
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 attacks. It also introduces a cryptographic
number carried in the Hello messages that can be used to protect sequence number carried in the Hello messages that can be used to
against replay attacks. protect against replay attacks.
Using this Cryptographic Authentication TLV, one or more secret keys Using this Cryptographic Authentication TLV, one or more secret keys
(with corresponding Security Association (SA) IDs) are configured in (with corresponding Security Association (SA) IDs) are configured in
each system. For each LDP Hello message, the key is used to generate each system. For each LDP Hello message, the key is used to generate
and verify a HMAC Hash that is stored in the LDP Hello message. For and verify an HMAC Hash that is stored in the LDP Hello message. For
cryptographic hash function, this document proposes to use SHA-1, the cryptographic hash function, this document proposes to use SHA-1,
SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard
(SHS) [FIPS-180-3]. The HMAC authentication mode defined in (SHS) [FIPS-180-4]. The HMAC authentication mode defined in
[RFC2104] is used. Of the above, implementations MUST include [RFC2104] is used. Of the above, implementations MUST include
support for at least HMAC-SHA-256 and SHOULD include support for support for at least HMAC-SHA-256, SHOULD include support for HMAC-
HMAC-SHA-1 and MAY include support for HMAC-SHA-384 and HMAC-SHA-512. SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. 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 (RFC 5036)
Configuration Sequence Number 0x0402 (RFC5036) Configuration Sequence Number 0x0402 (RFC 5036)
IPv6 Transport Address 0x0403 (RFC5036) IPv6 Transport Address 0x0403 (RFC 5036)
Cryptographic Authentication TBD1 (this document, TBD1 by IANA) Cryptographic Authentication TLV 0x0405 (this document)
The Cryptographic Authentication TLV Encoding is described in section The encoding for the Cryptographic Authentication TLV is described in
2.3. Section 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 between two LDP peers, as manually configured by the network SA between two LDP peers, as manually configured by the network
operator (or, possibly by some key management protocol specified operator (or, possibly by some key management protocol specified
by the IETF in the future) . by the IETF in the future).
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 SA ID value associated with the SA in the use and puts the correct SA ID value associated with the SA in the
LDP Hello message. If multiple valid and active LDP SAs exist for LDP Hello message. If multiple valid and active LDP SAs exist for
a given interface, the sender may use any of those SAs to protect a given interface, the sender may use any of those SAs to 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 a fixed lifetime. The actual operation of these mechanisms
is outside the scope of this document. is outside the scope of this document.
Note that each SA ID can indicate a key with a different Note that each SA ID can indicate a key with a different
authentication algorithm. This allows the introduction of new authentication algorithm. This allows the introduction of new
authentication mechanisms without disrupting existing LDP authentication mechanisms without disrupting existing LDP
sessions. sessions.
o Authentication Algorithm o Authentication Algorithm
This signifies the authentication algorithm to be used with the This signifies the authentication algorithm to be used with the
LDP SA. This information is never sent in clear text over the LDP SA. This information is never sent in clear text over the
wire. Because this information is not sent on the wire, the wire. Because this information is not sent on the wire, the
implementer chooses an implementation specific representation for implementer chooses an implementation-specific representation for
this information. this information.
Currently, the following algorithms are supported: Currently, the following algorithms are supported:
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
skipping to change at page 6, line 16 skipping to change at page 6, line 6
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
KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left
unspecified, the time will default to 0 and the key will be used unspecified, the time will default to 0, and the key will be used
immediately. If KeyStopGenerate or KeyStopAccept are left immediately. If KeyStopGenerate or KeyStopAccept are left
unspecified, the time will default to infinity and the key's lifetime unspecified, the time will default to infinity, and the key's
will be infinite. When a new key replaces an old, the lifetime will be infinite. When a new key replaces an old, the
KeyStartGenerate time for the new key MUST be less than or equal to KeyStartGenerate time for the new key MUST be less than or equal to
the KeyStopGenerate time of the old key. Any unspecified values are the KeyStopGenerate time of the old key. Any unspecified values are
encoded as Zero. encoded as zero.
Key storage SHOULD persist across a system restart, warm or cold, to Key storage SHOULD persist across a system restart, warm or cold, to
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 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 (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: TBD1, Cryptographic Authentication 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
- Length: Specifying the length in octets of the value field, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
including the Security Association ID and Cryptographic Sequence |0|0| Auth (0x0405) | Length |
Number fields. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Security Association ID: 32 bit field that maps to the o Type: 0x0405, Cryptographic Authentication
authentication algorithm and the secret key used to create the
message digest carried in LDP payload.
Though the SA ID implies the algorithm, the HMAC output size should o Length: The length in octets of the value field, including the
not be used by implementers as an implicit hint, because additional Security Association ID and Cryptographic Sequence Number fields.
algorithms may be defined in the future that have the same output
size.
- Cryptographic Sequence Number: 64-bit strictly increasing sequence o Security Association ID: The 32-bit field that maps to the
number that is used to guard against replay attacks. The 64-bit authentication algorithm and the secret key used to create the
sequence number MUST be incremented for every LDP Hello message sent message digest carried in LDP payload.
by the LDP router. Upon reception, the sequence number MUST be
greater than the sequence number in the last LDP Hello message
accepted from the sending LDP neighbor. Otherwise, the LDP message
is considered a replayed packet and dropped. The Cryptographic
Sequence Number is a single space per LDP router.
LDP routers implementing this specification MUST use existing Though the SA ID implies the algorithm, the HMAC output size
mechanisms to preserve the sequence number's strictly increasing should not be used by implementers as an implicit hint because
property for the deployed life of the LDP router (including cold additional algorithms may be defined in the future that have the
restarts). One mechanism for accomplishing this could be to use the same output size.
high-order 32 bits of the sequence number as a boot count that is
incremented anytime the LDP router loses its sequence number state.
Techniques such as sequence number space partitioning described above o Cryptographic Sequence Number: The 64-bit, strictly increasing
or non-volatile storage preservation can be used but are beyond the sequence number that is used to guard against replay attacks. The
scope of this specification. Sequence number wrap is described in 64-bit sequence number MUST be incremented for every LDP Hello
Section 2.4. message sent by the LDP router. Upon reception, the sequence
number MUST be greater than the sequence number in the last LDP
Hello message accepted from the sending LDP neighbor. Otherwise,
the LDP message is considered a replayed packet and is dropped.
The Cryptographic Sequence Number is a single space per LDP
router.
- Authentication Data: LDP routers implementing this specification MUST use existing
mechanisms to preserve the sequence number's strictly increasing
property for the deployed life of the LDP router (including cold
restarts). One mechanism for accomplishing this could be to use
the high-order 32 bits of the sequence number as a boot count that
is incremented anytime the LDP router loses its sequence number
state. Techniques such as sequence number space partitioning
described above or non-volatile storage preservation can be used
but are beyond the scope of this specification. Sequence number
wrap is described in Section 2.4.
This field carries the digest computed by the Cryptographic o Authentication Data: This field carries the digest computed by the
Authentication algorithm in use. The length of the Authentication Cryptographic Authentication algorithm in use. The length of the
Data varies based on the cryptographic algorithm in use, which is Authentication Data varies based on the cryptographic algorithm in
shown as below: use, which is shown below:
Auth type Length Auth type Length
--------------- ---------- --------------- ----------
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
message, the sequence number should be treated as an unsigned 64-bit message, the sequence number should be treated as an unsigned 64-bit
value. If the lower order 32-bit value wraps, the higher order value. If the lower-order 32-bit value wraps, the higher-order
32-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 the key distribution
MUST be reset. This is done to avoid the possibility of replay mechanism, MUST be reset. This is done to avoid the possibility of
attacks. Once the keys have been changed, the higher order sequence replay attacks. Once the keys have been changed, the higher-order
number can be reset to 0 and saved to non-volatile storage. sequence 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
verify the message digest. This specification discusses the verify the message digest. This specification discusses the
computation of LDP Cryptographic Authentication data when any of the computation of LDP Cryptographic Authentication data when any of the
NIST SHS family of algorithms is used in the Hashed Message NIST SHS family of algorithms is used in the Hashed Message
Authentication Code (HMAC) mode. Authentication Code (HMAC) mode.
The currently valid algorithms (including mode) for LDP Cryptographic The currently valid algorithms (including mode) for LDP Cryptographic
Authentication include: Authentication include:
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
Of the above, implementations of this specification MUST include Of the above, implementations of this specification MUST include
support for at least HMAC-SHA-256 and SHOULD include support for support for at least HMAC-SHA-256, SHOULD include support for HMAC-
HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC- SHA-1, and MAY also include support for HMAC-SHA-384 and HMAC-SHA-
SHA-512. 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 2-octet LDP Cryptographic Protocol ID is
appended to the authentication key prior to use (refer to Section 8). appended to the authentication key prior to use (refer to Section 8).
Other protocols using the common key similarly append their own Other protocols using the common key similarly append their own
Cryptographic Protocol IDs to their keys prior to use thus ensuring Cryptographic Protocol IDs to their keys prior to use, thus ensuring
that a different key value is used for each protocol. that a different key value is used for each protocol.
5. Cryptographic Aspects 5. Cryptographic Aspects
In the algorithm description below, the following nomenclature is In the algorithm description below, the following nomenclature is
used: used:
H is the specific hashing algorithm (e.g. SHA-256). o H is the specific hashing algorithm (e.g., SHA-256).
K is the Authentication Key from the LDP security association. o K is the Authentication Key from the LDP Security Association.
Ks is a Protocol Specific Authentication Key obtained by appending o 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 2-octet LDP Cryptographic Protocol
ID . ID.
Ko is the cryptographic key used with the hash algorithm. o Ko is the cryptographic key used with the hash algorithm.
L is the length of the hash, measured in octets rather than bits. o L is the length of the hash, measured in octets rather than bits.
AuthTag is a value which is the same length as the hash output. In o AuthTag is a value that is the same length as the hash output. In
case of IPv4, the first 4 octets contain the IPv4 source address the case of IPv4, the first 4 octets contain the IPv4 source
followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. address followed by the hexadecimal value 0x878FE1F3 repeated
In case of IPv6, the first 16 octets contain the IPv6 source address (L-4)/4 times. In the case of IPv6, the first 16 octets contain
followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. the IPv6 source address followed by the hexadecimal value
This implies that hash output is always a length of at least 16 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output
octets. is always a length of at least 16 octets.
5.1. Preparing the Cryptographic Key 5.1. Preparing the Cryptographic Key
The LDP Cryptographic Protocol ID is appended to the Authentication The LDP Cryptographic Protocol ID is appended to the Authentication
Key (K) yielding a Protocol Specific Authentication Key (Ks). In Key (K) yielding a Protocol-Specific Authentication Key (Ks). In
this application, Ko is always L octets long. Keys that are longer this application, Ko is always L octets long. Keys that are longer
than the bit length of the hash function are hashed to force them to than the bit length of the hash function are hashed to force them to
this length, as we describe below. Ks is computed as follows: this length, as we describe below. Ks is computed as follows.
If the Protocol Specific Authentication Key (Ks) is L octets long, If the Protocol-Specific Authentication Key (Ks) is L octets long,
then Ko is equal to Ks. If the Protocol Specific Authentication Key then Ko is equal to Ks. If the Protocol-Specific Authentication Key
(Ks) is more than L octets long, then Ko is set to H(Ks). If the (Ks) is more than L octets long, then Ko is set to H(Ks). If the
Protocol Specific Authentication Key (Ks) is less than L octets long, Protocol-Specific Authentication Key (Ks) is less than L octets long,
then Ko is set to the Protocol Specific Authentication Key (Ks) with then Ko is set to the Protocol-Specific Authentication Key (Ks) with
zeros appended to the end of the Protocol Specific Authentication Key zeros appended to the end of the Protocol-Specific Authentication Key
(Ks) such that Ko is L octets long. (Ks) such that Ko is L octets long.
For higher entropy it is RECOMMENDED that Key Ks should be at least L For higher entropy, it is RECOMMENDED that Key Ks should be at least
octets long. L octets long.
5.2. Computing the Hash 5.2. Computing the Hash
First, the Authentication Data field in the Cryptographic First, the Authentication Data field in the Cryptographic
Authentication TLV is filled with the value AuthTag. Then, to Authentication TLV is filled with the value AuthTag. Then, to
compute HMAC over the Hello message it performs: compute HMAC over the Hello message it performs:
AuthData = HMAC(Ko, Hello Message) AuthData = HMAC(Ko, Hello Message)
Hello Message refers to the LDP Hello message excluding the IP and Hello Message refers to the LDP Hello message excluding the IP and
skipping to change at page 10, line 46 skipping to change at page 10, line 24
sizes will also increase the size of the LDP message as transmitted sizes will also increase the size of the LDP message as transmitted
on the wire. on the wire.
6. Processing Hello Message Using Cryptographic Authentication 6. Processing Hello Message Using Cryptographic Authentication
6.1. Transmission Using Cryptographic Authentication 6.1. Transmission Using Cryptographic Authentication
Prior to transmitting the LDP Hello message, the Length in the Prior to transmitting the LDP Hello message, the Length in the
Cryptographic Authentication TLV header is set as per the Cryptographic Authentication TLV header is set as per the
authentication algorithm that is being used. It is set to 24 for authentication algorithm that is being used. It is set to 24 for
HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384 and 68 for HMAC- HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384, and 68 for
SHA-512. HMAC-SHA-512.
The Security Association ID field is set to the ID of the current The Security Association ID field is set to the ID of the current
authentication key. The HMAC Hash is computed as explained in authentication key. The HMAC Hash is computed as explained in
Section 3. The resulting Hash is stored in the Authentication Data Section 5. The resulting Hash is stored in the Authentication Data
field prior to transmission. The authentication key MUST NOT be field prior to transmission. The authentication key MUST NOT be
carried in the packet. carried in the packet.
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 router MUST determine whether to accept a Hello Message The receiving router MUST determine whether or not to accept a Hello
from a particular source IP address as follows. First, if the router message from a particular source IP address as follows. First, if
has, for that source IP address, a stored LDP Hello cryptographic the router has, for that source IP address, a stored LDP Hello
sequence number, or is configured to require LDP Hello cryptographic sequence number or is configured to require LDP Hello
authentication, then the router MUST discard any unauthenticated authentication, then the router MUST discard any unauthenticated
Hello packets. As specified later in this section, a cryptographic Hello packets. As specified later in this section, a cryptographic
sequence number is only stored for a source IP address as a result of sequence number is only stored for a source IP address as a result of
receiving a valid authenticated Hello. receiving a valid authenticated Hello.
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
SA is not valid for reception (i.e., current time < KeyStartAccept or is not valid for reception (i.e., current time < KeyStartAccept or
current time >= KeyStopAccept), LDP Hello message MUST be discarded, current time >= KeyStopAccept), the LDP Hello message MUST be
and an error event SHOULD be logged. discarded, and an error event SHOULD be logged.
If the cryptographic sequence number in the LDP Hello message is less If the cryptographic sequence number in the LDP Hello message is less
than or equal to the last sequence number received from the same than or equal to the last sequence number received from the same
neighbor, the LDP Hello message MUST be discarded, and an error event neighbor, the LDP Hello message MUST be discarded, and an error event
SHOULD be logged. SHOULD be 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 AuthTag, replaces the contents of the Authentication Data field with AuthTag
computes the Hash, using the authentication key specified by the and 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 LDP Hello message MUST be the Authentication Data field, the received LDP Hello message MUST be
discarded, and an error event SHOULD be logged. The foresaid logging discarded, and an error event SHOULD be logged. The aforesaid
need to be carefully rate limited, since while a LDP router is under logging needs to be carefully rate limited, because while a LDP
attack of a storm of spoofed hellos, the resource taking for logging router is under attack by a storm of spoofed Hellos, the resources
could be overwelming. required for logging could be overwhelming.
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 LDP Hello message received from the source IP address. The for the LDP Hello message received from the source IP address. The
saved cryptographic sequence numbers will be used for replay checking saved cryptographic sequence numbers will be used for replay checking
for subsequent packets received from the source IP address. for subsequent packets received from the source IP address.
7. Operational Considerations 7. Operational Considerations
Careful consideration must be given to when and how to enable and Careful consideration must be given to when and how to enable and
disable authentication on LDP Hellos. On the one hand, it is disable authentication on LDP Hellos. On the one hand, it is
critical that an attack cannot cause the authentication to be critical that an attack cannot cause the authentication to be
disabled. On the other hand, it is equally important that an disabled. On the other hand, it is equally important that an
operator can change the hardware and/or software associated with a operator can change the hardware and/or software associated with a
neighbor's IP address and successfully bring up an LDP adjacency with neighbor's IP address and successfully bring up an LDP adjacency with
the desired level of authentication, which may be with different or the desired level of authentication, which may be with different or
no authentication due to software restrictions. no authentication due to software restrictions.
LDP Hello authentication information (e.g. whether authentication is LDP Hello authentication information (e.g., whether authentication is
enabled and what the last cryptographic sequence number is) enabled and what the last cryptographic sequence number is)
associated with an IP address is learned via a set of interfaces. If associated with an IP address is learned via a set of interfaces. If
an interface is administratively disabled, the LDP Hello an interface is administratively disabled, the LDP Hello
authentication information learned via that interface MAY be authentication information learned via that interface MAY be
forgotten. This enables an operator that is not specifically forgotten. This enables an operator that is not specifically
manipulating LDP Hello authentication configurations to easily bring manipulating LDP Hello authentication configurations to easily bring
up an LDP adjacency. An implementation of this standard SHOULD up an LDP adjacency. An implementation of this standard SHOULD
provide a configuration mechanism by which the LDP Hello provide a configuration mechanism by which the LDP Hello
authentication information associated with an IP address can be shown authentication information associated with an IP address can be shown
and can be forgotten; configuration mechanisms are assumed to be and can be forgotten; configuration mechanisms are assumed to be
skipping to change at page 12, line 49 skipping to change at page 12, line 30
Authentication TLV depends completely on the strength of the Authentication TLV depends completely on the strength of the
cryptographic algorithm in use, the strength of the key being used, cryptographic algorithm in use, the strength of the key being used,
and the correct implementation of the security mechanism in and the correct implementation of the security mechanism in
communicating LDP implementations. Also, the level of security communicating LDP implementations. Also, the level of security
provided by the Cryptographic Authentication TLV varies based on the provided by the Cryptographic Authentication TLV varies based on the
authentication type used. authentication type used.
It should be noted that the authentication method described in this It should be noted that the authentication method described in this
document is not being used to authenticate the specific originator of document is not being used to authenticate the specific originator of
a packet but is rather being used to confirm that the packet has a packet but is rather being used to confirm that the packet has
indeed been issued by a router that has access to the Authentication indeed been issued by a router that has access to the authentication
Key. key.
Deployments SHOULD use sufficiently long and random values for the Deployments SHOULD use sufficiently long and random values for the
Authentication Key so that guessing and other cryptographic attacks authentication key so that guessing and other cryptographic attacks
on the key are not feasible in their environments. In support of on the key are not feasible in their environments. In support of
these recommendations, management systems SHOULD support hexadecimal these recommendations, management systems SHOULD support hexadecimal
input of Authentication Keys. input of authentication keys.
The mechanism described herein is not perfect . However, this The mechanism described herein is not perfect. However, this
mechanism introduces a significant increase in the effort required mechanism introduces a significant increase in the effort required
for an adversary to successfully attack the LDP Hello protocol while for an adversary to successfully attack the LDP Hello protocol while
not causing undue implementation, deployment, or operational not causing undue implementation, deployment, or operational
complexity. complexity.
9. IANA Considerations 9. IANA Considerations
The IANA is requested to as assign a new TLV from the "Label The IANA has assigned a new TLV from the "Label Distribution Protocol
Distribution Protocol (LDP) Parameters" registry, "TLV Type Name (LDP) Parameters" registry, "TLV Type Name Space".
Space".
Value Meaning Reference
----- -------------------------------- ------------------------
TBD1 Cryptographic Authentication TLV this document (sect 2.3)
The IANA is also requested to as assign value from the
"Authentication Cryptographic Protocol ID", registry under the
"Keying and Authentication for Routing Protocols (KARP) Parameters"
category.
Value Description Reference Value Description Reference
----- -------------------------------- ---------------------- ------ -------------------------------- ---------------------------
TBD2 LDP Cryptographic Protocol ID this document (sect 4) 0x0405 Cryptographic Authentication TLV this document (Section 2.3)
Note to the RFC Editor and IANA (to be removed before publication): The IANA has also assigned a value from the "Authentication
Cryptographic Protocol ID" registry under the "Keying and
Authentication for Routing Protocols (KARP) Parameters" category.
The new value should be assigned from the range 0x400 - 0x4ff using Value Description Reference
the first free value. ----- -------------------------------- -------------------------
2 LDP Cryptographic Protocol ID this document (Section 4)
10. Acknowledgements 10. Acknowledgements
We are indebted to Yaron Sheffer who helped us enormously in We are indebted to Yaron Sheffer who helped us enormously in
rewriting the draft to get rid of the redundant crypto mathematics rewriting the document to get rid of the redundant crypto mathematics
that we had added here. that we had added here.
We would also like to thank Liu Xuehu for his work on background and We would also like to thank Liu Xuehu for his work on background and
motivation for LDP Hello authentication. And last but not the least, motivation for LDP Hello authentication. Last but not least, we
we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen
Farrell, Eric Gray, Kamran Raza and Acee Lindem for their valuable Farrell, Eric Gray, Kamran Raza, and Acee Lindem for their valuable
comments. comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS-180-3] [FIPS-180-4]
"Secure Hash Standard (SHS), FIPS PUB 180-3", October National Institute of Standards and Technology (NIST),
2008. "Secure Hash Standard (SHS)", FIPS 180-4, March 2012.
[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, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
11.2. Informative References 11.2. Informative References
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009.
[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 [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012. (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.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, March 2014.
Authors' Addresses Authors' Addresses
Lianshu Zheng Lianshu Zheng
Huawei Technologies Huawei Technologies
China China
Email: vero.zheng@huawei.com EMail: vero.zheng@huawei.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Huawei Technologies
China China
Email: mach.chen@huawei.com EMail: mach.chen@huawei.com
Manav Bhatia Manav Bhatia
Ionos Networks Ionos Networks
India India
Email: manav@ionosnetworks.com EMail: manav@ionosnetworks.com
 End of changes. 87 change blocks. 
230 lines changed or deleted 203 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/