Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/97aug/nat-minutes-97aug.txt

Text File | 1997-10-10 | 18KB | 386 lines

             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
[e-mail] with line "unsubscribe nat" in the body of
message.

Details of the mailing list are as follows:

        Mailing List:      [e-mail]
        To join the list:  Send email to [e-mail] with
                           "subscribe" in the body of the message.
        To leave the list: Send email to [e-mail] 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          [e-mail]
Steve Bellovin          [e-mail]
Scott Bradner           [e-mail]
Robert Watson           [e-mail]
Bertrand Buclin         [e-mail]
Yanick Pouffary         [e-mail]
Peter Carson            [e-mail]
Naoki Matsuhira         [e-mail]
Makoto Nakamura         [e-mail]
Francesco Prudente      [e-mail]
Jerry Chu               [e-mail]
Andrew Malis            [e-mail]
Charlie Muirhead        [e-mail]
James V. Luciani        [e-mail]
Tom Meehan              [e-mail]
Alfred Amman            [e-mail]
Wim Biemolf             [e-mail]
Matthias Bauer          bauer@uni-erlangen
George Swallow          [e-mail]
Laurent Dumont          [e-mail]
Mike Sneed              [e-mail]
Bill Sommerfed          [e-mail]
Mikiyo Nishida          [e-mail]
Bredo oeveraas          [e-mail]
Lee Wilmot              [e-mail]
Misjam Kuhne            [e-mail]
Steve Parker            [e-mail]
Charles Kunzinger       [e-mail]
Gunnal  Lindberg        [e-mail]
Christy Bonafield       [e-mail]
Siegfried Lofflv        [e-mail]
Bernard Sales           [e-mail]
Martial Monfoot         [e-mail]
Ross Callon             [e-mail]
Thomas Rosenstock       [e-mail]
Allison Mankin          [e-mail]
Steve Deering           [e-mail]
Sean kennedy            [e-mail]
Brian Carpenter         [e-mail]
Jamez Skubic            [e-mail]
Suran de Sitra          [e-mail]
Pedro Roque             [e-mail]
Yakov Rekhter           [e-mail]
Kurt Jaeger             [e-mail]
Vinod Valloppillil      [e-mail]
Harald Koch             [e-mail]
Brian Field             [e-mail]
Makoto Nakamura         [e-mail]
Gary Malkin             [e-mail]
Paul Raison             [e-mail]
Mike Wittig             [e-mail]
Thomas Oeser            [e-mail]
Philip Smith            [e-mail]
Anne Lord               [e-mail]
Peter Higginson         [e-mail]
Jack McCann             [e-mail]
Mike Shand              [e-mail]
Jim Bound               [e-mail]
Matt Thomas             [e-mail]
Mark Hollinger          [e-mail]
James Ellil             [e-mail]
Hiroshi Kurakami        [e-mail]
Hirayuki Kitano         [e-mail]
Francesco Iceso         [e-mail]
Dan Nessett             [e-mail]
Juerg Fankhansen        fankhans@cselt_it
Dan Madonald            [e-mail]
Doug Junkins            [e-mail]
Ed Kern                 [e-mail]
Andrew Partan           [e-mail]
Hank Kilmer             [e-mail]
Dorian Kim              [e-mail]
Randy Bush              [e-mail]
Elfed Weaver            [e-mail]
Dave Nolan              [e-mail]
Frank Solensky          [e-mail]
Eric Mannie             [e-mail]
Terry Davis             [e-mail]
Jeremy Lawrence         [e-mail]
Kevin Brock             [e-mail]
Sara Bitan              [e-mail]
Dave Jacobson           [e-mail]
Hoe Trinh               [e-mail]
John Tavs               [e-mail]
Naiwing Shen            [e-mail]
Sue Thienese            [e-mail]
Barbara Denny           [e-mail]
Lixia Zhang             [e-mail]
Jeff Haag               [e-mail]
Sumit Vakil             [e-mail]
Pat Calhoun             [e-mail]
Hamid Asayesh           [e-mail]
Shohei Takeushi         [e-mail]
Hiroshi Kitamura        [e-mail]
Cheryl Madson           [e-mail]
Teno Monohan            [e-mail]
Kurt Dobbins            [e-mail]
Luca Gentili            [e-mail]
Raymond Sit             [e-mail]
Michael Lerpferger      [e-mail]
Bernard Volz            [e-mail]
George Tsirtsis         [e-mail]
Kevin Blakey            [e-mail]
Philip Bridge           [e-mail]
Brett Chappell          [e-mail]
Denise Heagerty         [e-mail]