Internet Engineering Task Force R. G. Moskowitz
Internet Draft Chrysler Corporation
Expires in six months February 6, 1998
Network Address Translation issues with IPsec
<draft-moskowitz-net66-vpn-00.txt>
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
servers network.
Server addresses need to be default or statically
routed to the VPN gateway on the clients network.
The clients need a name they can resolve that yields an
address that will route to the clients gateway.
The clients gateway needs to discover the servers
gateways address with only the servers 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
internets 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.coms 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 (GW2s 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.coms
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.coms network.
B.coms 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.coms 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.coms network. A.coms 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 GW1s
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 processings 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]