The Remote Access Conundrum Part 3: Dynamic Addressing—continued

Without End-to-End PPP

With IPsec, remote clients dial Internet access servers at ISP POPs; packets are routed in the normal fashion to an IPsec Security Gateway (SG). The SG is usually customer premises equipment—an IPsec-enabled firewall, router, or other device at the edge of the corporate network. Only the endpoints—the remote client and SG—perform IPsec processing.

IPsec tunnels encapsulate private IP packets inside public IP wrappers. As such, there are actually two sets of addresses—inner and outer. Outer packet source and destination addresses identify the client and SG. Inner packet addresses identify the client and the ultimate destination inside the corporate network.

IPsec clients receive outer packet source addresses from Internet access servers, but this address comes from the ISP's block. Current IPsec standards do not dictate inner packet source address. Some IPsec clients simply set the inner address to the outer address. When inbound packets reach the SG, the outer packet is removed, leaving the inner packet with a foreign source address. Without a local address, the remote client is an outsider, blind to broadcasts and possibly crippled by existing IP-based ACLs (below).

(Click image to see full view.)

Enabling dynamic assignment To overcome this, many IPsec SG vendors have implemented proprietary extensions. They create a configurable address pool at the SG and communicate dynamic addresses to remote clients. However, because PPP does not run end-to-end, the address cannot be carried by IPCP. And the Internet Key Exchange (IKE) used to establish IPsec tunnels was not originally designed to carry addresses. Several vendors implemented a proposed IKE extension known as Configuration Mode (IKECFG). By inserting a new IKE transaction exchange into the middle of tunnel setup, IKECFG lets the SG supply the remote client with IPv4 and IPv6 address assignments, netmasks, and DNS/DHCP server addresses.

Why not leverage DHCP?
IKECFG solves the basic problem, but failed to gain industry consensus. Detractors argue that IKECFG replicates functionality already provided by the Dynamic Host Configuration Protocol (DHCP).

Defined by RFC 2131, DHCP lets IP hosts automatically obtain network configuration parameters from a nearby server. DHCP is widely used to manage dynamic IP address assignments in corporate LANs. DHCP servers lease IP addresses to DHCP clients; they can also supply parameters like netmask, DNS server, and default router. Standard extensions to DHCP are being developed to accommodate load balancing, fail-over, and user classification.

Combining DHCP and Ipsec
Intel, Microsoft, RedCreek, and Sun are among those proposing to combine IPsec with existing DHCP services. DHCPv4 Configuration of IPsec Tunnel Mode leverages DHCP to assign dynamic network addresses to IPsec clients. This soon-to-be standard IPsec extension solves the "virtual presence" problem in three steps.

First, a bootstrap IPsec tunnel is established, allowing the remote client to communicate securely with a DHCP server, located somewhere inside the corporate network. Next, DHCP is used in the typical fashion to lease an IP address to the remote client. Finally, other IPsec tunnels are created for communication between the remote client and destinations inside the corporate network. The client uses the leased address as the inner packet source address.

By reusing the familiar, this solution is easily integrated with existing DHCPv3 and v4 address management facilities. DHCP servers that support the User Class option make it possible to assign client addresses from different pools, based on user identity. For example, the DHCP server may lease finance department users addresses from a specified range, simplifying departmental server ACLs. By separating address management from tunnel management, clients can conceivably keep the same leased address when recovering from transient tunnel or IPsec SG failures. As DHCP itself becomes more robust, new featureslike DHCP support for IPv6—can be leveraged by IPsec remote access clients.

Knowledge is power
Remote access VPNs based on L2TP may incorporate dynamic addressing, but will not satisfy every customer. Remote access VPNs based on IPsec—either alone or in conjunction with L2TP—require more careful planning:

1. Be aware that vendor approaches to IPsec client addressing differ. Make no assumptions. Look closely at the dynamic addressing capabilities provided by each platform.
2. Vendor extensions, however necessary, can impact multi-vendor interoperability. Dynamic addressing is yet another reason to use vendor-matched IPsec clients and security gateways, avoiding mix-and-match scenarios.
3. When selecting an IPsec platform with dynamic address management, consider how the platform will integrate with customer networks. Are address ranges constrained? Can address pools be associated with user groups? Can addresses be assigned by corporate DHCP servers? If so, what DHCP version or options are required? What other network configuration parameters can be propagated to remote clients?
4. Analyze customer networks to identify address dependencies. If you can't give remote clients a "virtual presence" on your customer's network today, work with the customer to identify changes required to corporate access lists and routes.

Administering these changes may not be your problem, but helping your customer understand what will be needed is simply good business.

Back to page 1:
< The Remote Access Conundrum Part 3: Dynamic Addressing

   

Related articles:
	The Remote Access Conundrum Series:
	[Jan. 5, 2000]	Part 1: Extended Authentication
	[Dec. 20, 2000]	Part 2: Tunneling at Layer Two
	[Feb. 8, 2001]	Part 3: Dynamic Addressing
	[Mar. 15, 2001]	Part 4: VPN Client Administration