NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Pyda Srisuresh <srisuresh@yahoo.com>
Matt Holdrege <matt@ipverse.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
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. |
Internet-Drafts:
· Traditional IP Network Address Translator (Traditional NAT)
· Protocol Complications with the IP Network Address Translator (NAT)
· NAT Friendly Application Design Guidelines
· An SNMP Application Level Gateway for Payload Address Translation
· Realm Specific IP: A Framework
· Realm Specific IP: Protocol Specification
· RSIP Support for End-to-end IPSEC
Request For Comments:
RFC |
Status |
Title |
RFC2663 |
IP Network Address Translator (NAT) Terminology and Considerations | |
RFC2694 |
DNS extensions to Network Address Translators (DNS_ALG) | |
RFC2709 |
Security Model with Tunnel-mode IPsec for NAT Domains | |
NAT WG Minutes
Scribed by Daniel Senie
Matt Holdrege <matt@ipverse.com> and Pyda Srisuresh srisuresh@yahoo.com WG Chairs
Thursday, August 2, 2000, 9AM
Agenda:
- NAT Implications - Tony Hain
- NAT Protocol Complications - Matt & Suresh
- NAT traditional - Suresh
- RSIP drafts - Gabriel
- App Guide - Daniel
- Interface Framework - Suresh
- NAT WG Revised milestones
- Aboba-NAT-IPSec - William Dixon
- ipsec-nat-traversal - Steinberg
-------------------------------------------
Matt: Introductions. RSIP -> Experimental path being considered. Proposal stage only at this point, will be taken to the mailing list.
Tony Hain: IAB Draft. Current revision -08. Minor comments received from Suresh. Send Tony additional comments. Status: almost done, needs cleanup then publication.
Suresh: The draft does seem closer to being done - awaiting response to the comments sent.
Matt, Protocol Complications draft: IETF last call did the trick in getting comments. Comments incorporated. Draft will be sent to WG last call.
Suresh: reviewed changes made in most recent draft:
Added a section on common characteristics of protocols broken by NAT.
Draft redone to ensure there were no "pro-NAT" wording, or understatement of the problem.
New text for lack of support of Kerberos, X Windows issues (FQDN can't be used).
Send comments.
Suresh: Traditional NAT draft. WG last call and review complete long time back. Any additional comments, feedback still OK. Awaiting IESG review pending other base NAT drafts. Publication of all base NAT documents (IAB draft, NAT complications draft and traditional NAT draft) must happen together.
Gabriel: RSIP drafts. Revised framework specification and support for end-to-end IPSec.
Framework document: Mike Borella lead, introduction rewritten, replaced implementation considerations with requirements section. Added sections in multi-party applications and scalability. Toned down mobile IP interaction. Added reference to the SLP-RSIP draft, and added a table of contents. Protocol specification document: registrations have lease times. Management of lease times discussed. Most packet and field diagrams documented in canonical form. RSIP gateway can redirect a host to a particular tunnel endpoint not necessarily itself.
IPSec support document: put message time before overall length to align protocol with protocol draft 5 added message counter parameter.
Suresh: Comments: Discussion on IETF list about administrative / manageability of RSIP stack. Has this been added?
Gabriel: yes.
Suresh: Concern RSIP is significant effort to manage. Concern there's issues with how the control channel interacts with applications. There are many applications that are affected by the way RSIP control and application data paths interact, but haven't been addressed.
Gabriel: expects there are holes, needs a summary or to do some research in this area. Multi-party case, is a good example, the RSIP folks don't know how to address these.
Action item: Gabriel will research updates to deal with the issues. Suresh will try to get some summary information from the discussion on the IETF list to Gabriel.
Mike Handley (sp?): Blanket statement that there's no need for ALGs in RSIP. Believes there could be more explanation.
Suresh: Assumption is that with RSIP replacing NAT, this obviates the need for ALG (end host will do the work).
Protocol draft: last message buffer discussion could use clarification. Is it per-host? Matt: Yes.
Daniel: draft-ietf-nat-app-guide-03.txt received few comments. Suresh suggested adding a section on peer networking, mirroring the protocol complications draft, and suggested verifying similar content match-up with other areas.
Suresh: Interface Framework document. Foglamps mailing list discussion of mechanism to control firewalls and NATs and control resources. Very similar to what's in this draft, which has added interest to this draft. Now interest in building a protocol for interfacing with NAT/Firewall. This document could be the basis for such work. Interfacing with ALG both internal and external, administrative agents, RSIP clients, multihomed-NATs, and so forth. Addresses foglamps issues relating to NATs (not firewalls), but could be used in that area. Would like to move this document along within the WG.
Milestones: Matt: we're late. Milestones not met. Base documents are about ready. the IAB draft also a gating factor.
Suresh: By early next year, WG milestones should be completed, provided the base NAT drafts are cleared with IESG.
Brian Carpenter: should RSIP be split out to a separate WG to get it completed?
Matt: not clear it'd get more attention as a separate WG. In any case, it's an IESG issue.
Alison: IESG will discuss as a part of the charter discussion.
Gabriel: RSIP really separate from NAT, and would prefer if it were split off.
Suresh: 9 months ago, ADs thought the NAT WG be the place to put it, but in the mean time, the NAT drafts haven't progressed so quickly.
Matt/Alison: take hum of the room. Seems to be rough interest in splitting RSIP off into separate WG. Alison will take input to IESG and see what consensus is.
Bernard Aboba: NAT and IPSec discussion: draft-aboba-nat-ipsec-02.txt. Will talk about the problem here, not solutions. Solutions will be discussed at IPSec group.
Goals and objectives: Describe the scenarios and issues. Usage scenarios: Telecommuters with IPSec and NAT because of DSL/Cable modems. Tunnel scenario. Transport mode is seen as extremely difficult at this point. Compulsory tunneling cases exist with ISPs and other upstream cases. Various discussion from the floor about DSL, cable modems and STSN/hotel system.
Suresh: Can it work with IPSec running in the NAT box? Bernard's experience is customers don't handle it.
Bob Moskowitz: Providers forcing IP address changes often via DHCP as a way to limit servers on cable modems and such. Makes matters even worse.
Known Nat/IPSec incompatibilities: AH, checksums (pseudoheader issue). UDP checksum is optional, providing a way around.
Alison comment that they should be used, however. Tunneling discussion: if inner packet is unaffected. IKE allows other identifiers, not necessarily just IP addresses. Issues with embedded IP addresses within NAT (in payload).
Incompatability between IKE destination ports and NAPT. Source ports will be changed. Re-key can occur on either side. Re-key coming from server looks like unsolicited packet, and NAT will drop it. NAT Port timeouts a big problem here, as the mapping would have to keep the association alive. In transport mode, Incompatibility between overlapping security policy and NAT policy. Makes for difficulty in deciding where to send information. Without client-nat communication this is a problem.
Suresh: request quick mode vs. main mode issues be isolated. Incompatability between SPI selection and NAT: issue is SPI of packets incoming to NAT with out client-nat communication NAT must depend on timing. A problem nearly all the time.
Summary: NAT compatability critical to key uses to Ipv6. Incompatibilities substantial and intricate. Goal is to find a solution sooner than Ipv6.
Brian Carpenter: 6-to4 has the same problem. Floor question: how about tunneling IPSec over L2TP.
Marcus Stenberg: Short talk about his draft. Only requires changes in end station.
Marcus Leech (AD): IPSec WG will be chartered to deal with the interoperability issues.
End Of Meeting