One document matched: draft-zheng-mpls-ldp-hello-crypto-auth-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-zheng-mpls-ldp-hello-crypto-auth-04.txt"
ipr="trust200902">
<front>
<title abbrev="LDP Hello Cryptographic Authentication">LDP Hello
Cryptographic Authentication</title>
<author fullname="Lianshu Zheng" initials="L." surname="Zheng">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<email>verozheng@huawei.com</email>
</address>
</author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<email>mach@huawei.com</email>
</address>
</author>
<author fullname="Manav Bhatia" initials="M." surname="Bhatia">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>India</country>
</postal>
<email>manav.bhatia@alcatel-lucent.com</email>
</address>
</author>
<date day="10" month="May" year="2012" />
<abstract>
<t> 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 National Institute of Standards and Technology (NIST) Secure
Hash Standard family of algorithms.
</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The Label Distribution Protocol (LDP) <xref target="RFC5036"></xref>
sets up LDP sessions that runs between LDP peers. The peers could either be
directly connected at the link level or could 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 the 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 sent to keep the LDP sessions alive. </t>
<t>Unlike other LDP messages, the Hello messages are sent using UDP
and not TCP. This implies that these messages can not use the security mechanisms
defined for TCP <xref target="RFC5926"> </xref>. <xref target="RFC5036"></xref>, besides
a note that some configuration may help protect against bogus discovery messages, does not really
provide any security mechanism to protect the Hello messages.</t>
<t>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 have been
observed and reported as a real problem in production networks
<xref target="I-D.ietf-karp-routing-tcp-analysis"/>.</t>
<t><xref target="RFC5036"></xref> describes that 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.</t>
<t>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. It also introduces a cryptographic sequence number
carried in the Hello messages that can be used to protect against
replay attacks. As a further step in security, the LSRs could be configured to only accept Hello
messages from specific peers when authentication is in use.</t>
<t>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) <xref target="FIPS-180-3"></xref>.
The HMAC authentication mode defined in NIST FIPS 198 is used <xref
target="FIPS-198"></xref>. 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.</t>
</section>
<section title="Cryptographic Authentication TLV">
<section title="Optional Parameter for Hello Message">
<t><xref target="RFC5036"></xref> 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 <xref
target="RFC5036"></xref>. This document defines a new Optional
Parameter: the Cryptographic Authentication parameter.</t>
<figure align="left">
<artwork>
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)
</artwork>
</figure>
<t>The Cryptographic Authentication TLV Encoding is described in
section 2.2.</t>
</section>
<section title="Cryptographic Authentication TLV Encoding">
<figure align="left">
<artwork>
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) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>- Type: 0x0404 (TBD by IANA), Cryptographic Authentication</t>
<t>- Length: Specifying the length in octets of the value field.</t>
<t>- Auth Key ID: 32 bit field that identifies the algorithm and the
secret key used to create the message digest carried in LDP
payload. </t>
<t>- 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 Hello packet sent by the LDP router.
Upon reception, the sequence number MUST be greater than the
sequence number in the last LDP Hello packet accepted from the
sending LDP neighbor. Otherwise, the LDP packet is
considered a replayed packet and dropped. </t>
<t> 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). One mechanism for accomplishing
this could be to use the high-order 32 bits of the sequence number as a wrap/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 really beyond the scope of this specification.
</t>
<t>- Authentication Data:</t>
<t>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:</t>
<figure align="left">
<artwork>
Auth type Length
--------------- ----------
HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes
</artwork>
</figure>
</section>
</section>
<section title="Cryptographic Aspects">
<t>In the algorithm description below, the following nomenclature, which
is consistent with <xref target="FIPS-198"></xref>, is used:</t>
<t>- H is the specific hashing algorithm specified by Auth Type (e.g.
SHA-256).</t>
<t>- K is the Authentication Key for the Hello packet.</t>
<t>- Ko is the cryptographic key used with the hash algorithm.</t>
<t>- B is the block size of H, in octets.</t>
<figure align="left">
<artwork>
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
</artwork>
</figure>
<t>- L is the length of the hash outputs, in octets.</t>
<t>- XOR is the exclusive-or operation.</t>
<t>- Ipad is the byte 0x36 repeated B times.</t>
<t>- Opad is the byte 0x5c repeated B times.</t>
<t>- 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.</t>
<section title="Cryptographic Key">
<t>As described in <xref target="RFC2104"></xref>, 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.</t>
<t>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.</t>
</section>
<section title="Hash">
<t>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:</t>
<t>H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet)))</t>
<t>Hello Packet refers to the LDP Hello packet excluding the IP
header.</t>
</section>
<section title="Result">
<t>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.</t>
</section>
</section>
<section title="Processing Hello Message Using Cryptographic Authentication">
<section title="Transmission Using Cryptographic Authentication">
<t>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.</t>
<t>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.</t>
</section>
<section title="Receipt Using Cryptographic Authentication">
<t>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 <xref
target="RFC5036"></xref>.</t>
<t>If the Auth Key ID field does not
match the ID of a configured authentication key, the received packet
MUST be discarded.</t>
<t> 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.
</t>
<t>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 <xref target="RFC5036"></xref>.
Otherwise, the received packet MUST be discarded.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>Section 1 of this document describes the security issues arising from
the use of unsecured LDP Hello messages. In order to address those
issues, it is RECOMMENDED that all deployments use the Cryptographic
Authentication TLV to secure the Hello messages.</t>
<t>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.</t>
<t> 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.
</t>
<t>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. Furthermore, it
is RECOMMENDED that Authentication Keys incorporate at least 128
pseudo-random bits to minimize the risk of such attacks. In support
of these recommendations, management systems SHOULD support
hexadecimal input of Authentication Keys.
</t>
<t> The mechanism described herein is not perfect and does not need to be
perfect. Instead, this mechanism represents 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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
<t> We would also like to thank the authors of RFC 5709 from where we have
taken most of the cryptographic computation procedures from.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.5036'?>
<reference anchor="FIPS-180-3">
<front>
<title>Secure Hash Standard (SHS), FIPS PUB 180-3</title>
<author fullname="National Institute of Standards and Technology">
<organization></organization>
</author>
<date month="October" year="2008" />
</front>
</reference>
<reference anchor="FIPS-198">
<front>
<title>The Keyed-Hash Message Authentication Code (HMAC), FIPS PUB
198</title>
<author fullname="US National Institute of Standards & Technology">
<organization></organization>
</author>
<date month="March" year="2002" />
</front>
</reference>
</references>
<references></references>
<references title="Informative References">
<?rfc include='reference.RFC.5926'?>
<?rfc include='reference.I-D.ietf-karp-routing-tcp-analysis'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:30:16 |