Subject: [mobile-ip] WG meeting minutes (IETF54)

From: [email-masked]
Date: Mon, 5 Aug 2002 14:59:58 -0500

Hello,

Attached are the WGs IETF54 meeting minutes. If you find any errors
or discrepancies, please do send a note with the correction.

-Chairs

Mobile IP WG minutes 
IETF54 @ Yokohama (July 15th)
=============================

Meeting minutes captured by Basavaraj Patil and Phil Roberts.

Agenda bashing:
---------------

Mr. Mastaka Ohta requested a presentation slot - rejected by the
chairs, ADs asked, and then insisted that the ongoing persistent
request be taken offline 

WG Doc Status
-------------
3012bis has actually completed WG last call.
Actually, it has been sent to the IESG and is on the review list
already.

3220bis is with the RFC editor and should be published as a new RFC
soon. 

Reg-Revocation in WG last call now.

AAA-Keys has completed WG last call and awaiting changes based on IESG
review comments.

MIPv6 discussions
------------------

Resolutions of all issues will be proposed to the ML, with included text for
the draft.  WG will be able to comment.

Issues Discussed:

	76 - unclear response on whether to include this, asked
	whether useful, whether not.  Dave Johnson requested whether
	it is dangerous to have it in the text and he and Charlie at
	least indicated some concern.  Some found it useful. 

	74 - source selection, plus guidance here, plus implementors
	common sense will get this right (Hesham).  Dave J history -
	acknowledging that it is useful and is there so folks will
	know it is possible.  (Mr. Keichi?) some communications must
	use COA so text will be needed to clarify this.  (?)  Problem
	needs to be solved, will be done elsewhere, not in this
	document.  (Francis) need something like API or state machines
	for some details and security descriptions. (Hesham) in some
	other API, let's not make it CoA vs HA, but something more
	abstract. 

	62 - (Hesham) separate issue posted to the ML.  Some twisted
	notion of ll home address and needing to keep what's at home.
	(TJ) thinks it ought to be obvious.  (Francis) should wait for
	DAD and DAAD before deciding on the best solution. (Phil)
	let's go with what we've got  (Hesham) either defending home
	address or defending link local  (Phil) yes, home

	72 - (Charlie) uses same binding update signalling as is in
	this draft, whereas the fast handover work has new signalling.
	(James) there is signalling for this in the fmip draft.
	(Charlie) Doesn't make sense to use the existing messages to
	do what it was designed to do?  (Rajeev) new signalling is
	slightly different.  (Charlie) even if you take it out, it
	could still be done.  This provides guidance.  (Alper) maybe
	it would be best left where it is to allow better performance
	now. (Erik) the security description is incomplete.  (Note to
	self - work with Jari about what is actually needed to make
	this complete.  If it's a lot, take seriously the request to
	drop it). 

	49 - (Hesham) need to clarify why this is a hard problem.
	(Francis) this is a general IPSEC/IKE problem.  Give it to
	IPSEC to solve.  (Erik) it is harder than what Hesham said: if
	I assign myself a temporary address (3041), preferred for a
	day, deferred for 6 days.  Don't want anyone to claim it in
	the mobility case even though I used it for just a little bit.
	Hard - need something different.  Not tied to binding
	lifetime, but the lifetime of the temporary address, conflict
	between multiple mobile nodes trying to claim the same
	temporary.  Conclusion is agreeable to all.

	55 - (FD) HA discovery is totally insecure and there is no way
	to make it sure. (Hesham) It doesn't need to be secure.  A
	fake HA will be discovered immediately. (Raj) What is the
	threat with not securing the HA process?  (FD) Not sure, but
	need to use IPSEC and IPSEC will fail.  All other proposed
	solutions can be done in a secure manner.  (Jim) Was arguing
	that maybe an alternative is possible, and reducing the size
	of the doc is a goal.  Maybe there is an argument for a
	special protocol.  (Hesham) this mechanism serves a good
	purpose and it should be left in. (Dave J)  Removing features
	solely for the purpose of making the doc shorter is a recipe
	to further reducing the implemented functions.  (Jari) node
	requirements can mandate stuff (Dave J) node requirements
	doesn't exist.  At worst you create extra work rather than
	denial-of-service.  (Thomas) not clear there is a concrete
	proposal here.  Need a concrete proposal if we're going to do
	something to replace this.  Proposal is to keep it, finish
	discussion on the ML. 

	70 - (DJ) what is the purpose in making it mandatory?  (Jari)
	when using ESP to protect BUs, ESP doesn't protect source
	address.  (DJ) use it only when using ESP?  (Jari) possible,
	but introduces unnecessary dependency.  (DJ)  Why not make it
	a required field?  We end up with distinguishing between a BU
	for home and for non-home BUs.  (Jari) we already have that.
	(FD) make it mandatory (Jari) need to know whether it is ESP.
	Just make a requirement for home registrations. Don't try to
	solve an implementation problem by changing the protocol.  Let
	implementors.  (Hesham) it's not a big problem, don't change
	it now. (Rajeev) in FMIPv6 and HMIPv6 you need it.  (Charlie)
	leave it up to implementors (Dave J) if you don't know whether
	you are using ESP you must use this. 

	(TJ) dynamic HA discovery question (56).  Alternative
	proposal, if addresses don't fit in MTU, do it j-1 addresses
	and make j the address of the HA that is responding.  Still
	get first optimization.  (Charlie) important to keep the first
	optimization. 

	(Hesham) prohibit site-local COA - no text is there.

	(FD) R-bit is needed to say whether mobile node is a router.

	(DJ) For RR the MN can't know whether the nonce is too old.
	An MN can send a BU requesting not to acknowledge.  Can't get
	told nonce is too old. -> Need to be able to handle Binding
	Acks and match them with sequence numbers even in the case we
	did not request a binding ack. 

	(DJ) For RR, the cookie may be protected by ESP on HA-MN link.
	If it isn't protected anyone on or near the FL will see both
	cookies.  Why not require ESP on MN-HA link? (Jari)  Previous
	discussion led us to believe it is a MAY.  One of the reasons
	is that the kind of attacks that can happen will hurt MN-HA
	but cannot hurt third parties.  (DJ) disagrees - affects
	conversation with CN also.  (Hesham) thinks it's a SHOULD (DJ)
	wants a MUST, reckless not to take advantage of required
	fnality (DJ) will post rest of issues to list.

	(Erik) let's not say anything about site-locals
 
	(Mr Keichi) why do all nodes have to support HoA?  (DJ) for CNs to
	receive a packet from a mobile node while it is away from
	home.  (Mr K) this does not prevent communication.  (DJ)  MN
	that sends a packet with HoA implies that all nodes must support it.

Fast Handoff in V6:
--------------------

(Phil's pres on an 802.11 fast handoff draft)

Phil set the context and provided the background for the work and
discussion. He also outlined a strategy for moving forward. Phils
recommendation is that Fast HO be defined for specific link layers and
we can start with defining Fast HO for 802.11
For details on the proposal refer to the slides.

- Hesham agrees. However a general protocol is all you really need. 
Jak: Disagrees. Example of IPv6 in RFC2461 and 2464

Ohta: FMIPv6 useless. Document is large. 3G/FoMA is not valid for
Internet access

Hesham: 802.11 work will raise the same issues all over again

Jim Bound: Agrees with the process proposed by Phil and supports it

Gopal: Doing the 802.11 spec will narrow the focus and help 
Gopal agrees that the 802.11 spec should simply specify the triggers

Rajeev: V05 already supports implementing FMIpv6 on 802.11

Hesham: Will the 802.11 draft simply specify the L2 triggers for fast
HO?

Jak: The current draft is focused on Preaddress configuration and this
is not possible in 802.11

(Rajeev's pres)

(Jim) on network controlled handover.  How does PAR know to send PrRtAdv without
an L2 trigger?  Only use when there is potentially no L2trigger, when MN sends
a solicitation.  Assertion: there is no way to do something like this without
some kind of l2 info.
(Hesham) tunnel was previously terminated on the mobile node - now what happens
with ingress filtering.
(Rajeev) question about what's available on L2?  (Jim) we are setting requirements
(Rajeev) are we putting musts for L2s (Jim) there may be a tight coupling that
needs to be specified.
- had to cut off the pres, Rajeev will post issues to the ML and solicit discussion
from the WG on answers to his question.

VPN Traversal requirements
--------------------------
(Farid Adrangi presented the requirements)

(Raj) on RO, is it an objective to solve v4 R.O.  (Farid) may
(Raj) what does RO have to do with this problem?  If a new entity is
introduced is rt. opt. needed.

Limited Private Address Support
-------------------------------
(Gabriel's pres)
new draft updates guidance for implementation of reverse tunneling
(Phil) what do you want to do with it? 
(Gab) separate wg document as
BCP or Informational 
(Pete) concerned that implementation community is split because there
are CDMA vendors  who are doing separate implementations from what is
done at Cthon.  Existing RFC is a fine spec, pp2 understands what it
means.  Needs to review. 

LMM Requirements
-----------------
(Carl pres)
Some small modifications.  Ready for WG last call.