NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00
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
· 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 | |
Chairs: Pyda Srisuresh - srisuresh@yahoo.com
Matt Holdrege - holdrege@lucent.com
Reported by: Yves Tjoens - yves.tjoens@alcatel.be
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>
_________________________________________________________________________
AGENDA:
1. Base-Nat drafts
- draft-iab-nat-implications-05.txt from Tony 10 mins.
- draft-ietf-nat-protocol-complications-02.txt 5 mins. from Matt
2. RSIP drafts - 30 mins.
- draft-ietf-nat-rsip-slp-00.txt
- draft-ietf-nat-rsip-ipsec-03.txt
- draft-ietf-nat-rsip-protocol-06.txt
- draft-ietf-nat-rsip-framework-04.txt
3. Miscellaneous - 15 mins.
--------------------
Matt - <draft-ietf-nat-protocol-complications-02.txt>
Matt proposed sending the draft to IETF for a 4-wk last call to flesh out more comments.
Fred Baker: why an ietf last call for an info i-d?
Matt: Because it impinges on so many things. Matt sent an e-mail to all the wg chairs yet we still need more feedback.
Fred Baker: It does not hurt, but is unexpected.
Matt: This was the best way the chairs and ADs think to get the required comments.
Suresh: Base nat drafts are the reason this wg was formed, we need to move past them. This is a base NAT draft and we need to do whatever it takes to get the necessary input.
---------------------
Mike Borella - RSIP drafts
<draft-ietf-nat-rsip-protocol-06.txt>
- terminology changes:
- rsip client: client portion of rsip protocol
- rsip server: server portion of rsip protocol
- rsip client and server from before are now called rsip host and rsip gateway.
- minor changes in protocol. Don't care parms are now empty instead of filling with 0's.
- revision of query_request and query_response using indicator to disambiguate whether talking about
subnets or host addresses
- beefed up error processing and general protocol behavior
- deprecated: ok and deallocate msgs (not needed or redundant)
- added overall length field (good for tcp)
- error msgs and codes separated and listed
- categorized: host vs. gateway
- mandatory vs. optional
- iana section + editorial work
- further work: minor stuff, deltas are getting smaller
- is protocol minimal or complete?
- examples? error msgs complete?
- clarify behavior? Should we send to last call?
Elliot Lear: Not ready for last call just yet question on determining inside or outside hosts.
Mike: Basically, this might be a situation when if you can't tell, just let the user use nat and hope for the best.
Suresh: Wasn't it decided in the last meeting that RSIP should simply be a replacement stack for IP? Apps shouldn't have to be redone with RSIP stack, right?
Elliot: You should not specify if an app should use nat or rsip, but you should provide the mechanisms for the administrator to enforce that. Are you doing app based routing? If so apps must know about this.
Mike: Hopefully apps should not know whether nat or rsip is being used.
Matt: Let's not have the "which is better" conversation here.
Elliot: Perhaps the query should help disambiguate this, but it might
require having ports in the query.
Matt: Perhaps you could write a draft on this topic?
Elliot: What I need is something to help determine using nat or rsip. For example to avoid tunneling.
Gabriel: you don't need to avoid rsip to avoid tunneling. we have tunneling there because we didn't want to delay,but it's simple to enable direct delivery. this is similar to MN-FA link in mobile IP (no tunneling).
Mike: We should avoid having to touch the applicatio.n
Scott Bradner: You suggesting that the initial handshake would have an application id? there's something like this in rsvp.
Suresh: Make the tunnel endpoint explicit, instead of assuming that they are the src/dst addresses, it may be possible to have the resources assigned by a different box than that which is involved in the data
transport, so tunnel endpoint is not necessarily the signal endpoint.
Mike: Now you need a protocol between the rsip controller and the gateway
Scott: Just specifying another first hop to use seems reasonable, but no more.
Suresh: In section 7 - Flow based logic and state terms are confusing. Why should you need this?
Mike: It's not mandated, you can have macro or micro or no policy.
Suresh: In that case, OK.
---------------
<draft-ietf-nat-rsip-framework-04.txt>
3 Sections now
- implementation issues
- deployment
- interaction with layer 3 protocols
New sections on
- intserv
- diffserv
- multicast
- dns
- locating rsip gateways
- brief discussion on authentication
- further work
Mobile IP section will synch up
Brian Carpenter: An rsip gw may be a diffserv router as defined by diffserv. pls check to make sure it's ok.
Suresh: Draft looks much improved. Has RSA-Ip or RSAP-IP been tested with applications that are known to have problems with NAT?
Mike: For relatively simple nat-unfriendly protocols, rsip just works without changing the app.
Suresh: Is this draft applicable for both rsa-ip and rsap-ip?
Mike: Don't see much market for rsa-ip. people want to share one ip addr among many hosts. in that situation, just use dhcp.
Suresh: That is not right. RSA-IP can be useful for renumbering. RSIP data path needs to be clarified. Specifically, you need to list the catalysts for intercation between RSIP-host and RSIP-client.
Mike: Perhaps for later with feedback from stack developer folks?
Suresh: More urgent than that. need convincing arguments that socket interactions would be supported by rsip stacks as well. For example, are applications required to request different sockets based on the destination address they are talking to? When does the RSIP stack request RSIP client to initiate a control session with RSIP-server?
-----------------
<draft-ietf-nat-rsip-ipsec-03.txt>
strong recommendation that ike float the source port
already allowed, for testing for example
this way, no need to do i-cookie agreement.
client is much easier. also solves problems with remote host rekeying
Suresh: Does not help when you are receiver of ike initiation and you rekey phase 1.
Answer(someone in Audience): You usually reuse the ports used in phase 1. So it would be ok.
Suresh: Even in that case, Use of Ephemeral IKE ports would only help
in the case of IKE initiation by RSIP hosts - cannot be IKE responder using
ephemeral ports.
Mike: rsip message authentication. No encryption, just authentication related draft in dhc, redirecting to get the ip addr of your rsip server rsip on linux: rsiponlinux-request@sandelman.ottawa.on.ca
----------------
draft-ietf-nat-rsip-slp-00.txt - jim kempf
allow client to find rsip server based on characteristics of server
draft contains service type template for rsip service type
added a service attribute for load-balancing
how to use scopes for provisioning
more flexibility in deployment
example on using slp scopes for provisioning
does the wg want this to advance to proposed/informational, other?
suggest advancing along with the rest of the rsip drafts
---------
draft-iab-nat-implications-05.txt - tony hain
pls look through it, this one is intended to be final.
---------
carmelo zaccone on generic architecture for rsip as time ran out
question to the wg: is our work of interest?
is it within the scope of the wg?
multiroaming with isp's, general enterprise,
current rsip has limitations
End Of Meeting
None received.