Subject: (NAT) Adelaide minutes

From: Matt Holdrege <[email-masked]>
Date: Wed, 26 Apr 2000 09:21:43 -0700

Here are the minutes, please let us know if you see any errors or omissions.

Chairs: Pyda Srisuresh - [email-masked]
Matt Holdrege - [email-masked]
Reported by: Yves Tjoens - [email-masked]
Gabriel Montenegro - [email-masked]
Prepared by: Suresh & Matt
___________________________________________________________________________

Mailing list: [email-masked]
To subscribe: Send e-mail to [email-masked] with "subscribe" in 
the body of the message. Only messages from subscribers are posted to the 
list.
To unsubscribe: Send e-mail to [email-masked] with "unsubscribe"
in the body of the message.

Mailing list: [email-masked]
(This is nat mailing list, in daily-digest format. To receive the digest, 
you can subscribe as follows.)
To subscribe: Send e-mail to [email-masked] with
"subscribe" in the body of the message.
To unsubscribe: Send e-mail to [email-masked] with
"unsubscribe" in the body of the message.
____________________________________________________________________
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: Wasnt it decided in the last meeting that RSIP should simply
be a replacement stack for IP? Apps shouldnt 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 application

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 cae, 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: [email-masked]

----------------

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

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.