NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 25-Jan-99
Pyda Srisuresh <email@example.com>
Matt Holdrege <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Vern Paxson <firstname.lastname@example.org>
Transport Area Advisor:
Vern Paxson <email@example.com>
To Subscribe: firstname.lastname@example.org
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:
Submit Internet-Draft on what is NAT and how NAT works.
Submit Internet-Draft on NAT limitations and a list of applications and protocols known to have problems working with NAT.
Submit Internet-Draft on NAT friendly application and protocol design guidelines.
Submit Internet-Draft on Interaction of NATs with IP switching, roaming IP, mobile IP, IP multicast, DNS and other protocols and applications.
Submit Internet-Draft on security implications of NAT.
Submit Internet-Draft on Network Management Information Base for NATs.
· IP Network Address Translator (NAT) Terminology and Considerations<!999999>
· DNS extensions to Network Address Translators (DNS_ALG)<!999999>
· Traditional IP Network Address Translator (Traditional NAT)<!999999>
· Implications of NATs on the TCP/IP architecture<!999999>
· Protocol Complications with the IP Network Address Translator (NAT)<!999999>
· IP Network Address Translator Application Programming Interface<!999999>
· Security for IP Network Address Translator (NAT) Domains<!999999>
· NAT Friendly Application Design Guidelines<!999999>
· IP Host Network Address (and Port) Translation<!999999>
· An SNMP Application Level Gateway for Payload Address Translation<!999999>
· Realm Specific IP: A Framework<!999999>
· Realm Specific IP: Protocol Specification<!999999>
· IP Relocation through twice Network Address Translators (RAT)<!999999>
No Request For Comments
NAT WG meeting minutes - 44th IETF - Minneapolis, MN - March 19, 1999
Matt Holdrege email@example.com
Pyda Srisuresh firstname.lastname@example.org
Reported by: Ben Rogers email@example.com
Edited by: Matt & Suresh
1. RSIP IETF 44.PPT
Mailing list: firstname.lastname@example.org
To subscribe: Send e-mail to email@example.com with "subscribe" in the body of the message.
To unsubscribe: Send e-mail to firstname.lastname@example.org with "unsubscribe" in the body of the message.
Mailing list: email@example.com
(This is nat mailing list, in daily-digest format. To receive the digest, you can subscribe as follows.)
To subscribe: Send e-mail to firstname.lastname@example.org with "subscribe" in the body of the message.
To unsubscribe: Send e-mail to email@example.com with "unsubscribe" in the body of the message.
All presentations, along with WG meeting minutes will be avilable on-line from the following URL (Within a few days after this posting) http://www.livingston.com/tech/ietf/nat
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 - "WG Introduction"
IESG Document Status
Architectural Implications of NAT
Protoocl Complications with the IP network Address Translator (NAT)
NAT Friendly Applications Design Guidelines
An SNMP Application Level Gateway for Payload Address Translation
Realm Specific IP: A framework draft
Realm Specific IP: Protocl specification
IP Relocation through twice Network Address Translators (RAT)
Pyda Srisuresh - "IESG Document Status"
Reminded the audience about the Word from the ADs concerning presentation discipline, sent as part of agenda e-mail.
Presenters should focus on unresolved/outstanding issues rather than give tutorial of their drafts. We intend to operate this way from this point on, going forward. Further, most of the issues should be debated over the mailing list.
For those presenters, who came prepared with some educational viewgraphs, I would be glad to add those slides to the WG minutes, even as they donot get to present these slides.
Terminology draft - is intended to encourage the use of same common terms across drafts. This draft is a required reading for all NATWG attendees.
As for WG drafts with the IESG - the IESG has close to 4 drafts (The DNS-ALG went through WG last call but not resubmitted with changes folded in). Suresh has been working with the IESG members to remove ambiguities and clarify text in the terminology draft. As soon as the draft clears its way, other should follow right along.
Pyda Srisuresh - "Agenda change"
Offline meeting with the Tony Hain, the author of the IAB NAT draft will result in Tony making a new revision of this draft. This new copy of the draft will be discussed in the next meeting, if necessary. We hope, issues are discussed over the mailing list and the draft goes through WG last call much before the next IETF, so we dont have to pursue this until the next IETF.
[Tony Hain - If anyone has comments, please send them]
[Brian Carpenter - Can Tony tell us the date for the 04 draft?]
[Tony Hain - April 2]
[Brian Carpenter - We'd like to get any gut feelings out of this draft and try to make it more objective. This should become a draft that we all agree on, instead of an IAB or NAT authored draft.]
[Pyda Srisuresh - Yes, I fully agree with Brian's comments. We do like to have a single IAB/NAT-WG draft that people could refer.]
[Matt Holdrege - There is a significant positive difference in 03. The review was mostly intended to remove some ambiguities, so readings of 03 might bring up problems which have already been solved.]
Matt Holdrege - "Protocol Complications"
Little input has come back from this group. Matt has sent a note to all WG and BOF chairs requesting input and specific complications. Very little information was returned. This needs to become an RFC
[???? - Which protocols have we already heard from?]
The draft shows which protocols we have already looked at and found problems with.
Matt may look through protocols as he can to find possible problems.
Before the next rev of this draft, Matt will be working on reorganizing the draft to make it more organized and readable.
[Danny Raz - Can we make a list of protocols which have been known to be working with NATs?]
In theory, this is a good idea. In practice, it will be nearly impossible. It is very hard to actually say that something _certainly_ works with NAT, given obscure options, etc.
This will be taken under advisement.
[Brian Carpenter - We could add a disclaimer to cover liability. Many of the protocols belong to currently dead WGs. Other areas might not even imagine that they might need to respond to such a request, as they might not see how NAT might be used with them. eg: BGP4]
Pyda Srisuresh - "NAT Friendly application design guidelines"
<Suresh will be representing Daniel Senie, who could not be present for the meeting. Issues will be forwarded to Daniel if necessary.>
[Dan Raz - Plans for NAT friendly evangelism outside this document?]
No. Only to present the guidelines.
If anyone feels like this draft does not address any issues that particular protocols might have, we'd like to hear about them.
One of the issues might be that Address bindings are not guaranteed to last in NAT after the session that used the binding has terminated. Some applications such as RSVP require that the Binding parameters be kept alive, even after the session that caused the binding to originate has gone away. This could be a sticky problem area - Are there many such applications ??
But for a few nits, the draft does not seem to have any issues left and may be ready to move forward.
[Rhandeev Singh - DNS lookups? Should the application cache these lookups, or always do the lookup?]
The application should do the DNS lookups, but not cache the results longer than is advised in the response. DNS-ALG will set the responses to be valid for no longer than a second for dynamic address bindings.
Dan Raz - "SNMP-ALG"
· Two or more private networks use the same address space.
· A single management station is expected to manage both of them.
· Occurs during mergers and with network service providers
· Local networks cannot be reconfigured
· No changes to NM software
· Transparent to both NM application and to network elements
· SNMP Proxies require reconfiguration of the local network and possibly NM software changes.
These proxies are intended to support elements which do not have an agent.
NAT between n-1 overlapping networks and the NM station
· Can this be done using only per-packet information
Currently everyone has standarized on using UDP under SNMP. TCP is possible, but not currently supported.
· Private MIB and non-standard encoding
When the variables contain address information, then we need to translate those addresses.
IP address type is the standard way to encapsulate IP addresses, but we often see private encapsulations of those addresses.
There is much work that needs to be done to parse the SNMP packets.
· IP addresses are used as an index to MIB tables
· Translate only PDUs from network elements to manager (they have the data).
· Translate only standard IP address type encoding
· Does not change packet length and OIDs
· May be insufficient for some applications
[Thomas Narten - This doesn't work if you dont have the same number of global addresses as the number of machines you need to manage.]
Correct. This is meant to be static.
[Pyda Srisuresh - I believe, the requirement is simply that Whoever is assigning the mapping addresses for the various private networks needs to ensure that managed address do not overlap. These neednt be globally unique.]
[Thomas Narten - I cannot see why a network manager would want this.]
[Bernard Aboba - I'm confused as to what you're trying to manage.]
The situation at hand is a real world case, and is a real world requirement from network managers. This application reduces cost
[Thomas Narten - The information is now hidden and the network is now much more difficult to manage.]
This doesn't necessarily help manage, it works for situations where we could do nothing else.
[Bernard Aboba - Write an SNMP proxy. It is easier than NAT.]
[??? - won't work for SNMPv3]
Yes it will.
[Others - Explain nature of v3 authentication and hence cite the reason why SNMPv3 wouldnt work with this solution]
It will if the ALG has access to SA keys - The ALG can get this from the SNMP application.
[Thomas Narten - Same as IPsec end-to-end versus concatenated tunnels.]
The keys are still within a single organization.
[??? - Assume that all NATs are run by the same organization.]
[Matt Holdrege - Since this is a problem specific solution, this should be Informational.]
[Tony Hain - The applicability statement should be very strong to show that it will not work in all situations.]
[Steve Deering - Doesn't the proxy provide a better solution?]
No, that requires network reconfiguration.
[Brian Carpenter - The proxy would take the load off the normal packet processor, thus providing added advantage.]
The NM software gets confused with a proxy.
[George Tsirtsis - A proxy can always be used in place of an ALG, but the ALG makes more sense in some cases.]
[Brian Carpenter - The management station should be reconfigured to become NAT aware. Without this, there is no way to clearly visualize the network.]
Manufacturers of this software are looking to NAT to solve this as they don't want to rework their own code.
[Matt Holdrege - This discussion should be moved to the list.]
Michael Borella - "Realm Specific IP (RSIP) protocol Specification"
· Generalization and extension of HostNAT/DNAT
How many have read the draft? [more than 10] Not bad
· As RSIP is currently defined, spoofing can be used for denial of service.
· RSIP should eventually include authentication
We're looking for feedback on these security isssues.
[Pyda Srisuresh - Are these issues you raise different from that of of a DHCP protocol?]
No. Same issues exist in DHCP as well.
Problems which RSIP doesn't solve
· Policy fix at RSIP server
191. ICMP requires memory
192. External access to local services
[Bernard Aboba - This doesn't seem to work for IPsec tunnel mode for more than one host at a time.]
[Unless you have a table of SPIs, you wont be able to demux]
[Tony Hain - Make sure this is addressed]
[Pyda Srisuresh - Why is TCP TIME-WAIT a problem?]
[Thomas Narten - Problem with generic NAT, or is it induced by RSIP?]
Listed this as an issue because it was mentioned in the IAB draft.
[Timothy Shepard - ICMP issue]
Need some memory to properly send pings through
· Comments on the whole idea
· Evaluation of messages and parameters (too few, too many)
Is the protocol too complex, or is it lacking in certain areas
· End to end security
Will be submitting a draft on how to run end to end ipsec through RSIP.
[Gabriel Montenegro - Will the SPI be the demuxer?]
[Gabriel Montenegro - I have NAR draft out that addresses this and can be used as a basis for this area. The old draft has already had some scrutiny from IPsec folks in the last IETF meeting.]
[Gabriel Montenegro - Why not use SOCKS as the base and add extensions to supports the RSIP protocol?]
[Bernard Aboba - Concern about similarity between this and other protocols. How can we evaluate this against other alternatives?]
Will be addressed in architecture draft
[Brian Carpenter - RSIP is one solution. We could really use Map-and-Encap in order to compare.]
RSIP could be used for V6 transition such that IPv4 addresses are assigned to IPv6/v4 hosts. This could be explored in future versions of the draft.
[Pyda Srisuresh - The main goal of the draft must be to address Private-v4<=>Public-v4 issues adequately. Subsequent to that, you could work on making it extentsible to other areas, including IPv6 transition]
[Pyda Srisuresh - Can the server notify the client?]
Yes, to invalidate parameters.
[Pyda Srisuresh - Doesn't look like unsolicited messages are covered here.]
Not explicitly at this time.
[Pyda Srisuresh - Why does a node need to ask for multiple addresses at a time?]
Basic-NAT environment where we might need a distribution of a sub-pool of addresses.
[Pyda Srisuresh - You mean allocation between servers?]
Yes. The server should be able to act as a client to get multiple addresses.
[Pyda Srisuresh - This seems confusing and can lead to misconfigurations.]
[Pyda Srisuresh - On a different note, Address request and port requests should not be separate, when a host is requesting for a tuple of (IP Address, TU port).]
Request for address is combined with a request for a block of ports - for extensibility.
[Pyda Srisuresh - The protocol does not seem to take into account domains that are supported by Multiple NATs.]
Two RSIP routers for the same client? Is this realistic?
[Pyda Srisuresh - Yes]
[Pyda Srisuresh - Why do we need to consider twice-NAT?]
Twice NAT mentioned for completeness sake. Expresses desire to move the draft forward for the common case. Scope can be narrowed to accomplish this
[Pyda Srisuresh - You need to include bi-directional NAT.]
Yes, we will include that.
[Pyda Srisuresh - DNS needs to be discussed as well in conjunction with Bi-directional NAT.]
Jeffrey Lo - "RSIP Framework"
Brief discussion of how RSIP actually works.
· Lightweight negotiation of arbitrary parameters.
· Messages and parameter formats allow extensibility beyond the current specification.
RSIP Protocol Phases
RSIP server becomes aware of an RSIP client, and assignes a client ID ant tunnel type.
[Pyda Srisuresh - Isnt sequence number you use simply a message ID for message request and response correlation?]
[Pyda Srisuresh - Then, simply call it Message-ID, so it is less confusing]
[Pyda Srisuresh - Is the framework document discussing protocol issues?]
[Michael Borella - the framework document presents the problem that RSIP is trying to solve.]
[Pyda Srisuresh - Framework doc should consist only of requirements, scope and applicability. It may be referenced by the protocol document.]
[Pyda Srisuresh - A good area to mention in the framework draft is whether applications would be affected, or only the protocol stack.]
[Rhandeev Singh - Are you saying that we can do away with the DNS ALG?]
[Michael Borella - Not at this time.]
[Pyda Srisuresh - Is this something that the application does? It is not clear that the stack can do this.]
This needs to be studied.
[ed- Further discussion and bickering on location of this protocol (stack vs. application), socks, ...]
Messages and Parameters
[Pyda Srisuresh - Security Considerations seems to imply that the server should be a traffic cop for traffic generated by RSIP clients. The original intent was for RSIP clients to be able to take part in end-to-end IPsec. The traffic cop defeats this purpose.]
More on the mailing list
IP relocation through twice network address trnalators
Originally presented at mobileip WG
Is intended to be a bootstrap for mobileip. NAT is proposed for a quick-fix for initial deployment.
RAT and MobileIP Comparision
Relocation (Mobile-IP and RAT)
Seamless mobility (Mobile IP)
[Thomas Narten - What do you mean by this?]
RAT doesn't allow you to keep your connections as your address changes.
[Steve Bellovin - Why not use tunnel mode IPsec, which provides seamless mobility?]
This is not intended as a replacement for MobileIP, but merely to give people experience with mobility
Route Optimization (Mobile IP)
E2E Layer 3 Security (Mobile IP)
Immediate Utility (RAT)
· ALG requirements
Needed when applications don't work correctly. Free versions of ALGs are encouraged to be shared.
· Application Scenarios
When is RAT most applicable?
· VPN-like connectivity
· FIREWALL traversal
RAT-to-RAT tunneling across firewalls?
[Pyda Srisuresh - Concerns about using RAT for mobileip. Introductory section should be clear on what the advantage/motive is for using RAT.]
· PRIVATE home addresses
· RSIP enabling
[Pyda Srisuresh - What do you mean by a RAT device, and how does it relate to twice-NAT? We need an architectural description of what goes into a RAT device.]
Zero-knowledge will register with registration server. Registration server will the send configuration information to the RAT device (Twice NAT box).
[Pyda Srisuresh - How does the HA talk with the RAT device?]
RAT box will intercept packets from the Correspondent Node and NAT them on their way to the Zero-knowledge Mobile Node.
[Pyda Srisuresh - Is the RAT device doing the equivalent job as the Foreign Agent?]
It looks more like a Home Agent than a Foreign agent.
[Steve Deering - Traffic from Correspondent to Mobile Node undergoes Twice NAT?]
Only for Correspondent -> Mobile Node sessions. Sessions in the other direction are not translated at all.
[Brian Carpenter - How did the MobileIP group respond to this?]
Pretty much ignored.
[Hillary Orman - This seems more comparable to IPsec tunnel mode.]
Yes, but nobody is shipping it.
[Steve Bellovin - Lots of demand and implementations are emerging soon after the IPsec RFCs have come out.]
So, we're seeing a lack of support for RAT because IPsec gives us the functionality?
[ed- implied general consensus]
[Brian Carpenter - Many large coorporations have already rolled out tunneling solutions.]
The purpose of RAT/MobileIP is to provide mobility.
[George Tsirtsis - This tries to address something between roaming and mobility.]
No changes are required to Mobile Nodes. The RAT box instantly provides all functionality even to legacy hosts.
[Steve Deering - This seems ironic, as it uses NAT to help outisders to reach a global address.]
[Brian Carpenter - Since the time that MobileIP has started, we have given up on having fixed addresses. Too many hosts are forced to use private addresses.
Realm Specific IP Protocol Specifications