Security of Messages Exchanged between Servers and Relay Agents
Extracted elements (20)
Public key schemes MAY be optional for key management because both relay agents and servers tend to be managed by a single organizational entity, making pre-shared secrets with IKEv2 sufficient in many deployments.
This specification was motivated by concerns about pervasive monitoring (RFC 7258) and other attacks. Sensitive data in relay messages — such as the DHCPv4 Relay Agent Information option (82), vendor-specific information, and Access-Network-Identifier options — must be protected.
DHCPv4 (RFC 2131) and the Bootstrap Protocol (RFC 1542) have no existing guidance for securing relay-to-server messages; this document fills that gap by requiring IPsec with encryption for DHCPv4 relay-to-server communication.
This specification replaces the text in Section 21.1 of RFC 3315 (DHCPv6) when followed. RFC 3315 stated IPsec should be used but did not require encryption; this document upgrades that to a MUST with encryption required.
DHCP messages between relay agents and servers MUST only be accepted from DHCP peers as identified in the local configuration.
Each relay agent and server using IPsec MUST also be configured with a list of the relay agents to which messages will be returned. IPsec selectors are pairs of addresses with direction of DHCP message exchange on DHCPv4 UDP port 67 or DHCPv6 UDP port 547.
For DHCPv6, relay and server implementations MUST support IPsec encryption of relay-to-relay and relay-to-server communication. For DHCPv4, relay and server implementations MUST support IPsec encryption of relay-to-server communication.
IKEv2 with pre-shared secrets SHOULD be supported for key management, as manually configured keys do not provide defense against replayed messages. IKEv2 with public keys MAY be supported.
Operators are RECOMMENDED to enable IPsec for relay-to-relay and relay-to-server DHCP communication.
Relay agents and servers MUST be able to exchange messages using the IPsec mechanisms described in RFC 4301. In a relay chain, each relay agent MUST have established independent, pairwise trust relationships with adjacent hops.
Relay agents and servers MUST use IPsec in transport mode with Encapsulating Security Payload (ESP); tunnel mode is not used for this communication.
Relay agents SHOULD be configured to forward DHCP messages to unicast addresses, because using IPsec with multicast has additional complexities (see RFC 5374).
This document REQUIRES combined mode algorithms for ESP authenticated encryption, ESP encryption algorithms, and ESP authentication algorithms as per Sections 2.1, 2.2, and 2.3 of RFC 7321, respectively.
By using IPsec with encryption, potentially sensitive client message data and relay-included information — such as the DHCPv4 Relay Agent Information option (82), vendor-specific options, and Access-Network-Identifier options — are protected from pervasive monitoring and other attacks.
Authentication uses shared keys indexed to the source IP address of the received DHCP message, which is considered adequate for relay-to-server DHCP message authentication.
Manually configured key management MAY be used but does not provide defense against replayed messages, as sequence numbers cannot be negotiated and manual keys tend to be long-lived.
Even when DHCP traffic between relays and servers is encrypted on the wire, unencrypted data may still be accessible through attacks on DHCP servers, relays, or related systems. Security of databases, logs, and network transfers of that data must also be considered.
IPsec as described in this document is also applicable to Lightweight DHCPv6 Relay Agents (RFC 6221), as they have a link-local address that can be used to secure communication with their next-hop relay(s).
Manual key management has two known limitations: replay protection cannot be provided because sequence numbers cannot be negotiated, and long-lived manual keys give attackers time to discover them.
The security model is hop by hop. For DHCPv6, each relay-to-relay and relay-to-server hop must be individually secured. The exchanges between clients and the first-hop relay agent or server are not secured by this specification.