INTERNET DRAFT George Tsirtsis Richard O'Brien Martin Tatham Alan O'Neill BTLABS April 1998 Possible Mechanisms and Components for AATN 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), , 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, , January 1998 [NET66], R. G. Moskowitz, Network Address Translation issues with Ipsec, , 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]