One document matched: draft-zheng-mpls-ldp-hello-crypto-auth-00.txt
Network working group L. Zheng
Internet Draft M. Chen
Intended status: Standards Track Huawei Technologies
Updates: RFC 5036 (if approved)
Expires: April 2011 October 8, 2010
LDP Hello Cryptographic Authentication
draft-zheng-mpls-ldp-hello-crypto-auth-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 8, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Zheng, et al. Expires April 8, 2011 [Page 1]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document introduces a new Cryptographic Authentication TLV
which is used in LDP Hello message as an optional parameter. It
enhances the authentication mechanism for LDP by securing the Hello
message against spoofing attack.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction..................................................2
2. Cryptographic Authentication TLV..............................4
2.1. Optional Parameter for Hello Message.....................4
2.2. Cryptographic Authentication TLV Encoding................4
3. Processing Hello Message Using Cryptographic Authentication...5
3.1. Transmission Using Cryptographic Authentication..........6
3.2. Receipt Using Cryptographic Authentication...............6
4. Security Considerations.......................................7
5. IANA Considerations...........................................7
6. Acknowledgments...............................................8
7. References....................................................8
7.1. Normative References.....................................8
7.2. Informative References...................................8
Authors' Addresses...............................................9
1. Introduction
The Label Distribution Protocol (LDP) [RFC 5036] utilizes LDP
sessions that run between LDP peers. The peers may be directly
connected at the link level or may be remote. A label switching
router (LSR) that speaks LDP may be configured with the identity of
its peers or may discover them using the LDP Hello message sent
encapsulated in UDP that may be addressed to "all routers on this
subnet" or to a specific IP address. Periodic Hello messages are
also used to maintain the relationship between LDP peers necessary
to keep the LDP session active.
Zheng, et al. Expires April 8, 2011 [Page 2]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
Unlike all other LDP messages, the Hello messages are sent using UDP
not TCP. This means that they cannot benefit from the security
mechanisms available with TCP. [RFC5036] does not provide any
security mechanisms for use with Hello messages except to note that
some configuration may help protect against bogus discovery events.
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 associated session. This can occur when the spoofed Hello
specifies a smaller Hold Time, causing the receiver to expect Hellos
within this smaller interval, while the true neighbor continues
sending Hellos at the previously agreed lower frequency. Spoofing a
Hello packet can also cause the LDP session to be terminated
directly, which can occur when the spoofed Hello specifies a
different Transport Address, other than the previously agreed one
between neighbors. Spoofed Hello messages is observed and reported
as real problem in production networks.
As described in [RFC5036], the threat of spoofed Basic Hellos can be
reduced by accepting Basic Hellos only on interfaces to which LSRs
that can be trusted, and ignoring Basic Hellos not addressed to the
"all routers on this subnet" multicast group. Spoofing attacks via
Extended Hellos are potentially more serious threat. An LSR can
reduce the threat of spoofed Extended Hellos by filtering them and
accepting only those originating at sources permitted by an access
list. However, performing the filtering using access lists requires
LSR resource, and the LSR is still vulnerable to the IP source
address spoofing.
This document introduces a new Cryptographic Authentication TLV
which is used in LDP Hello message as an optional parameter. It
enhances the authentication mechanism for LDP by securing the Hello
message against spoofing attack, and an LSR can be configured to
only accept Hello messages from specific peers when authentication
is in use.
Using this Cryptographic Authentication TLV, one or more secret keys
(with corresponding key IDs) are configured in each system. For each
LDP Hello packet, the key is used to generate and verify a "message
digest" or "message hash" that is stored in the LDP Hello packet. A
sequence number is also carried in each packet to help avoid replay
attacks.
Zheng, et al. Expires April 8, 2011 [Page 3]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
2. Cryptographic Authentication TLV
2.1. Optional Parameter for Hello Message
[RFC5036] defines the encoding for the Hello message. Each Hello
message contains zero or more Optional Parameters, each encoded as a
TLV. Three Optional Parameters are defined by [RFC5036]:
Optional Parameter Type
------------------------------- --------
IPv4 Transport Address 0x0401
Configuration Sequence Number 0x0402
IPv6 Transport Address 0x0403
This document defines a new Optional Parameter: the Cryptographic
Authentication parameter. The Cryptographic Authentication TLV
Encoding is described in section 2.2.
2.2. 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 (0x0404) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Auth Key/Digest/Hash... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 0x0404 (TBD by IANA), Cryptographic Authentication
- Length: Specifying the length in octets of the value field.
- Auth Type: The authentication type in use
0 - Keyed MD5
Zheng, et al. Expires April 8, 2011 [Page 4]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
1 - Meticulous Keyed MD5
2 - Keyed SHA1
3 - Meticulous Keyed SHA1
4 - Keyed SHA-256
5 - Keyed SHA-384
6 - Keyed SHA-512
7-255 - Reserved for future use
(TBD by IANA)
- Auth Key ID: The authentication key ID in use for this packet.
This allows one or more keys to be active simultaneously.
- Reserved: MUST be set to zero on transmit, and ignored on receipt.
- Sequence Number: The sequence number for this packet, providing
protection against replay attacks. The value is incremented
occasionally. For Meticulous Keyed MD5 and Meticulous Keyed SHA1
Authentication, this value is incremented for each successive
packet transmitted for a session.
- Auth Key/Digest/Hash:
This field carries the MD5/SHA1/SHA2 key digest/hash for the packet.
The length of the Auth Key/Digest/Hash varies based on the
cryptographic algorithm used, which is shown as below:
Auth type Length
---------------------- ----------
Keyed MD5 16 bytes
Meticulous Keyed MD5 16 bytes
Keyed SHA1 20 bytes
Meticulous Keyed SHA1 20 bytes
Keyed SHA-256 32 bytes
Keyed SHA-384 48 bytes
Keyed SHA-512 64 bytes
When calculating the digest/hash, the shared key is stored in this
field, padding with trailing zeros if needed.
3. Processing Hello Message Using Cryptographic Authentication
The Cryptographic Authentication mechanisms described in this draft
are very similar to those used in other protocols. One or more
secret keys (with corresponding key IDs) are configured in each
Zheng, et al. Expires April 8, 2011 [Page 5]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
system. One of the keys is included in a digest or a hash calculated
over the outgoing LDP Hello packet, but the Key itself is not
carried in the packet.
A sequence number is also carried in each packet to help avoid
replay attacks. The sequence number may be incremented in a circular
fashion. For most of the authentication scheme in use, the sequence
number is occasionally incremented (The decision as to when to
increment the sequence number is implementation dependent and
outside the scope of this document). Specifically, for Meticulous
Keyed MD5 and Meticulous Keyed SHA1, the sequence number is
incremented on every packet.
3.1. Transmission Using Cryptographic Authentication
Prior to transmitting Hello message, the Auth Type field is set to
indicate the authentication type in use. The Auth Key ID field is
set to the ID of the current authentication key. The Sequence Number
field is set, possibly having been incremented from the last message
sent according to the scheme in place. The authentication key is
placed into the Auth Key/Digest field, padding with trailing zeros
as necessary, for digest/hash calculation.
An MD5 digest or a SHA1/SHA2 hash is calculated over the entire LDP
Hello packet. The resulting digest/hash is stored in the Auth
Key/Digest/Hash field prior to transmission. The secret key is
replaced by the digest/hash, and MUST NOT be carried in the packet.
3.2. Receipt Using Cryptographic Authentication
The receiving LSR applies acceptability criteria for received Hellos
using cryptographic authentication. If the Cryptographic
Authentication TLV is unknown to the receiving LSR, the received
packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036].
If the Cryptographic Authentication TLV in a received Hello packet
does not contain a known and acceptable Auth Type value, then the
received packet MUST be discarded. If the Auth Key ID field does not
match the ID of a configured authentication key, the received packet
MUST be discarded.
Zheng, et al. Expires April 8, 2011 [Page 6]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
For most of the authentication scheme in use, if the received
sequence number lies outside of the range of last sequence number
received to last sequence number received +(Hello Hold Time/Hello
Interval) inclusive, the received packet MUST be discarded.
Specifically, for Meticulous Keyed MD5 and Meticulous Keyed SHA1, if
the received sequence number lies outside of the range of last
sequence number received+1 to last sequence number received +(Hello
Hold Time/Hello Interval) inclusive, the received packet MUST be
discarded.
The receiving LSR replaces the contents of the Auth Key/Digest/Hash
field with the authentication key specified by the received Auth Key
ID field. If the MD5 digest or SHA1/SHA2 hash of the entire LDP
Hello packet is equal to the received value of the Auth
Key/Digest/Hash field, the received packet is accepted for other
normal checks and processing as described in [RFC5036]. Otherwise,
the received packet MUST be discarded.
4. Security Considerations
Section 1 of this document describes the security issues arising
from the use of unsecured LDP Hello messages. In order to combat
those issues, it is RECOMMENDED that all deployments use the
Cryptographic Authentication TLV to secure the Hello message.
The quality of the security provided by the Cryptographic
Authentication TLV depends completely on the strength of the
cryptographic algorithm in use, the strength of the key being used,
and the correct implementation of the security mechanism in
communicating LDP implementations. Also, the level of security
provided by the Cryptographic Authentication TLV varies based on the
authentication type used.
5. IANA Considerations
IANA maintains a registry of LDP message parameters with a sub-
registry to track LDP TLV Types. This document request IANA to
assign a new TLV Types as follows:
TLV Type
Cryptographic Authentication 0x0404 (TBD)
Zheng, et al. Expires April 8, 2011 [Page 7]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
This document also request IANA to assign a new registry titled "LDP
Hello Authentication Type", its recommended values as follows:
Value LDP Hello Authentication Type Name
------- -----------------------------------
0 Keyed MD5
1 Meticulous Keyed MD5
2 Keyed SHA1
3 Meticulous Keyed SHA1
4 Keyed SHA-256
5 Keyed SHA-384
6 Keyed SHA-512
7-255 Unassigned
(TBD)
6. Acknowledgments
The authors would like to thank Liu Xuehu for his work on background
and motivation for LDP Hello authentication. The authors also would
like to thank Adrian Farrel, Thomas Nadeau and So Ning for their
comments.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
7.2. Informative References
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[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.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection",
RFC 5880, June 2010.
Zheng, et al. Expires April 8, 2011 [Page 8]
Internet-Draft LDP Hello Cryptographic Authentication October 2010
Authors' Addresses
Lianshu Zheng
Huawei Technologies Co., Ltd.
Huawei Building, No.3 Xinxi Road,
Hai-Dian District,
Beijing 100085
China
Email: verozheng@huawei.com
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd.
Huawei Building, No.3 Xinxi Road,
Hai-Dian District,
Beijing 100085
China
Email: mach@huawei.com
Zheng, et al. Expires April 8, 2011 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 06:07:09 |