NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99
Chair(s):
Pyda Srisuresh <srisuresh@yahoo.com>
Matt Holdrege <holdrege@lucent.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Vern Paxson <vern@aciri.org>
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
· IP Relocation through twice Network Address Translators (RAT)
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 meeting minutes - 46th IETF - Washington, DC - Nov 7, 1999
Chairs:
Pyda Srisuresh - srisuresh@yahoo.com
Matt Holdrege - holdrege@lucent.com
Reported by:
George Tsirtsis - gtsirt@hotmail.com
Gabriel Montenegro - Gabriel.Montenegro@Eng.Sun.COM
Prepared by: Suresh & Matt
In order to avoid confusion, the following indentation and format legend should be used as a guide to interpreting the minutes.
<Presenter> - "<presentation/Discussion Topic>"
<Remarks by minutes taker or editors>
Detailed Slides and/or Comments made by the presenter
Questions from the Audience:
[<Audience-Name> - <Question/Comment>]
<Response from the Presenter>
Matt Holdrege - Agenda
Daniel Senie
- draft-ietf-nat-app-guide-02.txt
Dan Raz
- draft-ietf-nat-snmp-alg-02.txt
Pyda Srisuresh
- draft-ietf-nat-interface-framework-00.txt
Mike Borella, et al
- draft-ietf-nat-rsip-framework-02.txt
- draft-ietf-nat-rsip-protocol-03.txt
- draft-ietf-nat-rsip-ipsec-00.txt
Carmello Zaccone
- draft-zaccone-nat-rsip-gen-arch-00.txt
- draft-zaccone-nat-transo-fram-00.txt
- draft-zaccone-nat-transport-01.txt
Matt Holdrege
- draft-ietf-nat-protocol-complications-01.txt
Vern, Transport Area AD, said that ipr should be disclosed as early as possible. if you can't disclose, you MUST abstain from discussion of the technology. you have a moral obligation to do so. no comments on what would happen if you don't abide by this ietf policy.
daniel senie - nat-app-guide-02.txt
Comments received from Suresh but not from anyone else. More comment are welcome. Will get a new rev of the draft out shortly.
dan raz - nat-snmp-alg-02
defined further problem scope, limitations and alternatives solutions, eliminated snmp discussion
- basic: translates only ip addresses only in pdu's from station to manager
- no change in pkt length
- advanced: xlates non-standard encodings, xlations in pdu's from
- station to manager and back. results in change of pkt length.
- real need from the nw mgmt service provider industry
Juergon: There are technical problems (sorry for not having time to do this on the list). Need to discuss snmpv3 (not just v1), also some conclusions and mechanisms are suspect.
answer: we're addressing industry need, and nobody is using v3 today.
suresh: what are the issues?
answer: main concern - we need to know what snmp alg can do and cannot do and impacts/consequences on snmpv1 versus v3
matt: should discuss v3, but v1 is definitely in order.
suresh - nat-interface-framework-00
- framework for interfacing with nat.
- predecessor: nat api draft (bad name)
There is renewed interest in the draft because of (a) mib spec for nat, (b) requirements on how to interface with a NAT as an alg, etc. so revised and reworded the old draft to address these issues specifically. This draft should also help in identifying RSIP protocol requirements.
Also described is how an FTP-ALG would use the interface to influence NAT operation.
FTP-ALG registration process expressed in the context of this framework functions exchanged between the ftp-alg and the nat gw working group polled for any comments.
Elliot Lear: Is there support for moving this forward as an RFC?
No comment from the audience.
Suresh: Anyone who doesnt want the draft move forward?
No comment from the audience.
Elliott: The draft should move forward only if there is explicit request from the work group instead of operating the other way around.
No comment from the audience.
mike borella - RSIP drafts
RSIP framework draft-
- major editing and reorganization
o client and server reqs
o mtu stuff
o rsap-ip servers
o deployment scenarios
o rsip/nat cascades
o multi-homed (preliminary)
o mobile ip (preliminary)
- rsip behind rsip
o nat behind rsip
o e2e still broken
o nat box is rsip client
- rsip behind nat:
o e2e broken
- rsip through nat
o need rsip alg in nat box
- only rsip behind rsip makes any sense, really
- but as you deploy rsip into a natted world, this is a good document
Multihoming
- more than 1 rsip gw per net for redundancy and failover
This can be addressed in different ways from simple mechanisms to heavy weight (transaction processing type of thing) but it is not critical for RSIP at this stage.
interaction with mobile ip
- how to add rsip stuff to mobile ip
- some preliminary discussion, but need to flesh it out and
- coordinate with mobile ip working group
suresh: it's ok to not finish everything on the first round, as long as you scope clearly what is being solved. Need to finish the framework and basic protocol first. Work on other issues in parallel.
Matt: you can always ask the mobile ip list for comments.
Brian Carpenter:
Need to know if there are show stoppers in mobile IP and any other protocol, details can be worked out later.
Mike continue with the presentation.
next steps - Still need to work on the following:
- rsip and mcast
- rsip/rsvp/diffserv
- registration of servers via dns servers
- locating rsip servers - particularly if you're not on the
- same subnet - Use dhcp or SLP?
- session authentication
must scope rsip to be able to finish it (at least partially) within the near future
suresh: is rsip an app specific configuration or host specific on the client? There might be reasons to only use RSIP for a set of applications.
matt: It is stack specific.
Gab: similar problem to mobile ip and ipsec: it's possible to use it selectively
Elliot: Much better than last draft. Still some issues with the draft:
- How much routing is required in the client? Does host need Routing info? routing tables in the client can get fairly complex. must clarify.
- How does it use SLP?
- There are some security implications. what if you use ipsec for the rsip tunneling from the outside? nobody can determine who is actually speaking to whom. this is both good and bad and should be documented.
- What if you rap RSIP in IPSEC? Some interesting trust relationships.
Danny Raz: UDP packet size might be larger than what the spec says.
- udp mtu of 500? where from?
suresh: Two points:
- A node should be able to select when to use NAT and when to use RSIP.
- You may have multiple RSIP instances. RSIP instance ID is needed to select which RSIP instance (i.e., address pool) to use.
Elliot lear: Two points.
1. rsip is a remediation. it's got overhead. Applications should be able to do things other than RSIP. Need to discuss on e-mail
2. cascading rsip servers you used public address space, this is the right thing. when you cross realms the recommendation worth restating is that you use public addresses.
Brian Carpenter: on point 2 above, clear conclusion from the iab workshop is that the global address space is a requirement
- on point 1 above: application must be aware?
- no, then just use ipv6. that's the whole point.
RSIP protocol draft -
Streamlined. One way of doing rsip. Basic primitives to do rsip. Anything else should go in a separate draft (like rsipsec)
To be done:
- overall length field in msgs
- error messages must be fleshed out
What should be the trasport medium for RSIP? - tcp vs udp
Matt: If there are no objection the best thing is to have only one transport protocol and this is TCP. If later we realise that UDP is needed for a case we can do it later.
Mike: I agree
suresh: Server could support both and client should be able to choose between the two since the RSIP protocol does not depend on the underlying transport medium.
Mike: In fact there might be changes in the protocol. E.g some things are not needed if you do TCP.
Eliot: Also agrees that ONE protocol is best but RSIP seams too lightweight for heavy TCP connections.
Mike: Other things constrain RSIP resources before TCP state becomes a problem
Elliot: What are the benefits of TCP?
Mike: better security, reliability
Bernard: TCP also helps with state control since the TCP connection will drop if a client crashes.
Gabriel: Auto-tuning can solve the large number of TCP connections problem.
Matt asked for show of hands: The rough consensus was to use TCP-only as the transport.
UDP may be brought in later on.
Suresh: Couple of other comments.
- After hearing Brian Carpenter's comment about applications not requiring change with RSIP, I agree with him. Now, I do believe, RSIP should be host specific - not application specific.
- More examples are needed during protocol specification.
- There seems to be an underlying assumption throughout the the document that address assignment is a function of the RSIP server and that address assignment and tunneling are in the same box. (Mike says yes!)
- Other than tunnels might also be used to traverse RSIP packets in private realm. Ex: Zaccone drafts, NAT based translation of encapsulating header.
Mike: Tunnel is the only mechanism we are sure will work at the moment.
RSIP IPsec draft -
Just made the cut-off day. Some work is still needed here.
Gabriel Montenegro: Need discussion on how to handle incoming SAs
Bernard Aboba: There might be an issue with interactions with IPSEC bump-in-the-stack implementations.
carmelo zacconi - RSIP transport (within private realm) framework
Possible extensions on the RSIP framework on the transport of datagrams in a native way without using tunnels.
Enable forwarding of incoming packets without tunneling to the rsip client
How to enable these reverse paths? the other drafts explore specific mechanisms with their tradeoffs. Specific mechanisms to build the reverse path are:
1. ospf minimized router daemon on the host
2. multicast - create a tree
3. rsvp - install info on a restricted set of routers
RSIP-gen-arch -
Aim to make RSIP more reliable
De-couple set of functions from RSIP server
Support RSIP multihoming
Offer policy and accounting
Assume multiple ISPs and multiple function blocks building RSIP (Policy Manager, Internet Session Manager and Configuration Manager)
Brian Carpenter:
1. The idea of not using tunnels when you can is good.
2. Multihoming needs to be solved but this seams like a very complex solution because it attempts to define an architecture. IETF only defines tools.
3. Reliability is important but having a lot of stateful boxes is against Internet design principles and may damage the stability of the whole system.
Gabriel Montenegro(Gab):
On the transport alternatives: suggest to have routing ADs look at this, as this is not specific to rsip but may apply in other areas as well, and is hightly routing specific in content.
Eliot Lear: Many interesting points in the draft (not agree with all). Not using tunnelling is also good if you try to do things like Diffserv. The separate Policy Manager is also a good idea.
Suresh: The draft is interesting and may have wider applicability as the draft is really about RSIP route/policy enforcement on the routers in private realm.
Mike Borella: This is interesting for rsip+ but is perhaps not part of rsip first release.
matt holdrege - NAT protocol complications.
Matt will issue an IETF last call after the next rev is posted.
Tony Hain: Scott bradner currently has the pen on the IAB document.
Should get a new rev out in a couple of weeks (by the end of 11/99?)
james kempf (sun) - Using SLP for RSIP server discovery
why not to use DHCP; but use SLP:
- dhcp requires configuration on the server (home networks?)
- slp requires nothing but the rsip server
- slp uses mcast (versus bcast)
- dhcp can't specify attributes
- slp can find server based on attributes
- option number space in dhcp is running out
- slp is not a problem, define a url/template, text based
- dhcp can't do dynamic updates
- slp reflects availability dynamically
Template for rsip servers
template-type = rsip
template-version = 0.0
url-syntax = ;nothing_beyond: host:port
ipsec-support = BOOLEAN
ike-support = BOOLEAN
tunnel-type = STRING L
etc.. draft forthcoming
suresh: seems applicable
Elliot lear: how to handle multiple rsip servers?
jim kempf: slp has a semi-reliable mcast called mcast convergence which can aid in this
Mike borella: looked at dhcp individual submission draft that defines dhcp option for server redirect
suresh: suggests this draft be submitted as working group item. seems like a good idea to have both options - DHCP configuration option as well as SLP.
None received.