One document matched: draft-tsirtsis-aatn-mech-00.txt
INTERNET DRAFT George Tsirtsis
Richard O'Brien
Martin Tatham
Alan O'Neill
BTLABS
April 1998
Possible Mechanisms and Components for AATN
<draft-tsirtsis-aatn-mech-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 are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not appropriate to
use Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
Abstract
This document attempts to list mechanisms that if added to the
Internet protocols could take us some way in providing well
desirable alternatives and improvements to NAT. Some of the
techniques and components described here are controversial and
their appearance in this document does not mean that the author
supports them. We merely attempt to list the options and issues
(most of them already known) as a starting point for an elimination
and selection process.
Tsirtsis et.al. [Page 1]
Internet Draft AATN Components & Mechanisms April 1998
Index
0. Introduction
1. A simple Tunneling alternative to simple NAT
2.Host Tunneling to a gateway
2.1. Internal NAT-Bypass
2.2. External NAT-Bypass
2.3. DNS triggered address allocation
3. Tunneling between gateways
4. How the end host knows to use public addressing:
4.1. By simple host ‘routing’ table (prefix or domain based)
4.2. By DNS query trigger
4.3. ICMP trigger for all external traffic
4.4. ICMP trigger for end-to-end sensitive traffic
4.5. Gateway initiated tunnels (back to the end-host)
5. Summary of Components
6. Security Considerations
7. References
0. Introduction
Section 1,2 and 3 explain the various mechanisms that use tunneling
as a main tool in an attempt to provide alternatives to NAT. Note
the similarities between the proposals.
Section 4 explains lists mechanisms that may answer the question
“How the end host knows to use public addressing (as opposed to
private)”.
Section 5 summarises possible changes to existing protocols or
requirement for new ones as a result of this study.
Note that there is no section on “How you find a tunnel end point”
but the issue is discussed throughout the document.
We apologise in advance if we missed (and I am sure we did :) or
misinterpreted (and I hope we did not :) any of the existing
proposals.
Tsirtsis et.al. [Page 2]
Internet Draft AATN Components & Mechanisms April 1998
1. A simple Tunneling alternative to simple NAT
A number of proposed solutions focus on the requirement of not
changing the end host stack. This is supported by the fact that if
you change the host, then the change should involve IPv6.
These solutions invariably involve some form of tunneling. The idea
is that since the host does not change (it things that all
addresses are unique and reachable) some other box needs to act on
its behalf. This philosophy of transparency to the end host was
also adopted by NAT and that is partly why it became so successful.
The alternative proposals use a typical router with tunneling
capabilities instead of a NAT router. These “tunneling routers”
encapsulate or decapsulate instead of translating using more or
less the same kind of addresses internally and externally that NAT
does.
The example given here assumes a hostA in a private network is
trying to communicate with a host in the Internet.
In the NAT case:
HostA---Private NET10---NAT -----------Internet--------HostB
10.0.0.1 Pool: 164.193.10.1 x.x.x.x
host A send packet: ---> NAT translates to:
SA DA SA DA
10.0.0.1 x.x.x.x 163.193.10.1 x.x.x.x
In the Tunneling Router (TR) case:
Tunnel
<============================>
HostA---Private NET10--TR -------------Internet--------HostB
10.0.0.1 Pool: 164.193.10.1 x.x.x.x
host A send packet: ---> TR tunnels to:
Original Packet Tunnel
SA DA SA DA | SA DA
10.0.0.1 x.x.x.x 10.0.0.1 x.x.x.x | 163.193.10.1 x.x.x.x
This apparently avoids translation providing that:
a) the destination host can terminate tunnels
b) the destination host has a global Internet address
It can be argued that this solution covers a large number of cases
where NAT is used today; that is, as a gateway from a private
Tsirtsis et.al. [Page 3]
Internet Draft AATN Components & Mechanisms April 1998
network to the global Internet. The obvious problem, however, is
that it requires the end host to support tunnel termination.
Note that wile tunnel termination on clients may require changes to
hosts, tunnel termination on servers may be much easier and it
probably conforms better to their specs (L2TP tunnels are designed
to also terminate on servers; they could easily also terminate
IPinIP, IPSEC, mobile IP etc).
Applicability
- A private network using private addresses and requires to
communicate with the global Internet. Note that the addresses used
by the private network should be from the designated blocks of
addresses that have been assigned for private use (e.g.: NET10). If
global but not registered addresses are used the technique will
fail if (and only if) the source address overlaps with the address
of the destination host. Note that if the destination host address
is not the same with that of the originating private host the
technique will work since the tunnel isolates this address from the
Internet.
- Accessing WWW, IRC, ftp, video, audio, mail, IPsec? etc globally
reachable servers from a private network could be done this way.
Problems
- How do you know a server supports tunnel termination and if yes,
what kind of tunneling (L2TP, mobile IP, IPSEC, IPinIP etc)? One
way is to first try tunneling (whichever the TR supports) and if
not succeed use NAT? This is obviously a hit and miss approach;
discovery mechanisms (often complicated) have been proposed but
here we try to provide a simple solution. Could a “tunnel type”
negotiation help here? Is there any available but even if there is,
it involves even more changes...
- How many global IP addresses the TR needs for the tunnels? Some
tunneling protocols will allow the use of a single IP address for
all tunnels (L2TP can mux on UDP port numbers), others (e.g IPinIP)
may need one per tunnel?
- Though any requirement for change should be targeting networks
that are “misbehaving” (in this case by using private addressing)
the described proposal requires servers to add tunneling
capabilities to their tack. Some servers do that anyway but the
ones who do not can do it in a case by case bases. After all
servers are there to serve and the above technique only increases
the amount of hosts that can be served by them...
2.Host Tunneling to a gateway
Tunneling to the gateway of a private network (from inside and/or
Tsirtsis et.al. [Page 4]
Internet Draft AATN Components & Mechanisms April 1998
from outside the private network) has been discussed in a number of
proposals. The basic idea is the following:
Tunnel Tunnel
<=================> <============================>
HostA---Private NET10--TR -------------Internet--------HostB
10.0.0.1 Global Pool: 164.193.10.1 x.x.x.x
Private Pool: 10.0.0.3
A host in the private network or the global internet tunnels to a
gateway to the global Internet or the private network respectively.
This allows the host to get an address from the corresponding
network (if it does not already have on, as in mobile IP) and
communicate with hosts inside this network (private or Internet).
There are few proposals that use a variety of techniques to allow
that.
2.1. Internal NAT-Bypass
One of them [NATB], allows a host in the private network to build
an L2TP tunnel to its Internet gateway and be assigned a global
address from the pool of addresses available to the gateway (as in
NAT). This address can now be used for end-to-end communication
with the external hosts.
HostA---Private NET10--TR -------------Internet--------HostB
Set tunnel
--------------------->
assign global addr
,---------------------, (tunnel to TR))
(<--------------------- )
‘---------------------‘
end-to-end communication with global address
,----------------------, (tunnel to TR)
(<-------------------------------------------------------->
‘----------------------‘
Note that, the tunnel, after the address assignment phase, may not
be used if the private network supports global routing as suggested
by Jim Bound.
2.2. External NAT-Bypass
The same could be done from the other side:
Tsirtsis et.al. [Page 5]
Internet Draft AATN Components & Mechanisms April 1998
HostA---Private NET10--TR -------------Internet--------HostB
Set tunnel
<-------------------------------
assign private address
(tunnel to TR),------------------------------,
(------------------------------->)
‘------------------------------‘
end-to-end communication with private address
(tunnel to TR),------------------------------,
<----------------------------------------------------->)
‘------------------------------‘
Note that with mobile IP tunneling (as proposed by Vipul in [MIP])
address assignment is not required since HostB is a host from the
private network that has been temporarily moved to the global
Internet and it already has a private address.
The tunnel here is required for the duration of the session since
there is no way the global Internet can route private addresses.
L2TP has been proposed as the tunneling mechanisms for both
scenarios since it was designed for this kind of remote access and
has all the hooks for authentication, accounting, address
assignment etc. IPSEC tunnel mode could also be used since some
associated mechanisms for address assignment through IPSEC tunnels
have appeared [SECALL]. Mobile IP [MIP] may also be used but a lot
of details and possibly modifications may be required (how you
accommodate hosts that are not originate from the private network,
thus, do not have private addresses?). IPinIP tunneling may also be
used if appropriate mechanisms are developed for address
assignment. I am sure that there are many other tunneling protocols
that could also be used.
Applicability
- Accessing servers both in private networks and in the global
Internet from hosts in the global Internet and private networks
respectively.
Problems
- How do you discover the tunnel termination point (in this case
the TR) address that can be reached from your position. A number of
ways have been proposed and are discussed later in this document.
- How do you know that you want to create a tunnel (i.e.: access a
private network or the global Internet)? This is arguably a
difficult problem and possibly involves significant changes to the
end hosts. Possible options are discussed later in this document.
Tsirtsis et.al. [Page 6]
Internet Draft AATN Components & Mechanisms April 1998
2.3. DNS triggered address allocation
Another interesting variation that may or may not use tunnels is
the following:
HostA---Private NET10—--NAT/TR------------Internet--------HostB
The first problem that one needs to solve here, when HostB needs to
connect to say HostA, is how HostB knows that HostA even exists.
Today this is possible if there is a statically mapped global
address for HostA, if that is not true HostB has no way of knowing
anything about HostA.
If we assume that the name HostA.Pnet.com is globally unique, then
HostB may be aware of that name. A name lookup on HostA.Pnet.com
will have to go all the way back to the authoritative DNS server
for the domain Pnet.com in order to be resolved. Now there are two
ways to proceed.
a) The DNS for the Pnet.com domain can in some way interact with
the NAT/TR Gateway. In this case the DNS triggers an address
mapping between the private address of HostA and a global address.
The mapping is retained in the NAT/TR and the global address is
returned as a DNS reply to the requesting HostB. HostB can now send
a packet to the global address of HostA. When the packet reaches
the NAT/TR it will have to be translated since the destination
address stated on the packet is only known to the NAT/TR and not to
HostA. Tunneling can not be used to deliver the packet to HostA
without translation since the encapsulated packet will have an
address unknown to HostA.
c) The DNS for the Pnet.com domain can in some way interact with
the local DHCP server. This can only be of use if the DHCP server
is able to perform server initiated address allocation. If yes,
then this is as described in [AIIH], where the DNS triggers the
DHCP to allocate an address to HostA. Then, communication with
HostB can take place without any need of translation or tunneling.
Unless the private network can not route on global addresses, in
which case the DHCP may also provide HostA with information about
the tunnel type and endpoint address, there is no need to use
tunnels.
In any case, the DNS trigger described in (a) may be a useful
addition to the NAT spec in order to allow incoming session through
a NAT router.
Tsirtsis et.al. [Page 7]
Internet Draft AATN Components & Mechanisms April 1998
3. Tunneling between gateways
In many ways this is similar to (2) but it is viewed as a more
generic solution and brings up a number of interesting points.
The problem space is as follows:
Tunnel
<==================>
HostA--Private NET-—TR1-----Internet----TR2--Private NET—-HostB
z.z.z.z x.x.x.x y.y.y.y w.w.w.w
This scenario arises from (2) since the destination (HostB) may not
be part of the global Internet but part of another private network.
Typically, this is called a VPN (though there is much argument
about what VPN actually is...:).
[NET66] attempts to solve this problem by introducing a special
range of addresses, globally unique but not routable, that are
assigned to servers in private networks. By limiting the number of
addresses used for that purpose it is possible to inject this
address space in the DNS system and create mappings between these
designate addresses, working almost as identifiers, and their
nearest globally reachable gateway, serving as a locator (KX
records). NET66, however, does not avoid using NAT in the case of
overlapping address spaces. That is, apart from the servers with
designated addresses, the rest of the private network may use
private addresses overlapping with the address space of another
private network that attempts to use this server. Since the tunnels
only go between gateways, overlapping address space can not be
supported. Extending the tunnel into the private network and up to
the servers, may eliminate the problem.
Other relevant proposals, like [PAID] and others, are more
aggressive in the architectural changes that require, generalising
the above principle. The (probably oversimplified) basic idea of
such proposals is that there is a core, globally reachable, network
of gateways that serve corresponding non-globally reachable
networks. This way, an end host is identified by a pair of
addresses; the end-host address + a gateway address. This seams
like an increased address space but a closer look arises a lot of
questions about their feasibility.
There two variations of this solution; the end-host is aware of the
architecture; the end-host is not aware of the architecture.
a) The end-host is aware of the architecture
Tsirtsis et.al. [Page 8]
Internet Draft AATN Components & Mechanisms April 1998
In this case the end-host has knowledge of the fact that a
destination host needs to be reached using two (rather than one)
addresses. This way the host can make clever use of the available
information and with possible/proposed changes to DNS it can
discover the related gateways, register it self to a gateway
address and use tunneling mechanisms to achieve the desired
communication. The fundamental problem of this approach, however
plausible, is that it requires many changes to end-host, gateways,
DNS and possibly many other protocols that its practical deployment
seams unlikely. It also comes down to the fact that the effort
required to deploy such a scheme would be more than enough to
deploy IPv6 instead.
b) The end-host is not aware of the architecture
In this case the burden is placed on the gateways, to hide the
operations of the network from the end-host. The problem with this
approach is that the end-host things that communicates with a
globally reachable hosts as usual and it can not do anything more
than what it does today. So, the network needs to provide to the
end-host information about say private addresses (introducing
changes to DNS) and the gateways need to be able to find each other
(introducing gateway discover protocols or even more changes to
DNS). Also the problem of overlapping address space between end
nodes seams difficult to solve like that.
4. How the end host knows to use public addressing:
In this section we attempt to list a number of ways to solve the
problem in hand. Some of these have already mentioned in various
drafts or discussions in IETF meetings and some others are new.
Please take the following analysis for its face value, we are just
listing the options that we could thing of and it does not mean
that we support the ideas.
For each option, we also attempt to list concerns and potential
problems; at least the obvious ones. The aim is to trigger
interested parties that may find feasible ways to implement/use
these options in concrete solutions. Also note, that depending on
the way that these options might be implemented and the combination
of options that one might use, the impact on the protocol stack
and existing protocols might considerably changes. Thus, at this
point only obvious change requirements are indicated and future
work should discover the details of these mechanisms.
4.1. By simple host ‘routing’ table (prefix or domain based)
HostA---Private NET10--GateWay ----------Internet--------HostB
10.0.0.1 x.x.x.x
Tsirtsis et.al. [Page 9]
Internet Draft AATN Components & Mechanisms April 1998
HostA, which is assumed to be capable of supporting at least two
addresses, could maintain a simple host routing table. This would
take the following form:
* A list of destination prefixes for each virtual interface. In the
case of multiple non-loadsharing gateways, the host routing table
would have to have a prefix list and virtual interface per gateway.
By default, the list of private address prefixes in the domain
(e.g. 10.0.0.0/8) would be associated with the host’s virtual
interface numbered with its private address. A default route would
also be associated with another virtual interface (the yet-to-be-
assigned public address).
* If HostA needs a tunnel to the GateWay in order to access the
Internet, the tunnel type (e.g. PPTP, L2TP, IP-in-IP, ATMP, GRE) is
also required.
* The gateway address (which would equate, in the case of tunnels,
to the tunnel end point).
This simple host routing table could be downloaded using DHCP
(extensions required) on initial boot together with tunnel end
point addresses and tunnel types when required.
In the simplest cases they could even be pre-configured e.g.
all 10.0.0.0/8 addresses use private address,
Tunnel type = IPinIP and
Tunnel destination = 10.0.0.5).
Applicability
- Private networks with clean addressing schemes (all hosts use
private addresses of known prefix(es).
- If private network is a stub domain with singly gateway router
this becomes easier.
- DHCP initiated network can benefit greatly since the
configuration is automated.
Issues:
- Virtual interfaces need to be created in advance of address
assignment.
- How you calculate lease time of public address?
- The host is becoming a router. Note that in the simple case only
static routs are required but in the general case, with multiple
exit points and big private networks, real routing capabilities may
be required on the host.
4.2. By DNS query trigger
When the host needs to communicate with an external host, it
performs a DNS lookup. The DNS resolver has, or may be configured
to have, the information necessary to know whether the destination
Tsirtsis et.al. [Page 10]
Internet Draft AATN Components & Mechanisms April 1998
host is internal or external to the private addressing domain:
a) The destination host is in a name domain outside the local
private-address domain OR the destination host has a public address
outside the private domain.
b) The DNS resolver either:
- Triggers a DHCP server-initiated address allocation (this
would require changes to DHCP like those done by Jim Bound/Dec in
DHCPv6, I think Jim is also working on that in DHCPv4) to the host,
providing it with a temporary address to use, or,
- the DNS uses a different record type which returns not
only the destination address but also indicates that this is
external. The host then issues a DHCP request.
c) In the case of multiple non-loadsharing gateways, either the
DHCP server or DNS resolver would have to know about gateway
routing tables. Both of these are problematic since DNS and DHCP
are not/should not participate in routing.
Possible Changes
- DHCPv4 to support server initiated address allocation (as DHCPv6
does).
- DNS to have (or appear to have) a notion of site. A record (flag)
to indicate internal/external address may also be required. A lot
of issues may come up with either of these changes and without
fundamental (and probably not desirable) changes to the way that
DNS works a lot depends on the network/DNS administrator which
makes the solution error prone.
- The end-host clearly needs to be changed in order to use most of
the above mechanisms.
4.3. ICMP trigger for all external traffic
HostA---Private NET10--GateWay ----------Internet--------HostB
10.0.0.1 x.x.x.x
In this case all external traffic needs to use globally unique
addresses, possibly retrieved from a DHCP server.
Host in private domain initiates session, without knowing whether
the destination is internal or external. If external, and datagram
reaches gateway, and ICMP message is send back to indicate that a
global address is required. The ICMP message used could be an ICMP
Destination Unreachable, Redirect or Source Quench, with changed
semantics, or an all together new ICMP message (not desirable). The
end-host, on reception of such a message should attempt to acquire
a global address with some mechanism like DHCP or by initiating
tunneling mechanisms as described in (2).
Tsirtsis et.al. [Page 11]
Internet Draft AATN Components & Mechanisms April 1998
Note that this mechanism would rely on the fact that communication
from the private network to the Internet is the minority case and
as such, failure to make a valid connection first time is not too
costly.
4.4. ICMP trigger for end-to-end sensitive traffic
HostA---Private NET10---NAT--------------Internet--------HostB
10.0.0.1 x.x.x.x
In this case, the Gateway to the internet is a NAT router and the
ICMP message is only send back when the session can not be
translated (e.g: IPSEC)
Host in private domain initiates session, without knowing whether
the destination is internal or external. If external, and datagram
reaches NAT box, address translation validity is checked. If
address translation is invalid (according to certain rules) then
the NAT box returns an ICMP message, indicating that a public
address needs to be used. Various ICMP message could again be used
if the semantics can change or a new message type is needed (say
Source Redirect)
As before, when the host receives the ICMP message, it sends a
request to the DHCP server to obtain a public address, and then
sends the datagram as in (2) (tunnelled or routed to NAT). This
method is also advantageous for the case where numerous NAT
gateways are used. The return of the ICMP message may indicate to
the host which gateway to tunnel to.
The Translation Rules that the NAT router uses to determine if
something should be translated or not could take a number of forms:
a) The NAT knows what it can translate. In this case the NAT has to
know what is “safe” to translate. For example, if NAT has an ALG
for the particular application then it can translate or if the IP
Payload is scrambled (end-to-end security is used) it can not
translate. A list of applications that are not to break by the
particular NAT implementation could also be stored in the NAT or a
rule that says “if unsure do not translate” could be used. In any
case this is largely and implementation/configuration issue.
b) The host knows what it should/should not be translated. In this
case the host needs to make an intelligent decision (to be defined)
on whether a packet/session should be subject to translation and
Tsirtsis et.al. [Page 12]
Internet Draft AATN Components & Mechanisms April 1998
notify the gateway accordingly. The problem here is the
notification of the gateway/NAT. A “Don’t Translate” option in the
IP header would be beneficial. This could be set by the sending
host, as an indication to NATs to encapsulate rather than to
translate. It could also be used between NAT gateways. This would
enable the host stack to decide where address translation is
appropriate, rather than the gateway. Obviously, changes to both
hosts and gateways/NATs are required for that.
Note that this mechanism is more scalable than that of (4.3.) since
only traffic that can not sustain translation is tunneled.
Obviously, an number of changes to ICMP, NAT and host are required
to make this work. The most important problem, however, is that the
host needs to change source address AFTER sending the first packet
(and getting back the ICMP message). One way to cope with that is
to take the connection down and set-up a new one, but even for that
the host stack needs to be changed.
4.5. Gateway initiated tunnels (back to the end-host)
This is very similar to the above mechanism.
The host, as above, does not know whether a destination address is
in or out of the site. The packet is send out and if the
destination is out of the site it will reach the NAT/Gateway. If
the packet can be translated, it does as normal. If not, the NAT
could initiate a tunnel back to the host and allocate a global
address ala NAT-bypass. Note that if L2TP is used address
allocation maybe easier since, this appears to the end-host as a
PPP call back service and it will accept address allocation as part
of the IPCP process from the tunnel originator, without having to
initiate DHCP.
In this case the host needs to be able to terminate tunnels from
the gateway which is not conformed to a typical client spec. The
host also needs to be aware of the process in order to associate
the incoming tunnel with a previous communication attempt. This
becomes particularly difficult if a number of connections are
initiated at the same time from a single host.
5. Summary of Components
Depending on the scheme some of the below are required:
* Fundamental (not so controversial?) Components
- Gateway discovery protocols/mechanisms (some already defined
e.g: NET66, PAID)
- Tunnel type negotiation. There is number of proposals that
Tsirtsis et.al. [Page 13]
Internet Draft AATN Components & Mechanisms April 1998
use some kind of tunneling technique. If no single tunneling
protocol is adopted by all (highly unlikely) the choices are static
configuration or a negotiation protocol. DHCP can also help as
described above.
- Server initiated DHCP configurations ala DHCPv6
* Controversial Components
- the ability for a host to maintain multiple virtual
interfaces. Hosts today do not support that very well or do not
supported at all.
One of the following:
- A ‘Don’t Translate’ IP option which may be set by the
hosts to indicate where address translation is inappropriate.
- A new or overloaded ICMP message, which a NAT/gateway may
return to the sending host when it is unable to translate a packet
without problems.
- NAT routers to be able to recognise packets/sessions that
can be safely translated.
- Extended DNS - DHCP and/or DNS - NAT/TR interaction
- Client hosts to be able to terminate tunnels
6. Security Considerations
This is not a protocols specification and security considerations,
although many, are not discussed here. If any of the ideas
described in this documents are going to become protocols or parts
of protocols, security considerations will be discussed in the
corresponding specifications.
7. References
[AIIH], J.Bound, Assignment of IPv4 Global Addresses to IPv6 Hosts
(AIIH), <draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt>, March 1998
[MIP], G. Montenegro, V. Gupta, Firewall Support for Mobile IP,
draft-montenegro-firewall-sup-03.txt, January 27, 1998
[NATB], G.Tsirtsis, A.O'Neill, NAT Bypass for End 2 End 'sensitive'
applications, <draft-ietf-nat-bypass-00.txt>, January 1998
[NET66], R. G. Moskowitz, Network Address Translation issues with
Ipsec, <draft-moskowitz-net66-vpn-00.txt>, February 6, 1998
[PAID], Y. Li, W. T. Teo, IP Private Address Identification (PAID),
Tsirtsis et.al. [Page 14]
Internet Draft AATN Components & Mechanisms April 1998
draft-yliteo-mobileip-paid-00.txt, 18 January 1998
[SECALL], Baiju V. Patel, Dynamic remote host configuration over
IPSEC using DHCP, draft-ietf-ipsec-dhcp-00.txt, September, 1997
-------------------------------------------------------------------
Notice: This contribution has been prepared to assist the IETF as a
basis for discussion. It is not a binding proposal on British
Telecommunications plc; specifically, British Telecomminications plc
reserves the right to modify, delete or amend any statements contained
herein.
-------------------------------------------------------------------
Tsirtsis et.al. [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 16:04:58 |