NAT WG meeting minutes - 43rd IETF - Orlando, FL - December 9, 1998 Chairs: Matt Holdrege Pyda Srisuresh Reported by: Ben Rogers Edited by: Matt & Suresh ____________________________________________________________________ Mailing list: nat@livingston.com To subscribe: Send e-mail to nat-request@livingston.com with "subscribe" in the body of the message. To unsubscribe: Send e-mail to nat-request@livingston.com with "unsubscribe" in the body of the message. Mailing list: nat-digest@livingston.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 nat-digest-request@livingston.com with "subscribe" in the body of the message. To unsubscribe: Send e-mail to nat-digest-request@livingston.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. - "" Detailed Slides and/or Comments made by the presenter Questions from the Audience: [ - ] _________________________________________________________________________ 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. Agenda 1. "NAT Friendly Application Design Guidelines" 20 mins. 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. (NAT) Domains" by Pyda Srisuresh 4. "IP Network Address Translator (NAT) Protocol Issues" 20 mins. by Matt Holdrege & Pyda Srisuresh 5. "IP Network Address Translator Application 20 mins. Programming Interface" by Pyda Srisuresh 6. "IP Host Network Address (and Port) Translation" 20 mins. 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 General Goal o 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. General Recommendations o 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) o Use DNS names, not IP addresses o Avoid passing addressing data in payload (IP addresses, port numbers) o End to end IPsec problematic * Consider using TLS instead. Host NAT is a possibility for the future o Service Location * Avoid location via broadcast or multicast o Subsequent Sessions * Address bindings not guaranteed between subsequent sessions. Reliance on the appearance of co-location can be problematic o 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. o 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. Additional Items o 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" Agenda o Terminology o Bootstrapping - Routing configuration - DNS configuration o Scenario 1: internally originated connections o Scenario 2: externally originated connections o Discussion Problems with Multihoming o Creates scaling problems for the global routing infrastructure. o Use of multiple address blocks from upstream ISPs provides a possible solution, but results in added address management complexity o Controlling load balancing based on address assignment is complex o Difficult to achieve symmetric flow of packets in and out of an enterprise Terminology o Inside Global Address (IGA): Block of address space assigned by the ISP to the enterprise. o Inside Local Address (ILA): Address space used within the enterprise behind the NAT o Outside Global Address (OGA): Legal address space outside the enterprise and the NAT o 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.] Topology An enterprise with 2 NAT routers interfacing with 2 different ISPs. Routing Configurations o NAT configured to assign IGA prefixes to internal addresses and OLA prefixes to external addresses. o OLA prefixes must not overlap with ILA or OGA address space o NATs EBGP peer with upstream ISPs to advertise IGA prefixes o NATs injects OLA prefixes into the enterprise IGP routing o NATs also IBGP peer with each other DNS configuration Goal: Bootstrap exchange of DNS messages across NAT Reaching the parent zone server o Assign an OLA prefix to the external parent server and create a translation entry in the NAT mapping the server OGA to its OLA o Configure internal DNS server with the parent zone server's OLA Reaching foo.com's DNS server o Assign a IGA prefix to the internal DNS server and create the corresponding translation entry in both the NATs o 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 Summary o 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) Discussion o Scheme places no addressing restrictions on the multihomed network except in OLA allocation. o Scheme is independent of the enterprises internal routing architecture. o Changing providers doesnt require renumbering. o Due to address allocation packet flow between a pair of hosts will always flow through the same NAT resulting in symmetry o In case of link failure between the NAT and ISP, fallback connectivity may be provided using RFC 2260 mechanisms. o 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. Misc. o Draft includes lab-tested router and DNS server configurations o Concept tested by Ed Kern at NANOG http://www.academ.com/nanog/feb1998/nat.html o 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.] Correct [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 Terminology o Clear-NAT - Nat applied to Outer packet Header o Secure-NAT - NAT applied to packets embedded within a secure tunnel o Secure-NAT gateway device - Supports both Clear-NAT and Secure-NAT o Terminology from IPsec RFCs + nat draft Secure-NAT Model o Secure Policies administered using private realm addressing o Secure-NAT address mapping o 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-NAT applications o Secure Extranet connectivity - Allows private domains to connect securely to external domains. o Secure mobile user connectivity - allows mobile users to connect securely to enterprise routers. There is a draft by Vipul () 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. Objective o Identify external agents and their interface requirements with NAT o Provide a framework for the development of one or more protocols by which agents can interface with NAT o Identify NAT objects that could be externalized with MIB o Provide an API framework for agents on the same device to interface with NAT. External Agents o Host-NAT and Host-NAPT clients need some way to obtain their addresses and routes. o Management application needed to configure a NAT (which ALGs are available, ...) o Backup NAT may be needed. o ALGs 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. NAT elements Draft will contain more gory details than are discussed in this meeting. o NAT Descriptor - ID, Type, Address map, etc. o BINDing Descriptor - ID, Type, specific addresses (port) bound, Leased time, Controlling Agent ID, etc. o Session Descriptor - ID, Controlling BIND ID, Original and Translated session parameters, Session Tag, Session Termination heuristic, etc. External Agent descriptor o Agent ID o Agent Type o Agent Call back requirements o Agent Call-back functions o 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.) Framework o Uses a common "control" protocol for HNAT parameter negotiation o Uses tunneling mechanisms for routing externally addressed packets within private domain. Motivations o Lack of a common protocol that enables Host-NAT-client and Host-NAT-Server to interoperate. o Hence goal is to design a common protocol that enables Host-NAT-client and Host-NAT-server to interoperate. Protocol requirements o Client type registration and identification - Client ID assignment o Enables negotiation of multiplexing fields - Global address, port, protocol ID o Enables negotiation of HNAT related parameters - Max. Leased Time, NAT type o Support negotiation of tunnel type o Support subnet query Considerations o Exploitation of existing protocols? * DHCP, ICMP, COPS, TCP/UDP/RUTS based? o Independence * Support negotiation of all fundamental parameters required to perform HNAT. o Extensibility * Flexible packet format * Able to support vendor specific information - New error codes * Able to accommodate new policies. Proposal o 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.] Yes.