doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7349.txt b/doc/rfc/rfc7349.txt
new file mode 100644
index 0000000..c4a8187
--- /dev/null
+++ b/doc/rfc/rfc7349.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          L. Zheng
+Request for Comments: 7349                                       M. Chen
+Category: Standards Track                            Huawei Technologies
+ISSN: 2070-1721                                                M. Bhatia
+                                                          Ionos Networks
+                                                             August 2014
+
+
+                 LDP Hello Cryptographic Authentication
+
+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 a mechanism to secure
+   the LDP Hello messages using Hashed Message Authentication Code
+   (HMAC) with the National Institute of Standards and Technology (NIST)
+   Secure Hash Standard family of algorithms.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   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 (c) 2014 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.                Standards Track                    [Page 1]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Cryptographic Authentication TLV  . . . . . . . . . . . . . .   4
+     2.1.  Optional Parameter for Hello Message  . . . . . . . . . .   4
+     2.2.  LDP Security Association  . . . . . . . . . . . . . . . .   4
+     2.3.  Cryptographic Authentication TLV Encoding . . . . . . . .   6
+     2.4.  Sequence Number Wrap  . . . . . . . . . . . . . . . . . .   7
+   3.  Cryptographic Authentication Procedure  . . . . . . . . . . .   8
+   4.  Cross-Protocol Attack Mitigation  . . . . . . . . . . . . . .   8
+   5.  Cryptographic Aspects . . . . . . . . . . . . . . . . . . . .   8
+     5.1.  Preparing the Cryptographic Key . . . . . . . . . . . . .   9
+     5.2.  Computing the Hash  . . . . . . . . . . . . . . . . . . .   9
+     5.3.  Result  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   6.  Processing Hello Message Using Cryptographic Authentication .  10
+     6.1.  Transmission Using Cryptographic Authentication . . . . .  10
+     6.2.  Receipt Using Cryptographic Authentication  . . . . . . .  10
+   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  11
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  14
+
+1.  Introduction
+
+   The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions
+   that run between LDP peers.  The peers could either be directly
+   connected at the link level or be multiple hops away.  An LDP Label
+   Switching Router (LSR) could either be configured with the identity
+   of its peers or could discover them using LDP Hello messages.  These
+   messages are sent encapsulated in UDP 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.
+
+   Since the Hello messages are sent using UDP and not TCP, these
+   messages cannot use the security mechanisms defined for TCP
+   [RFC5926].  While some configuration guidance is given in [RFC5036]
+   to help protect against false discovery messages, it does not provide
+   an explicit security mechanism to protect the Hello messages.
+
+   Spoofing a Hello message 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
+
+
+
+Zheng, et al.                Standards Track                    [Page 2]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+   within this smaller interval, while the true neighbor continues
+   sending Hellos at the previously agreed lower frequency.  Spoofing a
+   Hello message 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 have been observed and
+   reported as a real problem in production networks [RFC6952].
+
+   For Link Hello, [RFC5036] states that the threat of spoofed Hellos
+   can be reduced by accepting Hellos only on interfaces to which LSRs
+   that can be trusted are directly connected and ignoring Hellos not
+   addressed to the "all routers on this subnet" multicast group.  The
+   Generalized TTL Security Mechanism (GTSM) provides a simple and
+   reasonably robust defense mechanism for Link Hello [RFC6720], but it
+   does not secure against packet spoofing attacks or replay attacks
+   [RFC5082].
+
+   Spoofing attacks via Targeted Hellos are a potentially more serious
+   threat.  [RFC5036] states that an LSR can reduce the threat of
+   spoofed Targeted Hellos by filtering them and accepting only those
+   originating at sources permitted by an access list.  However,
+   filtering using access lists requires LSR resources and does not
+   prevent IP-address spoofing.
+
+   This document introduces a new Cryptographic Authentication TLV that
+   is used in LDP Hello messages as an optional parameter.  It enhances
+   the authentication mechanism for LDP by securing the Hello message
+   against spoofing attacks.  It also introduces a cryptographic
+   sequence number carried in the Hello messages that can be used to
+   protect against replay attacks.
+
+   Using this Cryptographic Authentication TLV, one or more secret keys
+   (with corresponding Security Association (SA) IDs) are configured in
+   each system.  For each LDP Hello message, the key is used to generate
+   and verify an HMAC Hash that is stored in the LDP Hello message.  For
+   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
+   (SHS) [FIPS-180-4].  The HMAC authentication mode defined in
+   [RFC2104] is used.  Of the above, implementations MUST include
+   support for at least HMAC-SHA-256, SHOULD include support for HMAC-
+   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].
+
+
+
+
+Zheng, et al.                Standards Track                    [Page 3]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+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 (RFC 5036)
+   Configuration Sequence Number     0x0402 (RFC 5036)
+   IPv6 Transport Address            0x0403 (RFC 5036)
+   Cryptographic Authentication TLV  0x0405 (this document)
+
+   The encoding for the Cryptographic Authentication TLV is described in
+   Section 2.3.
+
+2.2.  LDP Security Association
+
+   An LDP Security Association (SA) contains a set of parameters shared
+   between any two legitimate LDP speakers.
+
+   Parameters associated with an LDP SA are as follows:
+
+   o  Security Association Identifier (SA ID)
+
+      This is a 32-bit unsigned integer used to uniquely identify an LDP
+      SA between two LDP peers, as manually configured by the network
+      operator (or, possibly by some key management protocol specified
+      by the IETF in the future).
+
+      The receiver determines the active SA by looking at the SA ID
+      field in the incoming Hello message.
+
+      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
+      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
+      the packet.
+
+      Using SA IDs makes changing keys while maintaining protocol
+      operation convenient.  Each SA ID specifies two independent parts,
+      the authentication algorithm and the authentication key, as
+      explained below.
+
+
+
+
+Zheng, et al.                Standards Track                    [Page 4]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+      Normally, an implementation would allow the network operator to
+      configure a set of keys in a key chain, with each key in the chain
+      having a fixed lifetime.  The actual operation of these mechanisms
+      is outside the scope of this document.
+
+      Note that each SA ID can indicate a key with a different
+      authentication algorithm.  This allows the introduction of new
+      authentication mechanisms without disrupting existing LDP
+      sessions.
+
+   o  Authentication Algorithm
+
+      This signifies the authentication algorithm to be used with the
+      LDP SA.  This information is never sent in clear text over the
+      wire.  Because this information is not sent on the wire, the
+      implementer chooses an implementation-specific representation for
+      this information.
+
+      Currently, the following algorithms are supported:
+
+      HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
+
+   o  Authentication Key
+
+      This value denotes the cryptographic authentication key associated
+      with the LDP SA.  The length of this key is variable and depends
+      upon the authentication algorithm specified by the LDP SA.
+
+   o  KeyStartAccept
+
+      The time that this LDP router will accept packets that have been
+      created with this LDP Security Association.
+
+   o  KeyStartGenerate
+
+      The time that this LDP router will begin using this LDP Security
+      Association for LDP Hello message generation.
+
+   o  KeyStopGenerate
+
+      The time that this LDP router will stop using this LDP Security
+      Association for LDP Hello message generation.
+
+   o  KeyStopAccept
+
+      The time that this LDP router will stop accepting packets
+      generated with this LDP Security Association.
+
+
+
+
+Zheng, et al.                Standards Track                    [Page 5]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+   In order to achieve smooth key transition, KeyStartAccept SHOULD be
+   less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than
+   KeyStopAccept.  If KeyStartGenerate or KeyStartAccept are left
+   unspecified, the time will default to 0, and the key will be used
+   immediately.  If KeyStopGenerate or KeyStopAccept are left
+   unspecified, the time will default to infinity, and the key's
+   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
+   the KeyStopGenerate time of the old key.  Any unspecified values are
+   encoded as zero.
+
+   Key storage SHOULD persist across a system restart, warm or cold, to
+   avoid operational issues.  In the event that the last key associated
+   with an interface expires, it is unacceptable to revert to an
+   unauthenticated condition and not advisable to disrupt routing.
+   Therefore, the router SHOULD send a "last Authentication Key
+   expiration" notification to the network manager and treat the key as
+   having an infinite lifetime until the lifetime is extended, the key
+   is deleted by network management, or a new key is configured.
+
+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 (0x0405)      |             Length            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                  Security Association ID                      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Cryptographic Sequence Number (High-Order 32 Bits)      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Cryptographic Sequence Number (Low-Order 32 Bits)       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                Authentication Data (Variable)                 |
+    ~                                                               ~
+    |                                                               |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   o  Type: 0x0405, Cryptographic Authentication
+
+   o  Length: The length in octets of the value field, including the
+      Security Association ID and Cryptographic Sequence Number fields.
+
+   o  Security Association ID: The 32-bit field that maps to the
+      authentication algorithm and the secret key used to create the
+      message digest carried in LDP payload.
+
+
+
+Zheng, et al.                Standards Track                    [Page 6]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+      Though the SA ID implies the algorithm, the HMAC output size
+      should not be used by implementers as an implicit hint because
+      additional algorithms may be defined in the future that have the
+      same output size.
+
+   o  Cryptographic Sequence Number: The 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 Hello
+      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.
+
+      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.
+
+   o  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
+      use, which is shown below:
+
+      Auth type        Length
+      ---------------  ----------
+      HMAC-SHA1        20 bytes
+      HMAC-SHA-256     32 bytes
+      HMAC-SHA-384     48 bytes
+      HMAC-SHA-512     64 bytes
+
+2.4.  Sequence Number Wrap
+
+   When incrementing the sequence number for each transmitted LDP
+   message, the sequence number should be treated as an unsigned 64-bit
+   value.  If the lower-order 32-bit value wraps, the higher-order
+   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
+   number wraps, all keys, independent of the key distribution
+
+
+
+
+
+Zheng, et al.                Standards Track                    [Page 7]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+   mechanism, MUST be reset.  This is done to avoid the possibility of
+   replay attacks.  Once the keys have been changed, the higher-order
+   sequence number can be reset to 0 and saved to non-volatile storage.
+
+3.  Cryptographic Authentication Procedure
+
+   As noted earlier, the Security Association ID maps to the
+   authentication algorithm and the secret key used to generate and
+   verify the message digest.  This specification discusses the
+   computation of LDP Cryptographic Authentication data when any of the
+   NIST SHS family of algorithms is used in the Hashed Message
+   Authentication Code (HMAC) mode.
+
+   The currently valid algorithms (including mode) for LDP Cryptographic
+   Authentication include:
+
+   HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
+
+   Of the above, implementations of this specification MUST include
+   support for at least HMAC-SHA-256, SHOULD include support for HMAC-
+   SHA-1, and MAY also include support for HMAC-SHA-384 and HMAC-SHA-
+   512.
+
+   Implementations of this standard MUST use HMAC-SHA-256 as the default
+   authentication algorithm.
+
+4.  Cross-Protocol Attack Mitigation
+
+   In order to prevent cross-protocol replay attacks for protocols
+   sharing common keys, the 2-octet LDP Cryptographic Protocol ID is
+   appended to the authentication key prior to use (refer to Section 8).
+   Other protocols using the common key similarly append their own
+   Cryptographic Protocol IDs to their keys prior to use, thus ensuring
+   that a different key value is used for each protocol.
+
+5.  Cryptographic Aspects
+
+   In the algorithm description below, the following nomenclature is
+   used:
+
+   o  H is the specific hashing algorithm (e.g., SHA-256).
+
+   o  K is the Authentication Key from the LDP Security Association.
+
+   o  Ks is a Protocol-Specific Authentication Key obtained by appending
+      Authentication Key (K) with the 2-octet LDP Cryptographic Protocol
+      ID.
+
+
+
+
+Zheng, et al.                Standards Track                    [Page 8]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+   o  Ko is the cryptographic key used with the hash algorithm.
+
+   o  L is the length of the hash, measured in octets rather than bits.
+
+   o  AuthTag is a value that is the same length as the hash output.  In
+      the case of IPv4, the first 4 octets contain the IPv4 source
+      address followed by the hexadecimal value 0x878FE1F3 repeated
+      (L-4)/4 times.  In the case of IPv6, the first 16 octets contain
+      the IPv6 source address followed by the hexadecimal value
+      0x878FE1F3 repeated (L-16)/4 times.  This implies that hash output
+      is always a length of at least 16 octets.
+
+5.1.  Preparing the Cryptographic Key
+
+   The LDP Cryptographic Protocol ID is appended to the Authentication
+   Key (K) yielding a Protocol-Specific Authentication Key (Ks).  In
+   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
+   this length, as we describe below.  Ks is computed as follows.
+
+   If the Protocol-Specific Authentication Key (Ks) is L octets long,
+   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
+   Protocol-Specific Authentication Key (Ks) is less than L octets long,
+   then Ko is set to the Protocol-Specific Authentication Key (Ks) with
+   zeros appended to the end of the Protocol-Specific Authentication Key
+   (Ks) such that Ko is L octets long.
+
+   For higher entropy, it is RECOMMENDED that Key Ks should be at least
+   L octets long.
+
+5.2.  Computing the Hash
+
+   First, the Authentication Data field in the Cryptographic
+   Authentication TLV is filled with the value AuthTag.  Then, to
+   compute HMAC over the Hello message it performs:
+
+   AuthData = HMAC(Ko, Hello Message)
+
+   Hello Message refers to the LDP Hello message excluding the IP and
+   the UDP headers.
+
+
+
+
+
+
+
+
+
+
+Zheng, et al.                Standards Track                    [Page 9]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+5.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.
+
+   This also means that the use of hash functions with larger output
+   sizes will also increase the size of the LDP message as transmitted
+   on the wire.
+
+6.  Processing Hello Message Using Cryptographic Authentication
+
+6.1.  Transmission Using Cryptographic Authentication
+
+   Prior to transmitting the LDP 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 Security Association ID field is set to the ID of the current
+   authentication key.  The HMAC Hash is computed as explained in
+   Section 5.  The resulting Hash is stored in the Authentication Data
+   field prior to transmission.  The authentication key MUST NOT be
+   carried in the packet.
+
+6.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].
+
+   The receiving router MUST determine whether or not to accept a Hello
+   message from a particular source IP address as follows.  First, if
+   the router has, for that source IP address, a stored LDP Hello
+   cryptographic sequence number or is configured to require LDP Hello
+   authentication, then the router MUST discard any unauthenticated
+   Hello packets.  As specified later in this section, a cryptographic
+   sequence number is only stored for a source IP address as a result of
+   receiving a valid authenticated Hello.
+
+
+
+
+
+
+
+
+Zheng, et al.                Standards Track                   [Page 10]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+   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 SA
+   is not valid for reception (i.e., current time < KeyStartAccept or
+   current time >= KeyStopAccept), the LDP Hello message MUST be
+   discarded, and an error event SHOULD be logged.
+
+   If the cryptographic sequence number in the LDP Hello message is less
+   than or equal to the last sequence number received from the same
+   neighbor, the LDP Hello message MUST be discarded, and an error event
+   SHOULD be logged.
+
+   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 AuthTag
+   and computes the Hash using the authentication key specified by the
+   received Security Association 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,
+   if the locally computed Hash is not equal to the received value of
+   the Authentication Data field, the received LDP Hello message MUST be
+   discarded, and an error event SHOULD be logged.  The aforesaid
+   logging needs to be carefully rate limited, because while a LDP
+   router is under attack by a storm of spoofed Hellos, the resources
+   required for logging could be overwhelming.
+
+   After the LDP Hello message has been successfully authenticated,
+   implementations MUST store the 64-bit cryptographic sequence number
+   for the LDP Hello message received from the source IP address.  The
+   saved cryptographic sequence numbers will be used for replay checking
+   for subsequent packets received from the source IP address.
+
+7.  Operational Considerations
+
+   Careful consideration must be given to when and how to enable and
+   disable authentication on LDP Hellos.  On the one hand, it is
+   critical that an attack cannot cause the authentication to be
+   disabled.  On the other hand, it is equally important that an
+   operator can change the hardware and/or software associated with a
+   neighbor's IP address and successfully bring up an LDP adjacency with
+   the desired level of authentication, which may be with different or
+   no authentication due to software restrictions.
+
+   LDP Hello authentication information (e.g., whether authentication is
+   enabled and what the last cryptographic sequence number is)
+   associated with an IP address is learned via a set of interfaces.  If
+   an interface is administratively disabled, the LDP Hello
+   authentication information learned via that interface MAY be
+
+
+
+Zheng, et al.                Standards Track                   [Page 11]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+   forgotten.  This enables an operator that is not specifically
+   manipulating LDP Hello authentication configurations to easily bring
+   up an LDP adjacency.  An implementation of this standard SHOULD
+   provide a configuration mechanism by which the LDP Hello
+   authentication information associated with an IP address can be shown
+   and can be forgotten; configuration mechanisms are assumed to be
+   accessed via an authenticated channel.
+
+8.  Security Considerations
+
+   Section 1 of this document describes the security issues arising from
+   the use of unauthenticated LDP Hello messages.  In order to address
+   those issues, it is RECOMMENDED that all deployments use the
+   Cryptographic Authentication TLV to authenticate the Hello messages.
+
+   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.
+
+   It should be noted that the authentication method described in this
+   document is not being used to authenticate the specific originator of
+   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
+   key.
+
+   Deployments SHOULD use sufficiently long and random values for the
+   authentication key so that guessing and other cryptographic attacks
+   on the key are not feasible in their environments.  In support of
+   these recommendations, management systems SHOULD support hexadecimal
+   input of authentication keys.
+
+   The mechanism described herein is not perfect.  However, this
+   mechanism introduces a significant increase in the effort required
+   for an adversary to successfully attack the LDP Hello protocol while
+   not causing undue implementation, deployment, or operational
+   complexity.
+
+
+
+
+
+
+
+
+
+
+
+Zheng, et al.                Standards Track                   [Page 12]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+9.  IANA Considerations
+
+   The IANA has assigned a new TLV from the "Label Distribution Protocol
+   (LDP) Parameters" registry, "TLV Type Name Space".
+
+   Value   Description                       Reference
+   ------  --------------------------------  ---------------------------
+   0x0405  Cryptographic Authentication TLV  this document (Section 2.3)
+
+   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.
+
+   Value   Description                       Reference
+   -----   --------------------------------  -------------------------
+     2     LDP Cryptographic Protocol ID     this document (Section 4)
+
+10.  Acknowledgements
+
+   We are indebted to Yaron Sheffer who helped us enormously in
+   rewriting the document to get rid of the redundant crypto mathematics
+   that we had added here.
+
+   We would also like to thank Liu Xuehu for his work on background and
+   motivation for LDP Hello authentication.  Last but not least, we
+   would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen
+   Farrell, Eric Gray, Kamran Raza, and Acee Lindem for their valuable
+   comments.
+
+11.  References
+
+11.1.  Normative References
+
+   [FIPS-180-4]
+              National Institute of Standards and Technology (NIST),
+              "Secure Hash Standard (SHS)", FIPS 180-4, March 2012.
+
+   [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.
+
+
+
+
+
+Zheng, et al.                Standards Track                   [Page 13]
+
+RFC 7349         LDP Hello Cryptographic Authentication      August 2014
+
+
+11.2.  Informative References
+
+   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
+              Pignataro, "The Generalized TTL Security Mechanism
+              (GTSM)", RFC 5082, October 2007.
+
+   [RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
+              for the TCP Authentication Option (TCP-AO)", RFC 5926,
+              June 2010.
+
+   [RFC6720]  Pignataro, C. and R. Asati, "The Generalized TTL Security
+              Mechanism (GTSM) for the Label Distribution Protocol
+              (LDP)", RFC 6720, August 2012.
+
+   [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
+
+   Lianshu Zheng
+   Huawei Technologies
+   China
+
+   EMail: vero.zheng@huawei.com
+
+
+   Mach(Guoyi) Chen
+   Huawei Technologies
+   China
+
+   EMail: mach.chen@huawei.com
+
+
+   Manav Bhatia
+   Ionos Networks
+   India
+
+   EMail: manav@ionosnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+Zheng, et al.                Standards Track                   [Page 14]
+