Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode
Extracted elements (27)
By keeping configuration and addressing state on the DHCP server rather than in the IKE implementation, loss of a tunnel server does not result in loss of addressing state, making failover significantly easier to support. IKECFG creates a separate pool of address state that complicates failover provisioning.
DHCPv4 was chosen over IKECFG because IKECFG does not meet basic IPsec remote access configuration requirements: it lacks configuration leases, reconfiguration support, address pool management, and integration with existing IP address management facilities. Past experience with PPP IPCP demonstrated that minimal configuration mechanisms inevitably duplicate the functionality of DHCP.
The htype field is set to 31 (IPsec tunnel mode virtual interface) to allow the DHCP server to differentiate VPN from non-VPN requests, enabling address pool management where the remote host can be assigned an address from the appropriate corporate address pool.
The mechanisms described work best when the VPN is implemented using a virtual interface, giving the remote host two addresses: an Internet interface address (used as outer IPsec tunnel header) and a virtual intranet interface address (used as inner header), enabling full corporate network presence semantics.
No new DHCPv4 options and no modifications to DHCPv4 (RFC 2131) are required for IPsec tunnel mode configuration, because the required configuration parameters are a subset of those already supported in DHCPv4 options (RFC 2132).
Since the DHCPDISCOVER packet has a broadcast address destination, the IPsec implementations on both the remote host and the security gateway must be capable of handling broadcast-destined packets within an IPsec tunnel.
Where allocating a separate subnet per tunnel is not feasible and the DHCP server does not support the Relay Agent Information Option, stateless relay behavior is not possible; implementations MAY devise a mapping between xid, chaddr, and tunnel, though this creates substantial state on large VPN servers.
It SHOULD be possible to configure the remote host to forward all Internet-bound traffic through the tunnel, allowing the corporate security gateway to filter traffic as if the host were physically on the corporate network.
Since DHCP Relays are stateless, the security gateway SHOULD insert appropriate information in the DHCP message prior to forwarding to DHCP servers so it can route DHCPOFFER responses back to the correct IPsec tunnel without maintaining per-discovery state.
The assigned DHCP address MUST NOT be depended upon for security. A remote host can always set its own IP address and thus evade any security measures based on DHCP authentication; the security gateway MUST use per-tunnel packet filters or quick mode selectors instead.
The broadcast bit in the DHCPDISCOVER flags field MUST be set to zero for IPsec tunnel mode operation.
The chaddr field of the DHCPDISCOVER MUST include an identifier unique to the virtual subnet. The client MUST use the same chaddr field in all subsequent messages within the same DHCPv4 exchange.
The chaddr SHOULD be persistent between reboots so the DHCP server can re-assign the same address. For LAN interfaces, chaddr SHOULD be derived from the active LAN interface with the lowest interface number.
The client-identifier option MUST be included in DHCPv4 configuration of IPsec tunnel mode, MUST be unique within the virtual subnet, and SHOULD be persistent across reboots.
The DHCP SA MUST only be used for DHCP traffic. It is a temporary IPsec tunnel mode SA established solely to protect initial DHCPv4 traffic between the security gateway and the remote host.
The key lifetime for the DHCP SA SHOULD be on the order of minutes since it is only temporary. The remote host SHOULD use an IDci payload of 0.0.0.0/UDP/port 68 in the quick mode exchange.
The new address assigned via DHCPv4 SHOULD be used in the quick mode ID when establishing the new IPsec tunnel mode SA after DHCP configuration completes.
After DHCPACK processing, the remote host establishes a new IPsec tunnel mode SA using the assigned virtual address. All future DHCP messages (DHCPREQUEST, DHCPINFORM, DHCPDECLINE, DHCPRELEASE) and server messages (DHCPOFFER, DHCPACK, DHCPNAK) then flow over this new VPN SA.
The DHCP SA is a temporary IPsec tunnel mode SA established in IKE quick mode to protect initial DHCPv4 traffic. Its filters allow UDP port 67 (server) and UDP port 68 (client) traffic in each direction, working for both new DHCPDISCOVER and renewal DHCPREQUEST messages.
The security gateway acts as a DHCPv4 relay, inserting its address in the giaddr field and relaying packets between the client and the DHCP server. It does not request or renew addresses on the client's behalf. It snoops the yiaddr field in DHCPACK to learn the client's assigned address and plumb routes.
This document requires allocation of htype value 31 in the IANA arp-parameters registry to signify an IPsec tunnel mode virtual interface, used in the htype field of BOOTP/DHCP messages. No new IANA number spaces are created.
Authenticated DHCP cannot serve as an access control mechanism because a remote host can set its own IP address and evade DHCP-based security measures. The assigned address MUST NOT be depended upon for security; per-tunnel packet filters or quick mode selectors must be used instead.
DHCP packets between the remote host and security gateway are authenticated and integrity protected by IPsec. However, no protection is afforded the DHCP packets between the security gateway and the DHCP server unless DHCPv4 authentication (RFC 3118) is also used.
Forwarding DHCP client requests from untrusted sources exposes the network to DHCP exhaustion attacks and spoofing of the client-identifier option or client MAC address. These risks can be partially addressed through the DHCP Relay Agent Information Option (RFC 3046).
Configuration proceeds through five steps: (a) establish IKE Phase 1 SA; (b) establish DHCP tunnel mode SA via quick mode; (c) exchange DHCP messages over the DHCP SA to obtain virtual address; (d) optionally delete DHCP SA or retain it; (e) establish new tunnel mode SA using the assigned address. The remote host is ready to communicate with the intranet after step (e).
The DHCPDISCOVER message for IPsec tunnel mode sets htype (1 octet) to value 31 to signify a virtual IPsec tunnel mode interface, enabling the DHCP server to differentiate VPN from non-VPN requests. The flags field (2 octets) must have the broadcast bit set to zero. The giaddr (4 octets) holds the security gateway interface IPv4 address.
When no LAN interface is present, the chaddr field SHOULD be constructed by concatenating x'4000' (indicating a locally administered unicast MAC address), the IPv4 address of the interface supplying connectivity, and an additional persistent octet (MAY represent an interface number).