Realm-Specific IP for VPNs and Beyond - continued

Combining RSIP and IPsec
At first glance, RSIP sounds like a promising way for hosts to share public addresses while avoiding the pitfalls associated with applying NAT to IPsec traffic. But it turns out that there are RSIP extensions needed to accommodate end-to-end IPsec.

Basic RSIP relies on unique port numbers to demultiplex arriving packets. But IPsec ESP encrypts port numbers. When several RSIP hosts use the same RSIP gateway to relay ESP, another discriminator is needed. Fortunately, every IPsec packet carries a unique security-parameters index (SPI), assigned during security association setup. Unfortunately, the SPI is only guaranteed unique for the responder. To enable demultiplexing, the SPI + protocol (AH or ESP) + destination IP address must also be unique at the initiating RSIP gateway.

A similar problem occurs during association setup with the Internet Key Exchange (IKE). IKE packets usually carry a well-known source port 500. Using different source ports is the preferred solution. But if several RSIP hosts use the same RSIP gateway to relay IKE from port 500, another discriminator is needed. Again, there is a handy answer: every IKE packet carries the initiator cookie supplied in the first packet of an IKE session. The RSIP gateway can route IKE responses to the correct RSIP host using initiator cookie + destination port (IKE) + destination IP address.

To fix these problems, RSIP extensions have been proposed to the IETF, allowing RSIP hosts to register with an RSIP gateway for IPsec support, and allowing hosts to request and receive unique SPI values along with leased IP addresses and ports.

Possible service applications for RSIP
RSIP specifications are still at the Internet Draft stage. Support in commercial product is a down the road a ways. But if and when RSIP matures, it may represent a new revenue opportunity for ISPs. One can envision a provider running RSIP gateways, doling out IPs from its public block and charging on a per-use basis. RSIP might be involved in a wide variety of service offerings:

• Residential power-users and teleworkers with multi-host LANs that share a single IP leased by an RSIP-enabled Internet appliance, DSL router, or cable modem;
• Small-to-midsize enterprise customers with dozens or hundreds of hosts, sharing a small pool of public IPs leased by an RSIP-enabled WAN access router or firewall;
• Multi-dwelling units (apartments, shared office buildings) with many private LANs, sharing public Internet access through an RSIP-enabled device;
• Hospitality networks (airports, hotels) where roaming hosts briefly lease the public IP(s) shared by the entire network;
• Remote access concentrators that use RSIP to lease private IP(s) to roaming corporate users that access the Internet via dynamically-assigned public addresses; and
• Wireless devices (cell phones, PDAs) that lease public IP(s) for "sticky sessions" that persist even when the mobile device moves from one location to another, updating its local access IP.

These scenarios, and RSIP's relationship to IP multicast and differentiated services, are more fully explored in the RSIP architecture Internet Draft.

Parting thoughts
When the public Internet is leveraged for private business communication (as in many of these scenarios), VPN support becomes important. While NAT can be used in certain VPN scenarios, it tampers with end-to-end message integrity. RSIP—or whatever RSIP evolves into—may someday prove to be a better address-sharing solution for IPsec-based VPNs. And strategically placed RSIP gateways may someday also create new revenue opportunities for ISPs that extend beyond the realm of VPN.

—End

back to page 1
Related article: IP Security and NAT: Oil and Water?