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: 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: 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