NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98
Chair(s):
Pyda Srisuresh <suresh@livingston.com>
Matt Holdrege <matt@ascend.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:nat@livingston.com
To Subscribe: nat-request@livingston.com
Archive: ftp://ftp.livingston.com/pub/archive/nat
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:
Aug 98 |
|
Submit Internet-Draft on what is NAT and how NAT works. |
Aug 98 |
|
Submit Internet-Draft on NAT limitations and a list of applications and protocols known to have problems working with NAT. |
Dec 98 |
|
Submit Internet-Draft on NAT friendly application and protocol design guidelines. |
Dec 98 |
|
Submit Internet-Draft on Interaction of NATs with IP switching, roaming IP, mobile IP, IP multicast, DNS and other protocols and applications. |
Dec 98 |
|
Submit Internet-Draft on security implications of NAT. |
Apr 99 |
|
Submit Internet-Draft on Network Management Information Base for NATs. |
No Current Internet-Drafts
No Request For Comments
Minutes of the Network Address Translators (nat) Working Group
Chairs: Matt Holdrege (matt@ascend.com) and
Pyda Srisuresh (suresh@livingston.com)
Reported by Ben Rogers
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.
Slide presentations:
1. NAT agenda, milestones and applicability - by WG chairs
2. EIDs, IPsec, and HostNAT - by Steve Bellovin. Slides may be found at
http://www.research.att.com/~smb/talks/hostnat.ps (or)
http://www.research.att.com/~smb/talks/hostnat.pdf
3. Few comments on draft-iab-nat-implications-00.txt - by Yakov Rekhter.
All of the slides presented during NAT WG, along with meeting minutes are available on-line from the following URL: http://www.livingston.com/Tech/IETF/nat
Matt Holdrege introduced the Agenda
· Word from the AD
· Prioritize objectives in charter
· Discuss RFC packaging
· Groundwork for the following:
- NAT limitations, NAT friendly appl. guidelines
- Security issues, alternate solutions & ideas
- Impact of NAT on IP protocols and applications
· Review NAT draft
Security issues with NATs
Steve Bellovin on "IPsec, EIDs, HostNAT"
Review IAB Draft
Tony, Yakov and others
Scott Bradner: AD
Introduced the formation of the working group as an "encouragement of something that hurts", but with the goal of carefully monitoring and providing guidelines for NATs.
Made reference to the IAB draft, to be presented later by Tony and Yakov.
Suresh
Purpose of the meeting is to discuss goals for future movement, including hammering out the charter into something that would be usable for the group.
How can we improve experience with NATs:
· Make them easier to debug.
· Painless interaction with DNS, DHCP and other commonly used network applications.
· More applications that are NAT friendly and don't violate the layering model.
· Stable and reliable NAT implementations.
· MIB to manage NATs from remote sites.
· Redundant/Backup NATs.
Matt H.
Review of WG milestones
August 1998
· What is NAT, and how does it work (limiting the scope of discussions in the WG)
· Draft of limitations and a list of protocols which are currently non-NAT friendly (Using the current draft, or restarting, [Scott B. -- or utilizing the IAB draft])
December 1998
· NAT friendly applications and protocol design guidelines
· Draft on interaction of NAT with switching, roaming, mobile, multicast, DNS, [Baiju Patel from IBM -- Is this achievable in this timeframe?]
· Security implications
April 1999
· MIB for NATs
[Eric Fleischman -- How do we manage networks which have NATs in them? Should this be added to the milestones or objectives?
[Scott Bradner -- Add this to the Apr 99 deadline]
[Dina Feder -- Does IPsec need highlighted in the Interaction draft?]
Suresh. This should be taken care of in the security implications draft.
[Sid Nag -- Do we deal with Application Level Gateways, or only NATs] Suresh Focus will be on NATs, with possible spillover into payload considerations for groups of applications which behave in like-manner.
[??? -- Add Socks to the application list (Dec 98 milestone)?] OK.
[Dina Feder -- Security implications of NAT in the VPN PWG instead of NAT?]
This belongs in the NAT group, as we are discussing security considerations in the context of NATs.
[??? -- IntServ and RSVP added to interaction draft?] Perhaps splitting into separate drafts?
[Scott B. -- Continue on mailing list]
Suresh RFC packaging to be carried on in the mailing list.
Groundwork for the following in the mailing list:
· NAT Limitations, NAT friendly appl. guidelines.
· Security issues, alternate solutions & ideas.
· Impact of NAT on IP protocols and applications.
Security considerations should not be restricted to IPsec alone, even though IPsec is an important part of it. There are also other dimensions to security that we should focus on. For example, Vipul (SUN Microsystems) is working on a draft that deals with corporate resource security for mobile users. The resource security here is accomplished by employing a combination of NAT and Firewall at the borders of enterprise network.
[Yakov -- Suggestion of adding a document for multihoming with NAT]
OK.
[Scott B -- Review NAT draft after Security Issues]
Steve Bellovin
EIDs, IPsec and HostNAT
Endpoint identifiers
· Provide a /name/ for a host.
· Distinguish the name from a /locator/ (IP address), the way we find the host.
· Today IP address fill both roles
· Problems with mobility, renumbering. EIDs help resolve many of these issues.
· However, EIDs make packet headers larger.
IPsec
· Set up secure communication path between two hosts
· Actually, the path is between two certificate holders.
· A /security association/ identified by SPI and implicitly points to other data - Cryptographic algorithms, certificate name, IP address etc.
Security Associations are EIDs
· If you're using IPsec you already have strong auth of who your peer is.
· The IP address is irrelevant, except as a locator.
· This is not a per-packet overhead (no explicit EID needed)
· With IPsec, we have EIDs as long as implementations aren't too picky about checking IP addresses on incoming packets (using the auth check to determine who the remote end is)
Implications for NAT
· If IP addresses don't matter, we can change them on the fly.
· We still have issues with the TCP pseudo-header. Experimental code for TCP pseudo-header (See Huitema's draft)
· And, there's always the embedded address problem.
HostNAT
· Must NAT take place at the border?
· Host knows about its protocols, embedded addresses, etc.
· Use TCP renumbering, encap, IPsec, etc. to allow the outside address to be done at the endpoint. Perhaps a virtual interface with a dynamic outside addresses.
· IPsec EIDs handle circuit association. If we do this, how do we find the locator? That is the remaining issue.
Refs
EIDs http://users.exis.net/~jnc/tech/endpoints.txt - (Noel Chiappa)
TCP address Change http://www.chem.ucla.edu/~beichuan/etcp/ - (Christian Huitema)
These slides may be found at: www.research.att.com/~smb/talks/hostnat.[ps|pdf]
[Baiju Patel -- Do EIDs have to be unique?] Migration of service from one host to another.
[Spencer Dawkins -- Unique within which scope?] Unique within in the universe of discourse.
Tony Hain
Draft from the IAB
IABs roles include commenting on how things impact the architecture. Applicability statements should be necessary in the drafts. IAB will continue to provide the draft on the arch. impact unless the WG can provide a suitable replacement. NATs will be digging a big hole in the network
[Suresh -- not enough to say that NATs are digging a big hole, but you need to also describe the type of hole NATs are digging, and where. NATs operate in the border and do not impact the backbone (core) routing tables or Internet stability]
Tony Who gets to define border or core or any of the other terms involved?
[Suresh -- applicability in the "What is NAT" draft would address this.]
[Suresh -- What is the issue with DNS, using distinct internal and external addresses, but same names?]
[Noel Chiappa -- Does the NAT WG want to comment on possible changes to other protocols, or is that the IAB's job]
Scott B. Both WG and IAB will discuss this.
[Matt H. -- We will not dictate to other groups what they might do to be more friendly]
[Scott B. -- This group can make suggested changes as long as it does not make the other protocols less secure. Documents from this draft will be informational only.]
Yakov Rekhter
Comments on the draft
On "Name space inconsistency" - theory
"A significant failure of NAT is the name space inconsistency"
"When DNS is required to resolve a given host name on both sides of a NAT there is no good answer"
On "Name space inconsistency" - practice
A DNS server always returns the same information (same answer), regardless of whether a query came from inside or outside.
DNS ALG component of a NAT modifies DNS reply.
· Hosts "inside" see "local address"
· Hosts "outside" see "global address"
Address management in VPN
· Claim:
- "Address management in the 'hidden space' behind NATs will become a significant burden as there is no central body capable of, or willing to do it"
This is not a burden, but a feature as it allows finer grained management.
o Discussion:
> Why use of private address space "will become a significant
burden" ?
NATs and Security
· Claims:
- "The greatest concern from the explosion of NATs is the impact on the fledgling efforts at deploying IP security"
- "... represents a tremendous risk to deployment of enhanced security across the Internet"
- "... the greatest single threat to security integration being deployed in the Internet today"
- "... inhibit the roll out of IPSec, which will in turn slow growth of applications that require a secure infrastructure."
NATs and Security
o Discussion:
- IPsec is not the only way to provide end-to-end security
- SSL is a viable option.
- IPsec doesn't provide user-user security.
- IPsec can still be used between NATs.
NAT Overhead
· Claim:
- "There is a Small but significant overhead involved as checksums are recalculated for every packet"
· Discussion:
- Need quantification.
NAT and IPv6
· Claim:
- "The existence of NATs will complicate the integration of IPv6"
· Discussion:
- It is not clear whether transition to IPv6 could be accomplished without NATs. One transition method actually uses NAT.
- Use of NATs could make integration of IPv6 unnecessary
"Forward motion"
· Claim:
- "At best, NATs are a diversion from forward motion..."
· Discussion:
- Why?
What is next?
· The I-D as an input, and Revise it to:
(a) Correct factual errors
(b) remove FUD
(c) clearly separate facts from opinions
(d) present alternative opinions
[Bob Moskovitz -- correct Security Slide. SSL is not usable for UDP or other IP applications, and was more of a short term solution. IPsec will be needed for end-to-end security, especially to help provide identity]
[Steve Bellovin -- IP is the point of maximum leverage, thus IPsec is more globally useful than SSL]
[Noel Chiappa -- Work on IPsec through end-to-end boxes]
[Bob M. -- Work for IPsecond. Lot of remaining work, especially with chained SA tunnels and transports. Including issues of TCP checksums...]
[Ross Callon-- Transition issue. Many different alternatives, but the main transition method is a dual-stack method. The dual stack will prevent problems with NAT during transition.]
IPv6 or IPv4 only hosts...
[Ross Callon -- Application gateways to address this problem]
Matt H.
Presented a slide with a diagram on the deployment scenarios of NAT at the borders of a V6+V4 interconnected Global Internet network.v4 and v6 interconnected core network, accessed at the borders by disjoint stub networks (such as v4 private networks, v6 only networks, and (v4 + v6) private networks) using NAT technology.
Suresh
WG would like to help in doing a rewrite of the IAB draft.
[Scott B -- Yakov will want to do this]
[Brian Carpenter -- Will Yakov and IAB work as co-authors? This is TBD.]
Review of NAT draft (call for comments) (none)
Moving forward on the draft, perhaps with interaction with the IESG
This draft will be used as a basis for "What is NAT?" draft if possible.
[Scott B -- Raise issues on mailing list. Include applicability statement in or along with the standards RFC.]
Adjourned.