Network Working Group L. Zheng Internet-Draft M. Chen Intended status: Standards Track Huawei Technologies Expires: December 30, 2011 M. Bhatia Alcatel-Lucent June 28, 2011 LDP Hello Cryptographic Authentication draft-zheng-mpls-ldp-hello-crypto-auth-02.txt Abstract This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms should be used to secure LDP Hello messages. Zheng, et al. Expires December 30, 2011 [Page 1] Internet-Draft LDP Hello Cryptographic Authentication June 2011 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 This Internet-Draft is submitted in full conformance with the 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 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." This Internet-Draft will expire on December 30, 2011. Copyright Notice Copyright (c) 2011 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 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zheng, et al. Expires December 30, 2011 [Page 2] Internet-Draft LDP Hello Cryptographic Authentication June 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Cryptographic Authentication TLV . . . . . . . . . . . . . . . 6 2.1. Optional Parameter for Hello Message . . . . . . . . . . . 6 2.2. Cryptographic Authentication TLV Encoding . . . . . . . . 6 3. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8 3.1. Cryptographic Key . . . . . . . . . . . . . . . . . . . . 8 3.2. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Processing Hello Message Using Cryptographic Authentication . 10 4.1. Transmission Using Cryptographic Authentication . . . . . 10 4.2. Receipt Using Cryptographic Authentication . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Zheng, et al. Expires December 30, 2011 [Page 3] Internet-Draft LDP Hello Cryptographic Authentication June 2011 1. Introduction The Label Distribution Protocol (LDP) [RFC5036] 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. 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. Spoofed Hello attack has been identified in [I-D.ietf-karp-routing-tcp-analysis] and need to be addressed. 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. Zheng, et al. Expires December 30, 2011 [Page 4] Internet-Draft LDP Hello Cryptographic Authentication June 2011 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 HMAC Hash that is stored in the LDP Hello packet. For cryptographic hash function, this document proposes to use SHA-1, SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3]. The HMAC authentication mode defined in NIST FIPS 198 is used [FIPS-198]. Of the above, implementations MUST include support for at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or HMAC-SHA-512. Zheng, et al. Expires December 30, 2011 [Page 5] Internet-Draft LDP Hello Cryptographic Authentication June 2011 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]. This document defines a new Optional Parameter: the Cryptographic Authentication parameter. Optional Parameter Type ------------------------------- -------- IPv4 Transport Address 0x0401 (RFC5036) Configuration Sequence Number 0x0402 (RFC5036) IPv6 Transport Address 0x0403 (RFC5036) Cryptographic Authentication 0x0404 (this document, TBD by IANA) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic Sequence Number (High Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic Sequence Number (Low Order 32 Bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data (Variable) | ~ ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 0x0404 (TBD by IANA), Cryptographic Authentication - Length: Specifying the length in octets of the value field. - Auth Key ID: 32 bit field that identifies the algorithm and the secret key used to create the message digest carried in LDP payload. Zheng, et al. Expires December 30, 2011 [Page 6] Internet-Draft LDP Hello Cryptographic Authentication June 2011 - Cryptographic Sequence Number: 64-bit strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every LDP packet sent by the LDP router. Upon reception, the sequence number MUST be greater than the sequence number in the last LDP packet accepted from the sending LDP neighbor. In case it isnt, the LDP packet is considered a replayed packet and is dropped. LDP routers implementing this specification SHOULD use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the LDP router (including cold restarts). Techniques such as sequence number space partitioning and non-volatile storage preservation can be used but are beyond the scope of this specification. - Authentication Data: This field carries the digest computed by the Cryptographic Authentication algorithm in use. The length of the Authentication Data varies based on the cryptographic algorithm in used, which is shown as below: Auth type Length --------------- ---------- HMAC-SHA1 20 bytes HMAC-SHA-256 32 bytes HMAC-SHA-384 48 bytes HMAC-SHA-512 64 bytes Zheng, et al. Expires December 30, 2011 [Page 7] Internet-Draft LDP Hello Cryptographic Authentication June 2011 3. Cryptographic Aspects In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used: - H is the specific hashing algorithm specified by Auth Type (e.g. SHA-256). - K is the Authentication Key for the Hello packet. - Ko is the cryptographic key used with the hash algorithm. - B is the block size of H, in octets. For SHA-1 and SHA-256: B == 64 For SHA-384 and SHA-512: B == 128 - L is the length of the hash outputs, in octets. - XOR is the exclusive-or operation. - Ipad is the byte 0x36 repeated B times. - Opad is the byte 0x5c repeated B times. - Apad is source IP address that the would be used when sending out the LDP packet, repeated L/4 times, where L is the length of the hash, measured in octets. 3.1. Cryptographic Key As described in [RFC2104], the authentication key K can be of any length up to B. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. In this application, Ko is always L octets long. If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with trailing zeros such that Ko is L octets long. 3.2. Hash First, the Authentication Data field in the Cryptographic Authentication TLV is filled with the value Apad. Then, to compute HMAC over the Hello packet it performs: Zheng, et al. Expires December 30, 2011 [Page 8] Internet-Draft LDP Hello Cryptographic Authentication June 2011 H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet))) Hello Packet refers to the LDP Hello packet excluding the IP header. 3.3. Result The resultant Hash becomes the Authentication Data that is sent in the Authentication Data field of the Cryptographic Authentication TLV. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used. Zheng, et al. Expires December 30, 2011 [Page 9] Internet-Draft LDP Hello Cryptographic Authentication June 2011 4. Processing Hello Message Using Cryptographic Authentication 4.1. Transmission Using Cryptographic Authentication Prior to transmitting Hello message, the Length in the Cryptographic Authentication TLV header is set as per the 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-SHA-512. The Auth Key ID field is set to the ID of the current authentication key. The HMAC Hash is computed as explained in Section 3. The resulting Hash is stored in the Authentication Data field prior to transmission. The authentication key MUST NOT be carried in the packet. 4.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 Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded. If the cryptographic sequence number in the LDP packet is less than or equal to the last sequence number received from the same neighbor, the LDP packet MUST be discarded. Before the receiving LSR performs any processing, it needs to save the values of the Authentication Data field. The receiving LSR then replaces the contents of the Authentication Data field with Apad, computes the Hash, using the authentication key specified by the received Auth Key ID field, as explained in Section 3. If the locally computed Hash is equal to the received value of the Authentication Data field, the received packet is accepted for other normal checks and processing as described in [RFC5036]. Otherwise, the received packet MUST be discarded. Zheng, et al. Expires December 30, 2011 [Page 10] Internet-Draft LDP Hello Cryptographic Authentication June 2011 5. 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. Zheng, et al. Expires December 30, 2011 [Page 11] Internet-Draft LDP Hello Cryptographic Authentication June 2011 6. IANA Considerations IANA maintains a registry of LDP message parameters with a sub- registry to track LDP TLV Types. This document requests IANA to assign a new TLV type as follows for Cryptographic Authenticatio. This document suggests 0x0404 to foster pre-standard implementations. Zheng, et al. Expires December 30, 2011 [Page 12] Internet-Draft LDP Hello Cryptographic Authentication June 2011 7. Acknowledgements 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, So Ning, Eric Rosen and Sam Hartman for their valuable comments. We would also like to thank the authors of RFC 5709 from where we have taken most of the cryptographic computation procedures from. Zheng, et al. Expires December 30, 2011 [Page 13] Internet-Draft LDP Hello Cryptographic Authentication June 2011 8. References 8.1. Normative References [FIPS-180-3] "Secure Hash Standard (SHS), FIPS PUB 180-3", October 2008. [FIPS-198] "The Keyed-Hash Message Authentication Code (HMAC), FIPS 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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. 8.2. References 8.3. Informative References [I-D.ietf-karp-routing-tcp-analysis] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide", draft-ietf-karp-routing-tcp-analysis-00 (work in progress), June 2011. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [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. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. Zheng, et al. Expires December 30, 2011 [Page 14] Internet-Draft LDP Hello Cryptographic Authentication June 2011 Authors' Addresses Lianshu Zheng Huawei Technologies China Email: verozheng@huawei.com Mach(Guoyi) Chen Huawei Technologies China Email: mach@huawei.com Manav Bhatia Alcatel-Lucent India Email: manav.bhatia@alcatel-lucent.com Zheng, et al. Expires December 30, 2011 [Page 15]