draft-ietf-mpls-ldp-hello-crypto-auth-03.txt   draft-ietf-mpls-ldp-hello-crypto-auth-04.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 20, 2014 M. Bhatia Expires: September 30, 2014 M. Bhatia
Alcatel-Lucent Alcatel-Lucent
March 19, 2014 March 29, 2014
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
draft-ietf-mpls-ldp-hello-crypto-auth-03.txt draft-ietf-mpls-ldp-hello-crypto-auth-04.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.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 20, 2014. This Internet-Draft will expire on September 30, 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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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
skipping to change at page 4, line 33 skipping to change at page 4, line 33
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 a real problem in production networks [RFC6952].
[I-D.ietf-karp-routing-tcp-analysis].
[RFC5036] states that the threat of spoofed Hellos can be reduced by [RFC5036] states that the threat of spoofed Hellos can be reduced by
accepting Hellos only on interfaces to which LSRs that can be trusted accepting Hellos only on interfaces to which LSRs that can be trusted
are directly connected, and ignoring Hellos not addressed to the "all are directly connected, and ignoring Hellos not addressed to the "all
routers on this subnet" multicast group. Spoofing attacks via routers on this subnet" multicast group. Spoofing attacks via
Targeted Hellos are a potentially more serious threat. An LSR can Targeted Hellos are a potentially more serious threat. An LSR can
reduce the threat of spoofed Targeted Hellos by filtering them and reduce the threat of spoofed Targeted Hellos by filtering them and
accepting only those originating at sources permitted by an access accepting only those originating at sources permitted by an access
list. However, filtering using access lists requires LSR resource, list. However, filtering using access lists requires LSR resource,
and does not prevent IP-address spoofing. and does not prevent IP-address spoofing.
skipping to change at page 12, line 51 skipping to change at page 12, line 51
(L-16)/4 times. This implies that hash output is always a length of (L-16)/4 times. This implies that hash output is always a length of
at least 16 octets. 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. While [RFC2104] this application, Ko is always L octets long. While [RFC2104]
supports a key that is up to B octets long, this application uses L supports a key that is up to B octets long, this application uses L
as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and
[RFC6506] [RFC7166]. According to [FIPS-180-3], Section 3, keys [RFC7166]. According to [FIPS-180-3], Section 3, keys greater than L
greater than L octets do not significantly increase the function octets do not significantly increase the function strength. Ks is
strength. Ks is computed as follows: 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.
5.2. Computing the Hash 5.2. Computing the Hash
skipping to change at page 19, line 17 skipping to change at page 19, line 17
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 2008. October 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.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 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.
[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.
[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.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
[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.
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506,
February 2012.
[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
[I-D.ietf-karp-routing-tcp-analysis] [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Jethanandani, M., Patel, K., and L. Zheng, "Analysis of Hashing for Message Authentication", RFC 2104,
BGP, LDP, PCEP and MSDP Issues According to KARP Design February 1997.
Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
progress), April 2013.
[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.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
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
 End of changes. 11 change blocks. 
23 lines changed or deleted 17 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/