LDP Hello Cryptographic Authentication
Extracted elements (25)
SA IDs make key rolling convenient while maintaining protocol operation: each SA ID maps to an independent algorithm and key, so a new SA can be introduced without disrupting existing adjacencies. Multiple valid SAs may coexist and the sender may use any of them.
The AuthTag construction fills the Authentication Data field with a value derived from the IP source address before hash computation. This covers the IP source address in the HMAC and protects against attacks that spoof or manipulate the IP header fields.
To prevent cross-protocol replay attacks among protocols sharing common keys, a 2-octet LDP Cryptographic Protocol ID (value 2) is appended to the authentication key before use, producing a protocol-specific key Ks. Other protocols using the same key append their own Protocol IDs, ensuring distinct effective key values per protocol.
If the Cryptographic Authentication TLV (0x0405) is unknown to the receiving LSR, the received packet MUST be discarded per the unknown-TLV handling rules in RFC 5036 Section 3.5.1.2.2. Bit pattern 0|0 in the TLV type field causes unknown TLVs to be dropped.
The HMAC output size of the Authentication Data field SHOULD NOT be used by implementers as an implicit hint for the algorithm in use, because future algorithms may share the same output size. The SA ID is the authoritative indicator of the algorithm.
The TLV Length field for the Cryptographic Authentication TLV is set based on the algorithm: 24 for HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384, and 68 for HMAC-SHA-512 (covering the SA ID, 64-bit sequence number, and authentication data fields).
After a Hello is successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for subsequent replay checking for packets received from that source IP address. The authentication key MUST NOT be carried in the packet.
If the 64-bit sequence number wraps, all keys—independent of key distribution mechanism—MUST be reset to avoid replay attacks. After key reset, the higher-order sequence number can be reset to 0 and saved to non-volatile storage.
If the locally computed HMAC hash is not equal to the received Authentication Data field value, the LDP Hello message MUST be discarded and an error event SHOULD be logged. The logging MUST be carefully rate-limited to avoid resource exhaustion under spoofed-Hello storms.
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.
Implementations of this standard MUST use HMAC-SHA-256 as the default authentication algorithm.
Key storage SHOULD persist across a system restart (warm or cold). If the last key associated with an interface expires, the router SHOULD send a 'last Authentication Key expiration' notification and treat the key as having an infinite lifetime rather than reverting to an unauthenticated condition.
LDP routers implementing this specification MUST use existing mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the router, including across cold restarts. One approach is to use the high-order 32 bits as a boot count stored in non-volatile storage.
On receipt, if the router has a stored LDP Hello cryptographic sequence number for the source IP address, or is configured to require authentication, it MUST discard any unauthenticated Hello packets.
The 64-bit Cryptographic Sequence Number MUST be incremented for every LDP Hello message sent, and upon reception the sequence number MUST be greater than the sequence number in the last accepted Hello from that neighbor; otherwise the message is treated as a replay and dropped.
The receiving LSR locates the SA using the SA ID field. If the SA is not found or is not valid for reception (current time < KeyStartAccept or >= KeyStopAccept), the LDP Hello MUST be discarded and an error event SHOULD be logged.
To achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. 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.
An LDP Security Association (SA) is identified by a 32-bit SA ID and contains: the authentication algorithm, the authentication key, and four time parameters (KeyStartAccept, KeyStartGenerate, KeyStopGenerate, KeyStopAccept) that govern key rollover windows. The authentication algorithm and key are never sent on the wire.
The Cryptographic Authentication TLV is assigned Optional Parameter type 0x0405 for use in LDP Hello messages, alongside the existing IPv4 Transport Address (0x0401), Configuration Sequence Number (0x0402), and IPv6 Transport Address (0x0403) parameters.
To compute the HMAC, the Authentication Data field is first filled with AuthTag (a value encoding the IP source address followed by the repeated byte pattern 0x878FE1F3). Then AuthData = HMAC(Ko, Hello Message) is computed over the LDP Hello message excluding IP and UDP headers.
IANA assigned TLV type 0x0405 ('Cryptographic Authentication TLV') in the LDP Parameters 'TLV Type Name Space' registry.
IANA assigned value 2 ('LDP Cryptographic Protocol ID') in the 'Authentication Cryptographic Protocol ID' registry under the KARP Parameters category. This value is appended to authentication keys to prevent cross-protocol replay attacks.
Deployments SHOULD use sufficiently long and random authentication keys to resist guessing and cryptographic attacks; management systems SHOULD support hexadecimal key input. Use of Cryptographic Authentication TLV is RECOMMENDED for all deployments to guard against spoofed-Hello attacks that can terminate adjacencies or sessions.
The authentication mechanism confirms that a Hello was issued by a router with access to the authentication key, but does not authenticate the specific originator of the packet. Security quality depends entirely on algorithm strength, key strength, and correct implementation.
The Cryptographic Authentication TLV (type 0x0405) contains a 32-bit Security Association ID, a 64-bit Cryptographic Sequence Number (split into high and low 32-bit halves), and a variable-length Authentication Data field whose size depends on the algorithm (20 bytes for HMAC-SHA-1, 32 for HMAC-SHA-256, 48 for HMAC-SHA-384, 64 for HMAC-SHA-512).