Internet Engineering Task Force R. G. Moskowitz Internet Draft Chrysler Corporation Expires in six months February 6, 1998 Network Address Translation issues with IPsec Status of this Memo This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document looks at a number of issues surrounding the need for network address translation (NAT) when IPsec is used to create virtual private networks (VPN). This document only looks at simple VPNs. That is VPNs consisting of a single IPsec tunnel as compared to VPNs consisting of ‘chained’ and/or ‘nested’ IPsec tunnels and/or transports. It proposes a method to vastly reduce the extent that NAT is needed in a VPN. R. Moskowitz [Page 1] Internet Draft NAT issues with IPsec February 5, 1998 Table of Contents 1. Introduction..............................................2 1.1 Requirements...........................................2 2. Network Description.......................................3 3. Addressing for VPN Servers................................3 3.1 Sample DNS entries for VPN Servers.....................4 3.2 Internal addressing and routing in VPN Server networks.4 3.3 Internal routing in VPN Client networks................4 3.4 Sample Process flow....................................4 4. Tunnel discovery the KX record............................5 4.1 KX Process flow........................................5 4.2 Alternatives to the KX record..........................6 5. IANA functions............................................6 6. Security Considerations...................................6 7. References................................................6 8. Acknowledgments...........................................6 9. Author's Addresses........................................6 1. Introduction This document proposes a methodology to produce simple to manage Virtual Private Networks (VPNs). It assumes that the VPNs are constructed of tunnels (IP or link layer in IP) between IP networks across an internet. If proposes a variant of ‘Address Allocation for Private Internets’ [RFC 1918] to minimize the need of Network Address Translation (NAT). The name NET66 has nothing to do with the addresses used in this document, network 7 is used as the example network that IANA would assign and manage for this VPN methodology. Rather NET66 is an allusion to the per-interstate road across the US, Route 66. Route 66 was a defined path across the western half of the US. People planned their entrance and exit points from Route 7. Likewise, NET66 means some planning for entrance and exit from the VPN, but the expectation of a smooth trip over it. 1.1 Requirements The Design objectives are: All servers in the VPN are globally addressed. The servers need not be globally routable: R. Moskowitz [Page 2] Internet Draft NAT issues with IPsec February 5, 1998 Server addresses need to be routable in the server’s network. Server addresses need to be default or statically routed to the VPN gateway on the client’s network. The clients need a name they can resolve that yields an address that will route to the client’s gateway. The clients gateway needs to discover the server’s gateway’s address with only the server’s address as a clue. 2. Network Description The following diagram will be used in this discussion as a sample VPN of a community of interest. a.com b.com Host(1)-----| |-----Server(a) | | Host(2)-----|---- GW(1)-------------GW(2) ----|-----Host(3) | | | Server(b)---| | |-----Server(c) | | c.com | d.com | | Host(4)-----| | |-----Server(d) | | | Host(5)-----|---- GW(3)-------------GW(4) ----|-----Server(e) | | Server(f)---| |-----Host(6) 3. Addressing for VPN Servers If Srva.b.com has a global address then Host1.a.com can resolve the name to the address. A.com will have to have a route for this address to GW1. If all the VPN accessible servers are addressed out of the same block, then a.com only needs one route to GW1 for all servers accessed by host1.a.com. Since all of the traffic to the servers is within the VPN tunnels these addresses need not be routable R. Moskowitz [Page 3] Internet Draft NAT issues with IPsec February 5, 1998 on the internet, they only need be registered in the internet’s DNS. 3.1 Sample DNS entries for VPN Servers Assume that the block of addresses for VPN Servers is 7.0.0.0/8. If the 4 companies in section 2 received an allocation of 2 addresses the DNS entries might look like: Srvb.a.com IN A 7.0.1.1 Srva.b.com IN A 7.0.2.1 Srvc.b.com IN A 7.0.2.2 Srvf.c.com IN A 7.0.3.1 Srvd.d.com IN A 7.0.4.1 3.2 Internal addressing and routing in VPN Server networks The addresses in 3.1 would be used both in the public DNS and as the actual address on the servers. The router adjacent to the server would advertise a unique route for the server (e.g. 7.0.1.1/32). This way the packets will reach the server as they emerge from the gateway without any address translation required. 3.3 Internal routing in VPN Client networks The client networks (e.g. a.com for host1.a.com) advertise a route of 7.0.0.0/8 directed to their gateway. 3.4 Sample Process flow Host1.a.com needs to connect to a TCP application on Srva.b.com. Host1 performs a DNS lookup and gets the address 7.0.2.1. Host1 (assume its address is 192.168.50.2) sends out a TCP SYN sourced from 192.168.50.2, destined for 7.0.2.1. A.com’s network routes this packet into GW1 since it has a route to 7.0.0.0/8. GW1 (whose public address is 199.175.30.1) has a policy (see sec 4) that a destination of 7.0.2.1 is tunneled to 208.50.1.1 (GW2’s public address). GW1 places the packet it received into an IP packet sourced from 199.175.30.1, destined for 208.50.1.1. The internet routes this packet to GW2. GW2 removes the internal packet. Since the source address is a private R. Moskowitz [Page 4] Internet Draft NAT issues with IPsec February 5, 1998 address, GW2 MUST translate this address to an address usable within b.com (for example for the pool of 172.17.1.0/24). This requirement is based on the likelihood of GW2 having two or more tunnels from different hosts, all having the same private address. If the source address had been a public address, GW2 COULD have left the address unchanged if b.com’s network is able to route that address (as a destination address) back to GW2 (this is a site option). GW2 now delivers the packet into b.com’s network. B.com’s network routes this packet to Srva since there is a route to 7.0.2.1. Srva reverses the source and destination addresses and creates an SYN/ACK. B.com’s network routes this packet back to GW2. GW2 reverses the address translation on the destination address (if it performed one) and places the packet into an IP packet sourced from 208.50.1.1, destined for 199.175.30.1 (that is GW1). The internet delivers this packet to GW1. It removes the inner packet and puts it on a.com’s network. A.com’s network delivers the packet to Host1. 4. Tunnel discovery the KX record A key point in section 3.4 is GW1 ‘knowning’ that a packet destined for 7.0.2.1 was to be tunneled to 208.50.1.1. This could be done via manual configuration; that is GW1’s administrator had set up a rule accordingly. This method is easy to deploy on a small scale, but is not usable in a large context. An alternative is for GW1 to be able to process DNS KX records [RFC 2230]. Consider the following DNS records: Srva.b.com. IN A 7.0.2.1 IN KX 10, gw2.b.com. 1.2.0.7.in-addr.arpa. IN A Srva.b.com. gw2.b.com. IN A 208.50.1.1 4.1 KX Process flow A configuration option on GW1 starts the KX processing if the destination address is 7.0.0.0/8. GW1 does a reverse lookup on the destination address of 7.0.2.1 and gets Srva.b.com. It next does a lookup for a KX record for Srva.b.com and gets gw2.b.com. Finally it does a lookup up on gw2.b.com and gets 208.50.1.1 as the tunnel end point. R. Moskowitz [Page 5] Internet Draft NAT issues with IPsec February 5, 1998 Since KX processing’s purpose is to retrieve VPN configuration information, all of these queries MUST be secured with DNSSEC. This, plus the three DNS queries might be considered as a drawback to using the KX record. Another drawback in the KX record is that it does not supply any tunnel policy information, like a hint at what type of tunneling technology or parameters to use. 4.2 Alternatives to the KX record There are many alternatives to the KX record. SRVLOC, LDAP directory, and Attribute Certificates have all been proposed. Attribute certificates have the security needs stated above built into them. A full analysis is needed to select a better alternative to the KX approach. 5. IANA functions IANA will reserve a large block of addresses, a /8 is recommended (and might not be enough until IPv6 is deployed eliminating the need of NET66). IANA will develop the processes and procedures for an organization to license addresses from this block for their VPN accessible servers. 6. Security Considerations Network address translation, in conjunction with IPsec makes some large assumptions of trust. Intermediate systems are changing IP addresses on behalf of other systems. The KX record relies on the deployment of DNSSEC, without this it cannot be trusted. In fact the whole global server address block and its reverse lookup block needs to be secured with DNSSEC as well. 7. References [RFC 1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear ‘Address Allocation for Private Internets’ [RFC 2230] R. Atkinson ‘Key Exchange Delegation Record for the DNS’ R. Moskowitz [Page 6] Internet Draft NAT issues with IPsec February 5, 1998 8. Acknowledgments This document is based on discussions with Mark Johnson and Mike Papais of Chrysler Corporation, along with a host of others at the the Automotive Industry Action Group (AIAG) and within the IETF community. 9. Author's Addresses Robert G. Moskowitz rgm@icsa.net ICSA, Inc. R. Moskowitz [Page 7]