NAT BOF meeting minutes at the 39th IETF at Munich ------------------------------------------------------------------------ Network Address Translator (NAT) BOF at the 39th IETF at Munich was presided over by Pyda Srisuresh under the auspices of the transport area. More than 100 people from most of the IETF areas attended the BOF. Slides were used during the presentations by Yakov Rekhter, Pyda SriSuresh and Steve Deering. I will try to have these slides available for view in the next couple of days. Much thanks to Bertrand Buclin for painstakingly taking the BOF notes and sending me by e-mail in a very short time. We now have a mailing list created to discusss nat issues. The NAT mailing list is formed to address NAT related topics and issues such as NAT friendly application design rules, exploration of specific problems people think NATs create, identify topologies that NAT boxes do not seem to support, DNS, security, mobility and IPv6 issues effected by NATs etc. Initial membership consists of everyone who signed up at the Munich BOF (stated more accurately, everyone whose e-mail IDs we could decipher). If you do not want to get the mailing list please send email to majordomo@livingston.com with line "unsubscribe nat" in the body of message. Details of the mailing list are as follows: Mailing List: nat@livingston.com To join the list: Send email to nat-request@livingston.com with "subscribe" in the body of the message. To leave the list: Send email to nat-request@livingston.com with "unsubscribe" in the body of the message. Below are the minutes of NAT BOF, followed by the list of attendees. Cheers, suresh (Pyda Srisuresh) ------------------------------------------------------------------------ Start of NAT BOF Meeting Minutes Sequence of Events: 1. Agenda presentation by Suresh 2. Word from Scott Bradner, Transport Area Director 3. Statement of Objective 4. Overview on NAT by Yakov Rekhter 5. Talk on IP security considerations by Steve Bellovin 6. Presentation of new internet draft on NAT by Suresh 7. "Is NAT an alternative to IPv6 transition" by Steve Deering 8. Wrap up and closure by Scott Bradner 1. Agenda presentation by suresh Suresh presented the following agenda: 1. Word from the AD. 2. Statement of objective. 3. Overview on NAT by Yakov Rekhter 4. Present new internet draft on NAT 5. Comments from audience 2. Word from Scott Bradner, Transport area director NATs have been seen as something evil and ugly in the IETF. However, NAT is there and is being used, so the IESG decided to investigate how much NAT should be standardized. The internet-draft from Suresh and Kjeld started the discussion going and the IESG decided to use this as a basis to reopen the discussion within IETF with a BOF session. The arrival of the intranet concept and the draconian approach used by some of the ISPs in address allocation has forced people to revisit the applicability of NATs. 3. Statement of Objective Suresh stated the objective of the meeting to be the following: * Collect input on what NAT means to different people. * Explore specific problems people think NATs create. * Identify topologies that NATs do not support. * Summarize NAT issues, caveats and resolutions. * Determine need to form a work group. 4. Overview on NAT by Yakov Rekhter Yakov Rekhter presented NATs (with no application specific knowledge) and Application Level Gateways (ALGs) as devices helping interconnect disparate routing realms. The Internet model was that there should be a single routing realm in the world. However, reality shows that there are more than one realm (for example, RFC1918 acknowledges the existing of multiple realms with the provision of re-usable address ranges). Two options for interconnecting realms are either ALGs or NATs. Both NATs and ALGs help interconnecting routing realms with either distinct or overlapping address spaces. There are two flavors of ALGs, Non-transparent and Transparent. A non-transparent ALG, by its name is visible to end users and requires users to establish explicit connection with the ALG, whereas the transparent ALGs are non-visible and users are not aware of the ALG presence during their transactions. Non-transparent ALGs allow for other-than-address based authentication, whereas transparant ALGs relying solely on address based authentication. NATs modify addresses in IP header and adjust transport layer (TCP/UDP) checksum. But, NATs are application independent and do not understand syntax and semantics of application data stream. NATs can use dynamic or static address mapping. Static is more robust because there is no need to determine if the mapping would be terminated. Dynamic mapping could be driven either by DNS requests, or by the data traffic (although the latter is the most common). NATs deal very poorly with application data that contain IP addresses. E.g., FTP PORT command. ALGs are application specific and may not be very efficient from performance stand point. As a middle ground between ALGs and NATs, Yakov suggests the use of ATs, which are NATs with application specific knowledge where possible, combined with ALGs for all other types of applications. Specifically, ATs could incorporate DNS ALG functionality for the interconnecting routing realms. FQDNs have to be unique across realms. Usually, also DNS zones are constrained to a single realm. An AT should modify DNS RRs data when it traverse the gateway. End-to-end IP security is jeopardized when packets cross routing realms, as NATs, ALGs and ATs alike perform routing address translations. IPSEC assumes that addresses are preserved on an end to end basis. IP SEC does not support applications crossing multiple realms. However, IPSEC is not the only way to achieve security. Yakov suggests enhancements to IP security to support communications spanning multiple routing realms. The major use of NATs today is to interconnect routing realms based on RFC1918 private addresses. It also improves the address space utilization, and thus reduce the rate of consumption of IPv4 addresses. Enables scaleable routing via topologically significant address assignment while limiting the impact of renumbering to AT itself. It also provides scaleable routing support for multihomed sites and improves path symmetry for those. Finally, they could used for migration from IPv4 to IPv6. Drawbacks are unpredictable failure modes when dealing with an application that is not supported via the ALG functionality but carries IP address at the application layer. IP SEC for inter-realm connectivity is problematic. NGTRANS has a proposal on the table called No-NAT (NNAT) which addresses most of the drawbacks of NAT, however this proposal needs to be further developed to see if it is a viable alternative. 5. Talk on IP security considerations by Steve Bellovin The very issue of security is to establish trust. IPSEC's purpose is to not trust the network, and establish trustable mechanisms between hosts. The main use of IPSEC is either host to host, or firewall to firewall (VPNs). In most case, all the hosts behind a firewall are considered as 'secure' thanks to the firewall. The main thing to worry when deploying IPSEC is determining the trust boundaries. With NATs, when DNSSEC is used, the signatures on the responses must be cut off. On a general basis, NATs prevent most of the services relying upon cryptographic services (e.g. non-repudiation because the NAT would need to act on proxy of the user and have the user private keys !). Application level security is by definition applying to an environment with different trust boundaries. Re-engineering IPSEC to cope with NAT would mean trusting a third party (the NAT), thus lessening the overall security level (theoretically). For example, with encrypted FTP data channels, NAT would not work unless the NAT device has the decrypting key of one of both parties involved in the transfer, which defeats the purpose of encrypted FTP. 6. Presentation of new internet draft on NAT by Suresh New internet draft to replace RFC 1631 was presented by Suresh. The ID is authored by Srisuresh (suresh) and Kjeld Egevang. The new draft extends RFC1631 with the concept of Network Address and Port Translation. There are public domain implementations available from linux and freeBSD. NAT has significant issues: * The biggest issue being that NAT takes away end-to-end significance of the source and/or destination addresses, TCP/UDP ports. * NAT expects sessions to be fairly independent. NAT has issues with session dependency between sessions. An example would be FTP control session setting up the FTP data sessions. Without following the contents of the control session, it would be hard to predict the data session characteristics such as session orientation. * NAT does not deal with addresses within payload. The new draft makes a few clarifications and corrections: * Correction to the incremental checksum adjustment alogorithm * ARP responses to NAT addresses on LAN * As for DNS server deployment, recommends having a DNS Server on private network to resolve all private names and an External DNS server to resolve external names. However, centralizing DNS service to the NAT box could obviate the need to have two different DNS servers, one for the priavte network and one for the global network. * Switch over from NAT to NATP. * In a nutshell, NAT is a hack and does not work with all applications. So, it is desirable to have application level gateways for the applications that are not NAT friendly. Network Address Port Translator: * Most popular with ISPs. * NAPT translates a large pool of private addresses into a single address, but maps applications to different TCP/UDP port numbers. * Uses identifier field in ICMP query messages to map to the same field on the assigned IP address. Security considerations with NATs: * UDP sessions are inherently unsafe. Responses to a datagram could come from an address different from the target address used by sender. NAT implementations that do not track datagrams on a per-session basis could compromise the security even further. * Multicast sessions (UDP based) are another source for security weaknesses. * NAT makes up for the loss of end-to-end address significance by maintaining a state for each session. This type of state management for sessions in NAT makes it a target for break-ins that hosts have had to deal with (.e.g. SYN attacks). 7. "Is NAT an alternative IPv6 transition" by Steve Deering Steve does often IPv6 tutorials, and a very frequently asked question is whether NAT is an alternative to IPv6 transition ? NAT have kept the Internet alive and growing and helped buying time for the development of IPv6... NAT can help avoid renumbering when one changes service provider. However, NATs do not nicely supports using redundant paths out of a site, and breaks IP mobility in certain (likely) topologies. So, NAT as a new addressing and routing architecture, is a bad idea and significantly inferior to the current one. More complicated, more fragile, less efficient, messy interdependence between IP and DNS, and harder to debug and manage, less accomodating to new applications etc. 8. Wrap up and closure by Scott Bradner The issue is not anymore whether NAT is a good thing or not. It is merely whether the IETF should do something about it. Many auestions were raised. * If the NAT proposal was put on the standard track, how would one test multiple interoperable implementations ? * Either it could be published as an informational document, or it could evolve toward a NAT Requirements document. Arguments in favor of further work are: * Work group could come up with ways to simplify the troubleshooting of problems involving NATs. * Proposal is to make at a minimum a NAT BCP. * A few protocols currently developed are not NAT friendly. Maybe some protocol design guidelines to help new protocols being NAT friendly could be useful. * NATs are usually implemented on firewalls, and since there is a firewall MIB in the development, then it might be expanded to also cover NAT features. * IP mobility issues effected by NAT, NAT use during transition to IPv6, Best current practices for NAT etc. NAT has been helping preserving address space. Even though, it should not be included as a recommended practice for the registries when assigning addresses. However, some of them set for themselves the policy of imposing NAT onto their local 'customers'. Most of the attendance admit that a NAT WG should be set up within the IETF. The NAT WG will itself define the charter and what kind of deliverables it will produce (BCP, FYI or standards). Jim Bound requested that the NoNAT concept be covered by NGTRANS. Jim also argued on the rationale that NAT is widely deployed and hence that justifies the creation of a WG so that the IETF stick to reality. While the IESG has mandated IPSEC for IPv6 while it can't be exported. This shows inconsistency with the definition of 'sticking to reality'. ------------------------------------------------------------------------ Start of NAT BOF attendees list Full Name e-mail ID ----------------------------------------------------------------------- Pyda Srisuresh suresh@livingston.com Steve Bellovin smb@research.att.com Scott Bradner sob@harvard.edu Robert Watson watson@vbo.dec.com Bertrand Buclin Bertrand.Buclin@ch.att.com Yanick Pouffary Pouffary@taec.enet.dec.com Peter Carson carson@vcx.lkg.dec.com Naoki Matsuhira matsu@vd.net.fujitsu.co.jp Makoto Nakamura naka@inf.furukawa.co.jp Francesco Prudente F.Prudente@telecomitalia.it Jerry Chu Jerry.chu@eng.sun.com Andrew Malis malis@casc.com Charlie Muirhead CMuirhead@incl.com James V. Luciani luciani@baynetworks.com Tom Meehan tommeehan@baynetworks.com Alfred Amman amman@baynetworks.com Wim Biemolf Wim.Biemolf@sec.nc Matthias Bauer bauer@uni-erlangen George Swallow swallow@cisco.com Laurent Dumont laurent@apple.com Mike Sneed mikes@pulse.com Bill Sommerfed sommerfed@apolkly.com Mikiyo Nishida west@sfc.wide.ad.jp Bredo oeveraas bredo@ripe.net Lee Wilmot lee@ripe.net Misjam Kuhne mis@ripe.net Steve Parker sparker@eng.sun.com Charles Kunzinger kunzinge@us.ibm.com Gunnal Lindberg lindberg@cdg.chalmers.je Christy Bonafield cbonafield@nwc.com Siegfried Lofflv fl@lf.net Bernard Sales salesb@btmaa.bel.alcatel.be Martial Monfoot martial.monfort@edfgdf.fr Ross Callon rcallon@casc.com Thomas Rosenstock thomas.rosenstock@den.siemens.de Allison Mankin mankin@east.isi.edu Steve Deering deering@cisco.com Sean kennedy liam@bbnplanet.com Brian Carpenter brian@harsley.ibm.com Jamez Skubic james.skubic@netinsight.se Suran de Sitra suran@nortel.ca Pedro Roque roque@cisco.com Yakov Rekhter yakov@cisco.com Kurt Jaeger pi@LF.net Vinod Valloppillil VinodV@microsoft.com Harald Koch chk@utcc.utoronto.ca Brian Field bfield@advtech.uswest.com Makoto Nakamura naka@inf.furukawa.co.jp Gary Malkin gmalkin@baynetworks.com Paul Raison praison@baynetworks.com Mike Wittig mwittig@mail.cybg.com Thomas Oeser thomas.oeser@isoc.de Philip Smith philip@uk.uu.net Anne Lord annel@uk.uu.net Peter Higginson higginson@mail.dec.com Jack McCann mccann@zk3.dec.com Mike Shand shand@mail.dec.com Jim Bound bound@zk3.dec.com Matt Thomas matt.thomas@altavista-software.com Mark Hollinger myth@ucx.lkg.dec.com James Ellil jte@cert.org Hiroshi Kurakami kurakami.hiroshi@na.tnl.ntt.co.jp Hirayuki Kitano kit@icat.or.jp Francesco Iceso iceso@net.telecomitalia.it Dan Nessett dan_nessett@3mail.3com.com Juerg Fankhansen fankhans@cselt_it Dan Madonald danmad@eng.sun.com Doug Junkins junkins@nwnet.net Ed Kern ejk@digex.net Andrew Partan asp@part.com Hank Kilmer hank@rem.com Dorian Kim dorian@blackrose.org Randy Bush randy@bogus.com Elfed Weaver Weaver@hydradra.hy.gb Dave Nolan noland@emh1.hqisec.army.mil Frank Solensky solensky@ftp.com Eric Mannie mannie@helios.iihe.oc.be Terry Davis terry.l.davis@boeing.com Jeremy Lawrence jlawrence@cisco.com Kevin Brock brock@netmanage.com Sara Bitan sarab@radghard.com Dave Jacobson dujake@vnet.ibm.com Hoe Trinh htrinh@raliegh.ibm.com John Tavs tavs@raleigh.ibm.com Naiwing Shen nshen@mci.net Sue Thienese set@bellcore.com Barbara Denny denny@3com.com Lixia Zhang lixia@cs.ucla.edu Jeff Haag jhaag@usr.com Sumit Vakil svakil@usr.com Pat Calhoun pcalhoun@usr.com Hamid Asayesh hamid@eng.sun.com Shohei Takeushi takeuchi@ccs.mt.nec.co.jp Hiroshi Kitamura kitamura@ccrle.nec.de Cheryl Madson cmadson@cisco.com Teno Monohan tmo@ssh.fi Kurt Dobbins dobbins@ctron.com Luca Gentili lucag@cineca.it Raymond Sit raymond_sit@eem.jf.intel.com Michael Lerpferger lerperg@fas.harvard.edu Bernard Volz volz@process.com George Tsirtsis george.tsirtsis@bt-sys.bt.co.uk Kevin Blakey kevin@msn.bt.co.uk Philip Bridge bridge@unisource.ch Brett Chappell bchappe@nswc.navy.mil Denise Heagerty denise@dxcoms.cern.ch