Network working group                                          L. Zheng
Internet Draft                                                  M. Chen
Intended status: Standards Track                    Huawei Technologies
Updates: RFC 5036 (if approved)
Expires: September 2011                                  March 14, 2011


                  LDP Hello Cryptographic Authentication

               draft-zheng-mpls-ldp-hello-crypto-auth-01.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 September 14, 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





Zheng, et al.        Expires September 14, 2011               [Page 1]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


   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. Cryptographic Aspects ......................................... 5
      3.1. Cryptographic Key ........................................ 6
      3.2. Hash ..................................................... 6
      3.3. Result ................................................... 7
   4. Processing Hello Message Using Cryptographic Authentication ... 7
      4.1. Transmission Using Cryptographic Authentication .......... 7
      4.2. Receipt Using Cryptographic Authentication ............... 7
   5. Security Considerations ....................................... 8
   6. IANA Considerations ........................................... 8
   7. Acknowledgments ............................................... 9
   8. References .................................................... 9
      8.1. Normative References ..................................... 9
      8.2. Informative References  .................................. 9
   Authors' Addresses .............................................. 10

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



Zheng, et al.        Expires September 14, 2011               [Page 2]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


   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.

   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 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-



Zheng, et al.        Expires September 14, 2011               [Page 3]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


   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.



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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Auth Type   |    Reserved   |          Auth Key ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                      Authentication Data                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   - Type: 0x0404 (TBD by IANA), Cryptographic Authentication

   - Length: Specifying the length in octets of the value field.

   - Auth Type: The authentication type in use



Zheng, et al.        Expires September 14, 2011               [Page 4]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


      0 - HMAC-SHA-1
      1 - HMAC-SHA-256
      2 - HMAC-SHA-384
      3 - HMAC-SHA-512
      4-255 - Reserved for future use
   (TBD by IANA)

   - Reserved: MUST be set to zero on transmit, and ignored on receipt

   - Auth Key ID: The authentication key ID in use for this packet.
      This allows one or more keys to be active simultaneously.

   - 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


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



Zheng, et al.        Expires September 14, 2011               [Page 5]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


   - 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 the byte 0x878FE1F3 repeated (L/4) times.



3.1. Cryptographic Key

   As described in RFC 2104, 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 and the Auth Type
   field is set accordingly per Cryptographic Authentication algorithm
   in use.

   Then, to compute HMAC over the Hello packet it performs:

     H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet)))

   Hello Packet here is the entire LDP Hello packet including the IP
   header.








Zheng, et al.        Expires September 14, 2011               [Page 6]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


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.



4. Processing Hello Message Using Cryptographic Authentication

4.1. Transmission Using Cryptographic Authentication

   Prior to transmitting Hello message, the Auth Type field is set to
   indicate the authentication type in use. 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 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.

   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



Zheng, et al.        Expires September 14, 2011               [Page 7]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


   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.



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.



6. 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)

   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      HMAC-SHA1
           1      HMAC-SHA-256
           2      HMAC-SHA-384
           3      HMAC-SHA-512
         4-255    Unassigned
        (TBD)


Zheng, et al.        Expires September 14, 2011               [Page 8]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


7. 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, So Ning, Eric Rosen, Sam
   Hartman and Manav Bhatia for their valuable comments.



8. References

8.1. Normative References

   [RFC2104] Krawczyk, H. et al., "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.

   [FIPS-180-3] National Institute of Standards and Technology, "Secure
             Hash Standard (SHS)", FIPS PUB 180-3, October 2008.

   [FIPS-198] US National Institute of Standards & Technology, "The
             Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
             198, March 2002.

8.2. Informative References

   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
             Signature Option", RFC 2385, August 1998.

   [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
             (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [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 September 14, 2011               [Page 9]


Internet-Draft LDP Hello Cryptographic Authentication       March 2011


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 September 14, 2011              [Page 10]