NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Pyda Srisuresh <email@example.com>
Matt Holdrege <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Vern Paxson <firstname.lastname@example.org>
Transport Area Advisor:
Vern Paxson <email@example.com>
To Subscribe: firstname.lastname@example.org
Description of Working Group:
IP V4 Network Address Translation (NAT) has become an increasingly common function in the Internet for a variety of reasons. NATs are used to interconnect a private network consisting of unregistered IP addresses with a global IP network using limited number of registered IP addresses. NATs are also used to avoid address renumbering in a private network when topology outside the private network changes for variety of reasons. And, there are many other applications of NAT operation.
A number of NAT deployments are currently in use and naturally, a large number of internet applications work transparently with NATs. However, there are applications for which NATs would fail and custom-specific Application Level Gateways (ALGs) are required to perform translations for those applications.
NAT has the potential to interrupt end-to-end nature of Internet applications, thereby threatening end-to-end security and other end-to-end functions. In addition, NAT has topology restrictions and other constraints on the protocols and applications that run across NATs. Thus NATs have a particular area of application and should not be considered a general solution.
This working group will provide a forum to discuss applications of NAT operation, limitations to NAT, and impact of NAT operation on internet protocols and applications. The Working Group recognizes that NAT may interfere with protocols that use cryptographic protection for authentication, integrity or confidentiality. The Working Group will NOT suggest changes in such protocols to make them NAT friendly when such modification will significantly reduce the security provided by those protocols. However, the Work Group will examine and discuss alternative solutions, and other new ideas relating to this issue. Broadly speaking, the objective of the work group is to come up with a series of documents in the following categories.
The first category of documents will address what NAT is, how NAT works and applications of NAT operation in address conservation, prevention of address renumbering, load sharing and other areas.
The second category of documents will address requirements of NAT and limitations to NAT operation. Specifically, this will include a detailed list of applications which are known to have problems working over NATs.
The third category of documents are Informational RFCs which will specify NAT friendly application and protocol design guidelines, interactions between NATs and applications such as DNS and protocols such as IP sec. Particular emphasis will be placed on security issues. The Work group will also examine and discuss various alternative solutions, and other ideas to identify areas where NATs or other protocols and applications can be improved to overcome the shortcomings in interoperability or functionality.
The fourth category of documents will deal with network management of NATs.
Exploration of the use of NATs for load sharing is not within the scope of this working group.
The goals and milestones section below lists just the subject matter of issues to be covered. This is done so deliberately because there may be some adjustments made to the packaging of the RFCs, while covering all of the contents below. The work group will decide how to group the contents into different RFCs.
Goals and Milestones:
Submit Internet-Draft on what is NAT and how NAT works.
Submit Internet-Draft on NAT limitations and a list of applications and protocols known to have problems working with NAT.
Submit Internet-Draft on NAT friendly application and protocol design guidelines.
Submit Internet-Draft on Interaction of NATs with IP switching, roaming IP, mobile IP, IP multicast, DNS and other protocols and applications.
Submit Internet-Draft on security implications of NAT.
Submit Internet-Draft on Network Management Information Base for NATs.
No Request For Comments
NAT WG meeting minutes - 43rd IETF - Orlando, FL - December 9, 1998
Chairs: Matt Holdrege <email@example.com>
Pyda Srisuresh <firstname.lastname@example.org>
Reported by: Ben Rogers <email@example.com>
Edited by: Matt & Suresh
Mailing list: firstname.lastname@example.org
To subscribe: Send e-mail to email@example.com with "subscribe" in the body of the message.
To unsubscribe: Send e-mail to firstname.lastname@example.org with "unsubscribe" in the body of the message.
Mailing list: email@example.com
(This is nat mailing list, in daily-digest format.
To receive the digest, you can subscribe as follows.)
To subscribe: Send e-mail to firstname.lastname@example.org with "subscribe" in the body of the message. To unsubscribe: Send e-mail to email@example.com with "unsubscribe" in the body of the message.
All presentations, along with WG meeting minutes will be avilable on-line from the following URL. http://www.livingston.com/tech/ietf/nat
In order to avoid confusion, the following indentation and format legend should be used as a guide to interpreting the minutes.
<Presenter> - "<presentation/Discussion Topic>"
<Any other remarks by minutes taker or editors>
Detailed Slides and/or Comments made by the presenter
Questions from the Audience:
[<Audience-Name> - <Question/Comment>]
<Response from the Presenter>
Matt Holdrege - Introduction
Two NAT Drafts sent to mailing list completed WG last call and are currently awaiting IESG review for advancing into informational RFC status.
1. "NAT Friendly Application Design Guidelines" 20 mins.
<draft-ietf-nat-app-guide-00.txt> by Daniel Senie
2. "A Multihoming solution using NATs" 20 mins.
< draft-akkiraju-nat-multihoming-00.txt > by Praveen Akkiraju and Yakov Rekhter
3. "Security for IP Network Address Translator 20 mins.
<draft-ietf-nat-security-00.txt> by Pyda Srisuresh
4. "IP Network Address Translator (NAT) Protocol Issues" 20 mins.
<draft-ietf-nat-protocol-issues-01.txt> by Matt Holdrege & Pyda Srisuresh
5. "IP Network Address Translator Application 20 mins.
<draft-ietf-nat-api-00.txt> by Pyda Srisuresh
6. "IP Host Network Address (and Port) Translation" 20 mins.
<draft-ietf-nat-hnat-00.txt> by Jeffrey Lo & K. Taniguchi
Daniel Senie - "NAT Friendly Application Design Guidelines"
http://www.amaranthnetworks.com/nat - This is the link to Daniel's web page that will have the most uptodate copy of applications that are NAT friendly
- Develop new application protocols which do not require ALG assistance from NAT and Firewall implementations
These guidelines tend to apply to both NAT and Firewall implementations as the requirements for a firewall a similar.
- Use of Multiple Session Bundle
- Use single TCP or UDP port for all traffic where possible
- If possible, originate all sessions from the same endpoint (this avoids the FTP problem)
- Use DNS names, not IP addresses
- Avoid passing addressing data in payload (IP addresses, port numbers)
- End to end IPsec problematic
- Consider using TLS instead. Host NAT is a possibility for the future
- Service Location
- Avoid location via broadcast or multicast
- Subsequent Sessions
- Address bindings not guaranteed between subsequent sessions.
Reliance on the appearance of co-location can be problematic
- Operational Reliability
- TCP preferred over UDP since NAT can track TCP sessions more easily and know when sessions end.
- UDP sessions are tracked by timeouts.
ALG's can overcome this problem, but we'd rather design applications to not need this processing.
- Processing Overhead
- Each new session requires resources and processing to establish associations. Using a single session for app reduces overhead.
There is still some overhead, but this is unavoidable.
- Comments since the last draft
- Performance: latency and throughput can be affected by NAT. Depends on implementation.
The hardware solution can be optimized to lessen this problem
- NAT implementations presently tend to only support TCP and UDP applications (... for implementations of NAPT). A device performing just NAT, without any ALG support, supports many applications as is.
Questions from the Audience:
[Eliot Lear - UDP session management. UDP may make it more difficult to maintain the mapping]
An application may maintain keep-alives to make this less of a problem.
[Someone said there are similar issues with SOCKS, and these ideas can be shared with NAT. Do we have any plan to make a utility to verify the guidelines?]
Multiple sessions can work, but are not as reliable, nor as friendly as single sessions. An analyzer might be created to diagnose traffic in a non-NAT environment.
[Can we add a recommendation to change current applications (eg. modify FTP to use passive) to avoid these problems in current protocols.]
An RFC exists on this particular issue, RFC1579 by Steve Bellovin. It doesn't reduce FTP to a single session, though, just makes the connections start from the same endpoint.
Praveen Akkiraju - "A Multihoming solution using NATs"
- Routing configuration
- DNS configuration
- Scenario 1: internally originated connections
- Scenario 2: externally originated connections
Problems with Multihoming
- Creates scaling problems for the global routing infrastructure.
- Use of multiple address blocks from upstream ISPs provides a possible solution, but results in added address management complexity
- Controlling load balancing based on address assignment is complex
- Difficult to achieve symmetric flow of packets in and out of an enterprise
- Inside Global Address (IGA): Block of address space assigned by the ISP to the enterprise.
- Inside Local Address (ILA): Address space used within the enterprise behind the NAT
- Outside Global Address (OGA): Legal address space outside the enterprise and the NAT
- Outside Local Address (OLA): Address space in the enterprise used to translate OGA addresses
[Brian Carpenter - terminology is quite confusing and is worth rethinking, because outside and inside are backwards from what we're currently used to.]
An enterprise with 2 NAT routers interfacing with 2 different ISPs.
- NAT configured to assign IGA prefixes to internal addresses and OLA prefixes to external addresses.
- OLA prefixes must not overlap with ILA or OGA address space
- NATs EBGP peer with upstream ISPs to advertise IGA prefixes
- NATs injects OLA prefixes into the enterprise IGP routing
- NATs also IBGP peer with each other
Goal: Bootstrap exchange of DNS messages across NAT
Reaching the parent zone server
- Assign an OLA prefix to the external parent server and create a translation entry in the NAT mapping the server OGA to its OLA
- Configure internal DNS server with the parent zone server's OLA
Reaching foo.com's DNS server
- Assign a IGA prefix to the internal DNS server and create the corresponding translation entry in both the NATs
- Configure DNS Server for authoritative parent zone with the IGA's from both NAT's to reach foo.com's authoritative server
(DNS message handling as in draft-ietf-nat-dns-alg-01.txt)
Initial NAT Table
Internal DNS server and Root DNS server are both mapped to provide inside/outside pairs for each.
NAT bootstrapped with foo.com and parent zone DNS server mappings.
- DNS response processing in a NAT consists of 2 stages
- translation of the IP-UDP header
- translation of the reply message
(Walk-through of full packet flow for a DNS lookup, and changes to the NAT table.)
The structure of this query-response system ensures that all traffic flow passes through the same NAT.
Resolving X.foo.com (externally initiated session)
(Walk through of full packet flow for the incoming DNS-lookup)
- Scheme places no addressing restrictions on the multihomed network except in OLA allocation.
- Scheme is independent of the enterprises internal routing architecture.
- Changing providers doesnt require renumbering.
- Due to address allocation packet flow between a pair of hosts will always flow through the same NAT resulting in symmetry
- In case of link failure between the NAT and ISP, fallback connectivity may be provided using RFC 2260 mechanisms.
- Controlling the selection of the NAT which processes a DNS response controls the rest of the packet flow to the target host.
- Load balancing is tied to the flow of DNS packets
- Translation of the IP-UDP and DNS reply are handled in the same NAT
- Under policy control Translation of the IP-UDP and DNS reply may be handled in seperate NATs
- This allows for more flexible policy based load balancing of traffic flows.
- Draft includes lab-tested router and DNS server configurations
- Concept tested by Ed Kern at NANOG
- Refer draft-rfced-info-srisuresh-05.txt for details on NAT operations and issues.
Questions from the Audience:
[Brian Carpenter - DNS server for foo.com has to be inside foo.com, and zone transfer will result in a disaster.]
[continued... Very clever zone transfer (at minimum) is needed, if this is possible at all. This is not very clear in the text.]
[Suresh - Names are apparently end-to-end unique. Is the DNS information here a duplicate effort of the DNS-ALG draft (or) Is there something particularly different in this draft?]
DNS information here is same as in DNS-ALG draft.
The information is included here for Completeness.
[continued.. Twice nat and BGP are implied as required in this draft, while they are only required for the given scenarios.]
Twice nat is not necessarily required, but BGP seems to be.
[continued.. BGP doesn't have to be on boxes connecting to two ISPs. The draft must be scoped properly. Terminology should be cleared up to be consistent with other drafts. Also, DNS based Load sharing discussed here seems orthogonal to multihoming and NAT issues.]
[Eliot Lear - We can probably get away with no BGP, but we would still need to use some dynamic routing protocol.
[Yakov - BGP is mentioned because an existing RFC 2260 for robust multihoming is based on BGP]
[Radia Perlman - Talked about ISP link going down, but not what happens when the NAT itself goes down. Can we force new DNS queries so that address caching does not occur.]
Force of 0 ttl should address this problem.
[Bob Brandt - This seems to infer that there is a 1-1 mapping between external DNS servers and internal addresses. This seems to create a scaling problem.]
Addresses are assigned for a limited time, so we can timeout the addresses quickly.
Pyda Srisuresh - "Security Model for NAT domains"
Problems with End-to-end IPsec.
Security from NAT box to external node seems to be possible
Model made to be in line with IPsec model to provide security for NAT nodes-> external nodes
- Clear-NAT - Nat applied to Outer packet Header
- Secure-NAT - NAT applied to packets embedded within a secure tunnel
- Secure-NAT gateway device - Supports both Clear-NAT and Secure-NAT
- Terminology from IPsec RFCs + nat draft
- Secure Policies administered using private realm addressing
- Secure-NAT address mapping
- Security Association Parameters
Secure-NAT Gateway Outbound Packet Processing
(Flow-chart to describe NAT processing decision)
(Verify Outbound packet against outbound Secure policies. In case of a match, subject the pakcet to Secure-NAT prior to tunneling using Outbound IPsec SA.)
Secure-NAT Gateway Inbound IPsec Packet Processing
(Detunnel packet using IPsec SA, perform inbound Secure-NAT, then verify that it matches inbound security policies)
Slides thus far make the assumption that keys are statically configured.
IKE support to secure-NAT GW
(Large diagram describing the role of IKE-ALG in the translation of secure policies)
- Secure Extranet connectivity - Allows private domains to connect securely to external domains.
- Secure mobile user connectivity - allows mobile users to connect securely to enterprise routers.
There is a draft by Vipul (<draft-gupta-ipsec-remote-access-00.txt>) that describes how secure remote access is possible for a mobile user, without requiring both Home and Care-of addresses on Mobile Node.
Matt Holdrege - "NAT Protocol Issues" draft
Title has been a point of contention (issues?)
"Limitiations" proposed on the list
"NAT Protocol Complications" is the new proposed title.
We need input from the community
We will continue to document the additional information we receive on protocols in the current format.
We are working on a better method to get more contributions.
The draft will be titled after we can put more information into this draft.
Questions from the Audience:
[Brian Carpenter - RFC on renumbering issues brought up a similar set of problems. There was not at the time a clean way to find all the affected protocols. Y2K was solved by searching 2000 RFCs, but an appeal to the community may be better in this case.]
Diverse group in the room should be able to talk to members of other WGs to help find these types of issues.
Pyda Srisuresh - "NAT API"
Draft title is not necessarily representative of the objectives of this draft. In particular, the intent is not to mandate standardization of the NAT API.
- Identify external agents and their interface requirements with NAT
- Provide a framework for the development of one or more protocols by which agents can interface with NAT
- Identify NAT objects that could be externalized with MIB
- Provide an API framework for agents on the same device to interface with NAT.
- Host-NAT and Host-NAPT clients need some way to obtain their addresses and routes.
- Management application needed to configure a NAT (which ALGs are available, ...)
- Backup NAT may be needed.
A number of agents with different requirements would need to interface with the NAT. (Hence the API name.)
NAT is doing significant resource management, and this information is useful for network management applications.
These constitute the behind-the-scene's agenda for the creation of this draft. There is no intention to standardize on an API.
Draft will contain more gory details than are discussed in this meeting.
- NAT Descriptor - ID, Type, Address map, etc.
- BINDing Descriptor - ID, Type, specific addresses (port) bound, Leased time, Controlling Agent ID, etc.
- Session Descriptor - ID, Controlling BIND ID, Original and Translated session parameters, Session Tag, Session Termination heuristic, etc.
External Agent descriptor
- Agent ID
- Agent Type
- Agent Call back requirements
- Agent Call-back functions
- Agent Accessibility information
Function calls provided to agents
(List of function calls that an agent could invoke)
Functions are provided to perform inquiries on bindings, sessions to register with NAT (as an ALG, ...) to set parameters within BIND or Session to free BIND or Sessions
Callback functions in agents
(List of callback function an agent could provide)
Callbacks may occur on events or packets, or simply periodically.
The ADs have advised that this WG is the right forum to discuss Host-NAT issues. However, we need to ensure that the base documents of the WG are given priority.
Questions from the Audience:
[Eliot Lear - This seems to be required. Brian raised the issue of architectural implications of NAT. This draft addresses some of those problems, especially in terms of Host NAT.]
This doesn't provide for Host NAT, per-se.
[Brian Carpenter - Hasn't read the draft.]
Jeffrey Lo - "Host Network Address Translation"
This draft came out recently, so there may not have been many people who have taken a look at it. (Some indication of Distributed NAT.)
- Uses a common "control" protocol for HNAT parameter negotiationUses tunneling mechanisms for routing externally addressed packets within private domain.
- Lack of a common protocol that enables Host-NAT-client and Host-NAT-Server to interoperate.
- Hence goal is to design a common protocol that enables
Host-NAT-client and Host-NAT-server to interoperate.
- Client type registration and identification
- Client ID assignment
- Enables negotiation of multiplexing fields
- Global address, port, protocol ID
- Enables negotiation of HNAT related parameters
- Max. Leased Time, NAT type
- Support negotiation of tunnel type
- Support subnet query
- Exploitation of existing protocols?
- DHCP, ICMP, COPS, TCP/UDP/RUTS based?
- Support negotiation of all fundamental parameters required to perform HNAT.
- Flexible packet format
- Able to support vendor specific information
- New error codes
- Able to accommodate new policies.
- Dynamic Bindings Acquisition Protocol (DBAP)
- ICMP based
- Enable assignment of various parameters
End host implementation
(Chart of relations between various pieces of client and server)
Questions from the Audience:
[Daniel Senie - Choice of ICMP versus TCP]
This was designed around a larger scale implementation.
[Nair Venugopal - Does this mean that we can use transport mode IPsec.]
NAT Friendly Application Design Guidelines
Multihoming with NATís
Security Model for NAT Domains
NAT Application Programming Interface
Host Network Address Translation