First draft of minutes from last week

Greetings again. Sorry for getting these to the list late; I have been
travelling since Paris.

--Paul Hoffman


MOBIKE WG meeting
Wednesday August 3, 2005, Paris
Notes taken by Lakshminath Dondeti and Maureen Stillman,
   combined by Paul Hoffman

Introductory talk

	Jari A: In May we resolved design issues. Pasi wrote a protocol
	draft according to decisions made; it was reviewed and revised
	version has been submitted.

	Related documents are here FYI:

	* devarapalli-mip4-mobike-connectivity -- MIPv4 approved WG (not
	MOBIKE) item. Discussed in 3GPP, especially in relation to 3GPP-WLAN
	interconnection May need liaison planning. Good to review in MOBIKE
	also.

	Paul H: we should coordinate with MIPv4 list. Pasi E: There is a
	discussion underway in that group.

	* dupont-mobike-transport Paul H: Please review, and we'll discuss
	within a reasonable time

	Paul H: It's fine to talk about non-WG documents as long as they
	don't block WG doc progress. There are several other drafts like the
	above two.  Please see the agenda slides.

Pasi E on MOBIKE-Protocol-01:

	(see the slides)

MOBIKE easy issues (Pasi Eronen):

	21, 25, 29 are Editorial
	
	26 Window size and latest update counter
	
	Word "path" now used only in senses that include the route
	
	23 : Separate payload types
	
	30 : Protocol ID in notifications (to be in sync with the
	ikev2-clarifications document)
	
	24 NAT prevention needs clarification and a better name
	
		Jari A.: Let's make some progress here by coming with some
		decisions and we can get those confirmed on the list.
	
		Francis D: dependency on 22
	  
	35, Version number (Skip the complexity now!)
	
	37: Move MOBIKE supported notification from IKEv2_SA_INIT to AUTH
	exchange
	
		Allows per user policy about whether MOBIKE is allowed
	
		Hannes: less fragmentation risk if added to AUTH
	
		Jari A: Clarification req: 
	
		Tero:  Can't fragment the first packet, because can't do
		stateless IKEv2 exchange.  Let's keep IKEv2_SA_INIT packet very
		small and allow the stateless feature to be continued to be
		supported. NAT-T may make the notification even larger.
	
		Seems like there is consensus on this.
	
	36: Unacceptable addresses.
	
		Receiver might not know which address set was acceptable
	
		Jari A: I had different thoughts on the list, but it is
		clarified now and I am ok with this.
	
		Pasi: This is a corner case anyway
	
	27: Security and path testing
	
		Sec considerations section needs text on path testing
	
		Dependent on issue 34
	
	Consensus calls: 35, 37 (Lakshminath: add comments from Tero as
	text) and 36 mostly yes and no hands on oppose. All will be repeated
	on the list.
	
	22: close the issue, misunderstanding (Hannes)

MOBIKE issue 34 (Pasi Eronen):

	(see the slides!) Discussion in the room:
	
	Current protocol just does what IKEv2 NAT traversal does
	
	This is another place where we upgrade a MAY to a MUST in IKE v2
	
	Terminals that are totally idle sending keep alives consumes energy
	
	Should we ask the BEHAVE WG anything? (Paul H says no, emphatically)

	Only 2 people in the room have done an implementation with this

	Suggestion: never time out; wait until you are under attack
	
	When added to IKEv2, it was a corner case
	if you care about it you implement the SHOULD
	if you don't care then you don't implement the SHOULD
	
	Path test is valuable independent of this issue. It is clear we need
	this path testing feature regardless of this issue.
	
	Relationship to Path test
	
		with approach 1
			there are more of these time periods ->
			more need of separate exchange
			if you want to do NAT detection in path testing ->
			need separate exchange
		
		with approach 3
			fewer of these time periods
	
	summary:
		approach 1 and 3 both work
		both have pros and cons
	
	Tero agreed to write the summary to the list and send them 
	
	Want to see more discussion on the list;
	security considerations for the path test exchange
	
	Sense of how we support this corner case; do we want to drop it?
	We know it will happen if the NAT rebooted or change mapping for
	some reason
	
	Ask on the list about implentations IKEv1 or IKEv2
	
Next steps (Jari A)

	get rough consensus on technical issues
	fix security considerations
	clarify role of multihoming

	3GPP2 has sent a liaison statement; we need to respond to it

Design document (Hannes)

	mobike design 03
	
	document update for this IETF
	changed lots of text and organization
	
	Difficult to follow the whole story; moved text to make it easier
	to understand
	
	missing pieces
	
	selecting address (issue #20)

	more details in the security consideration section
	
	add design rationale for some issues that arise
	
	readability - better structure for the doc -- new outline
	
	Paul H: this tracks the IKEv2 clarifications document and can get
	to the IESG after the protocol document (not by long)
	People seem to like that
	
Way forward (Jari A and Paul H)

	Close all open issues on the protocol document
	We want to finish for real by September 15
	
	Then have WG last call
	
	At the same time as WG last call for the protocol finish the design
	document
	
	Read the docs now; don't wait.