Update Changes from draft –07 –Added references to IPSRA requirements draft, updated other references –Improved consistency of terminology –Added language on use of the assigned address in the quick mode exchange Issues –Use of assigned address in quick mode exchange –Tear down or reuse of the DHCP SA –New htype for VPN –Contents of client-identifier option
Configuration Requirements To obtain an IP address and other configuration parameters appropriate to the class of host To reconfigure when required To support failover –Want to be able to maintain address/configuration state between VPN server failures To integrate with existing IP address management facilities such as DHCP –Want single point of address and configuration management
Security Requirements To support address pool management –Examples Extranet where vendors, contractors, employees have different access levels, allocated out of different address pools Intranet where sales, marketing, engineering have different quality of service levels, allocated out of different pools To authenticate where required –Since DHCP server typically not co-located with VPN server, can’t assume access to IKE credentials –DHCP authentication required to prove claim of identity in the client-identifier-option
DHCP Packet Body Hardware address length (hlen), hardware type (htype), client hardware address (chaddr) –Should be unique to the segment client is connecting to –Hardware identifier tells VPN server/DHCP relay which VPN interface to forward DHCP messages to Client-identifier-option isn’t returned by DHCP server –LAN: Use interface hardware address –Dialup with no LAN adapter Use outer IP address + 2 random octets Issue: Not consistent between reboots, would cause new configuration to be returned on reboot Should a different htype be used for VPN? –Would make it easier for DHCP server to distinguish VPN clients
DHCP Options Client-identifier-option –Must be unique to client –Consistency between reboots helpful –Can use Htype/Chaddr combination as suggested in RFC 2132 If a LAN interface exists, can use Chaddr from that interface With no LAN interface (dialup case) can use IP address + two random octets –Not consistent between reboots, makes it difficult to support user or machine specific policies –Can use FQDN or NAI + interface number Consistent between reboots Makes it easier to administer DHCP authentication than using htype/chaddr; don’t want to change keys when LAN card changes Classless static route option –Draft-ietf-dhc-csr-03.txt –Replacement for RFC 2132 static route option
Address Pool Selection Support for existing methods for address pool selection –Client hardware address –Client-identifier option –Vendor-class-identifier option –Vendor-specific information option –Relay agent option –User class option –Subnet selection option –Host name option –Authentication option Can leverage conditional behavior of popular DHCP servers DHCP (even with authentication) is not an Access Control mechanism –Shouldn’t use address assignment as a way of restricting access; client can just choose its own IP address and get around the restrictions
Walkthrough The remote host establishes an IKE MM or AM security association with the VPN server. The remote host establishes a DHCP tunnel mode QM SA with the VPN server. –Filters From client to server: Any to Any, destination: UDP port 67 From server to client: Any to Any, destination: UDP port 68 DHCP messages are exchanged between the remote host and the DHCP server, using the VPN server as a DHCP relay, configuring the intranet interface of the remote host. –Security gateway needs to snoop the DHCPACK to learn the IP address assigned to the VPN interfaces The remote host MAY request deletion of the DHCP SA or the remote host and VPN server MAY continue to use the same SA for all subsequent traffic by adding temporary SPD selectors as with name ID types. The remote host establishes a tunnel mode SA to the VPN server in a quick mode exchange.