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