The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
Extracted elements (24)
A fixed-length 4-byte Key ID was chosen over a variable-length key name (as used in DNS TSIG) to minimize the size expansion caused by the relay agent information option. Named keys would require more physical space and more complex encoding and parsing implementations.
The server generates its own Authentication suboption in reply messages rather than echoing back the relay agent's suboption; this is a deliberate variance from RFC 3046 section 2.2, enabling independent authentication of server-to-relay traffic.
Two alternative mechanisms for authenticating relay agent options were developed: this suboption-based approach and IPsec-based authentication. The suboption approach is appropriate when IPsec is unavailable or when multiple relay agents make pairwise key management burdensome; IPsec is appropriate when it is readily available and pairwise keys can be efficiently managed.
In multi-relay configurations where one relay agent adds the relay agent option and another sets giaddr, both 'giaddr' and 'hops' must be zeroed during hash computation to ensure consistent checksum calculation across all relay topologies.
The existing DHCP Authentication specification (RFC 3118) explicitly excludes relay-agent data from its authentication because relay-agent information is added after the client sends its message. This specification fills that gap for the relay-agent-to-server segment only.
A relay agent that adds a relay agent information option and sets giaddr MUST NOT set the Relay ID field.
All implementations MUST support Algorithm 1, the HMAC-SHA1 algorithm, for computing authentication information.
All implementations MUST support the default RDM (value 1), which uses a monotonically increasing counter for replay detection.
At the replay detection check stage, the receiver MUST NOT update its notion of the last valid Replay Detection value until the checksum has been successfully tested, to prevent a malicious host from injecting a high replay counter value.
During hash computation, the 'hops' field MUST be set to zero (its value may change in transmission) and the 'giaddr' field MUST also be set to zero (it may be modified by intermediate relay agents). The Authentication Information field is set to all zeros during computation.
If a relay agent generates a Relay ID value, it SHOULD select a value that it can regenerate reliably across reboots (e.g., based on MAC or IP address).
If checksums do not match, the receiver MUST drop the message. If they match, the receiver updates its notion of the last valid Replay Detection value and processes the message.
Receivers MUST discard messages containing RDM values they do not support, and if the Replay Detection value is not valid, the receiver MUST drop the message.
Receivers SHOULD perform the replay-detection check before testing the checksum, because the keyed hash calculation is likely to be much more expensive than the replay-detection value check.
Relay implementations SHOULD support a configuration that indicates all relayed messages should include the authentication suboption, and use of the authentication suboption SHOULD be disabled by default.
The receiver MUST support a configuration that allows it to drop incoming messages that do not contain a valid relay agent information option and Authentication suboption.
Algorithm 1 (HMAC-SHA1) requires a shared secret key configured at both relay agent and DHCP server. A 32-bit Key ID identifies which shared key was used; Key ID values are locally significant only and carry no protocol-level semantics.
The Relay Identifier field provides a stable sender identity for relay agents that do not set giaddr. Servers use giaddr preferentially, then Relay ID if giaddr is unset, for associating per-sender state such as Key ID and replay-detection counters.
The Replay Detection Method (RDM) field is a 4-bit value. RDM value 0 is reserved; RDM value 1 (default) specifies that the Replay Detection field contains a monotonically increasing counter. Receivers associate a replay counter with each sender and reject messages with a counter value less than or equal to the last valid value.
IANA created a new suboption code (8) in the DHCP relay agent option suboption number space for the Authentication Suboption, and two new number spaces: Algorithm (1-byte, value 0 reserved, value 1 = HMAC-SHA1) and Replay Detection Method (4-bit, value 0 reserved, value 1 = monotonically increasing counter). New values assigned through IETF consensus.
Because DHCP uses UDP, messages may be delivered out of order. The replay-detection mechanism will cause receivers to drop late-delivered packets, leading to client retries and wasted computational work by senders whose messages were reordered.
The protocol adds computational burden (cryptographic hash calculations) to relay agents and servers, potentially adding latency to DHCP exchanges. This burden is highest during mass reboot events such as a cable MSO head-end reboot, which can increase the time required to serve all clients.
The Authentication Suboption has code 8 and contains: 1-byte Algorithm, 4-bit MBZ, 4-bit RDM, 64-bit Replay Detection, variable-length Relay Identifier, and variable-length Authentication Information fields. The length field covers algorithm, RDM, and all subsequent fields in octets.
When Algorithm 1 (HMAC-SHA1) is used, the suboption length is fixed at 38. The Authentication Information field contains a 32-bit Key ID followed by a 160-bit HMAC-SHA1 result.