NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99
Chair(s):
Pyda Srisuresh <suresh@ra.lucent.com>
Matt Holdrege <matt@ascend.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:
· IP Network Address Translator (NAT) Terminology and Considerations
· DNS extensions to Network Address Translators (DNS_ALG)
· Traditional IP Network Address Translator (Traditional NAT)
· Implications of NATs on the TCP/IP architecture
· Protocol Complications with the IP Network Address Translator (NAT)
· IP Network Address Translator Application Programming Interface
· Security for IP Network Address Translator (NAT) Domains
· NAT Friendly Application Design Guidelines
· IP Host Network Address (and Port) Translation
· 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)
No Request For Comments
NAT WG - Oslo - Tuesday, July 13th
Chair: Matt Holdrege <holdrege@lucent.com>
Reported by:
- Gabriel Montenegro gab@Sun.COM
- George Tsirtsis <george.tsirtsis@bt.com>
agenda bashing - The Agenda was accepted
Milestone status
The NAT Terminology and Considerations draft was approved by the IESG and will soon receive an RFC number. This is a very important document as it describes the terms that all IETF documents should use when discussing NAT.
Other drafts in the works are...
- dns-alg draft
- traditional nat
- nat api
- security for nat domains
- nat friendly app designs
- hnat
- snmp alg
- rsip (framework, protocol, ipsec)
Each can be found on the IETF NAT WG web page.
There is some delay in the milestones due to the extensive review of the NAT terminology draft.
Protocol Complications - Matt Holdrege -
draft-ietf-protocol-complications-01.txt
The updated draft is available on the IETF web site.
Matt solicited input from NAT WG and all other WG chairs but has not received a lot of feedback. We need to understand which applications do not work with NAT including non-IETF applications. (vendor specific etc).
- There is a suggestion to make this Informational RFC shell and put the text on the Web so it can be updated
- Someone pointed out that Web - RFC links may be unstable so RFC should be stable and self contained
- The Weird WG is trying to put all RFCs in Web Form, NAT could be a pilot project
- Matt wants to make the ITU and other external bodies aware of this document so IP technology developed outside the IETF can consider NAT.
- Matt also is thinking about more than the general usage of NAT. The typical use: home user going out to global internet (1 nat) and back into a corporation (2nd nat).
Vern said that the doc should be as self-contained as possible.
RSIP - Mike Borella <Mike_Borella@3com.com>
Three RSIP drafts exist. A framework document , the RSIP protocols specification and RSIP interactions with IPSEC document.
- draft-ietf-nat-rsip-protocol-01.txt
- draft-ietf-nat-rsip-framework-01.txt
- draft-ietf-nat-rsip-ipsec-00.txt
Framework Document
Public Internet to private intranet connections need to be studied further.
George Tsirtsis: May want to look at DSTM and NAT-PT in NGTRANS WGs that study a similar problem.
.
Overview of RSIP operation
The draft talks about the context, scoping and philosophy of RSIP and discusses different methods, pros and cons.
There is added talk of demultiplexing beyond port numbers, subnet query pros and cons for determining locality of location.
Next steps
- Move TCP TIME_WAIT, ICMP and DNS from protocol draft into framework
- Add section on external access to internal servers
- Mike's suggestions for future: make choices and nail down stuff in framework
- More security considerations
- Distinguish between client-server application (much easier) and supporting external access to internal servers (more complicated)
George Tsirtsis - look at what ngtrans is doing for v6 to v4 mechanisms
The RSIP Protocol
Local Authentication needs more work/feedback
An example has been added in the anex
Need to extend error messages
Issues
- Transport for RSIP: now has its own port number but could go over SHOCKs/DHCP/IPCP
- Brian Carpenter: to clarify this is about transport of RSIP signalling and not data after address allocation. Many people have not used TCP only to realise later that TCP is a good idea after all because of reliability. etc. Mike also agrees.
- BIND messages for local servers. Needed but not sure how it is going to be implement in different scenarios
- Client state diagram Someone asked could you dislocate RSIP server from gateway router? This way multihoming will become easier. Mike: Yes but it is too complex.
The end of the protocol draft lists the changes:
We discussed an appendix with protocol example with negotiation example, and addr and port resource error messages.
We are starting to gain implementation experience, and gain in understanding of what's needed. This means there will be changes to this part of the spec
We can implement a NAT function as a complement coexisting with rsip server
We must decide on transport for the RSIP signalling: socks/dhcp/ipcp/port? reliable/unreliable (TCP/UDP)?
Brian Carpenter - TCP is a good choice
Mike: yes, TCP and authentication
BIND msgs for local servers? not needed for road warrior perhaps for home networks
Client state diagram
mike's adding this to the draft
Someone: why not separating the router from the rsip server box?
Gabriel responded later that this separation would benefit from allowing the rsip client to express not only that it needs a tuple (address, port, spi, etc), but also to express what the intended peer of this session will be (a la nar/socks)
IPSEC draft
This is a combination of 3com work and Gabriel Montenegro's/sun (NAR draft)
This extends RSIP to support IPSEC. No change required in IPSEC.
Client and server agree on initiator cookie and spi
Future issues
- e2e security model and assumptions
- Policy integration
- Host with some policy
- Plug into a network with policy
- Mild violation of cookie creation, mild violation of 2408 sec 2.5.3
To avoid socket collisions, clients should/must also allocate port numbers in additions to the SPI.
IKE: use initiator cookie as demultiplexer
ESP: use incoming spi
We are soliciting input as we revise these drafts
Discussion on Mobile IP support
some drafts that talk about this are:
- http://search.ietf.org/internet-drafts/draft-ietf-mobileip-privaddr-00.txt
- http://search.ietf.org/internet-drafts/draft-teoyli-mobileip-mvpn-02.txt
General Discussion:
Mike: All drafts are being revised. If people have strong opinions now its time to contribute
- Someone said that RSIP is kernel level and may not work with Raw sockets.
- Matt: virtual sockets with an abstraction layer could be used to handle raw sockets.
- Someone asked: What interactions you have with Mobile IP?
- Mike: a document was written 1.5 years ago but needs to be revisited.
Gabriel: RAT may also have interactions; NAR (predecessor of RSIP) studies both mobility and security so, could be used as reference. An other document also exists dealing with private addresses and mobile IP.
- Brian Carpenter asked: Does RSIP requires other things to be changed (e.g: DNS) Is there a roadmap for the future of this work?
Matt: Roadmap will need input from others (IAB?).
Gabriel: Need to separate RSIP of the future from RSIP of now that we need for Home Networks etc. Definitely need to work more on Security and already work with Security people. Incoming connections and multiple RSIP gateways are also future work items.
Matt: RSIP for now may need to be made more robust to deal with RSIPxN situations.
Gabriel: Agree but RSIP may already be too big (according to NITS BOF people) so we need to allow people to implement only parts of it for what they are doing.
- Matt: RSIP is not specifically in the WG charter but has been worked on here and it may be better to keep it in NAT WG for now until IAB or IESG can give us more directions.
Steve Bellovin: No more direction is likely to come out of IAB, further to what was given in the network layer BOF. You should understand what needs to be done for the general case and do it. Do not wait for someone to give you the go ahead.
Conclusion: RSIP will remain in the NAT WG for now
5. NAT Transport - Carmelo Zaccone - draft-zaccone-nat-transport-00.txt Access to Multiple ISPs is a problem and the tunneling approach has drawbacks This work attempts to identify ways to do this without tunneling Possible approaches:
- Turn PC into Router running OSPF (minimum implementation)
- Use multicast to advertise unicast addresses via trees rooted in the host
- Reverse path creation with RSVP
Discussion: clarification questions on the different mechanisms, scalability etc.
Mike: Problem space is valid but solutions seams too complex. Are there any alternatives?
Discussion to continue on the mailing list
6. AOB
None. Meeting dismissed.