Preliminary minutes from the WG last week

Please let me know if you have any changes.

MOBIKE WG minutes
IETF 65

Minutes supplied by Al Arsenault, BBN
(Edits and formatting by Paul Hoffman, with additional notes from Cheryl
Madson, Maureen Stillman, Jari Arkko, and Tero Kivinen)

Paul Hoffman, VPNC & IMC, Chair
Jari Arkko, exiting co-chair (now AD)

Agenda:
	Status of MOBIKE protocol and design documents
	Presentation on draft-nikunder-esp-beet-mode
	Discussion of what to do with the WG

Status of MOBIKE protocol and design documents
	Protocol document accepted as a Proposed Standard on 3/3/06
	Draft-ietf-mobike-design-08.txt being reviewed by Russ Housley, AD as of 3/15/06
	- if everything is clean, it will go to IETF Last Call
	- else Russ will get back to document authors and there may be another draft

Presentation on draft-nikander-esp-beet-mode
	Bound end-to-end (BEET) mode - Pekka Nikander (and Jan Melen)
	Presentation outline
	- Introduction
	- motivation
	- BEET in a nutshell
	- Packet formats
	- IP header processing

	Introduction: augments the ESP tunnel and transport modes; aimed for
	end-toend tunnels; limited tunnel mode semantics without the overhead.

	Motivations: support new uses of ESP - Tunnel mode with fixed inner
	addresses are leaner and more secure; transport mode with external
	address changes (NATS, mobility, multi-homing, etc.) Identifier/locator
	split in ESP

	Two independent implementations, one on Linux & one on FreeBSD
	Both running as part of HIP packages

	Summary
	- new mode for ESP
	- up to 51% HEADER SAVINGS
	- EASIER DEALING WITH natS, MOBILITY, MULTI-HOMING
	- FACITLIATES IDENTIFIER/LOCATOR SEPARATION
	- MINIMAL ADDED COMPLIXTIN Y - ABOUT 100 LINES OF CODE

	Questions:
	1 - Richard Graveman, RFG Security - have you looked at draft on
	IPsec tunnel mode in ROHC group? Is this solving the same or a
	different problem?  Answer: this is a subset of their problem.

	2 - Francis Dupont - Same comments - believe ROHC (IPsec) is more
	generic is more generic.  This is a good thing, but it's better for
	HIP than for this group.

	3 - Michael Richardson - Can you confirm that you don't transport
	the fragment ID for the ECN or DS field? If have a /32 - /32 tunnel
	and have variability in those fields, you can't transmit them
	anymore?  Answer: it depends on what you do. If you replace the AF,
	the other fields are discarded. If you're using the same AF, don't
	remember exactly what happens. In all packets you still have a UDP
	header, so you could copy ID & fragmentation fields from IP header &
	back at the receiving end; it would work but it could reveal
	something. Michael: works well for TCP, but may fall down at some
	point.

	4 - Jari Arkko - want to argue in favor of having full semantics for
	tunnel mode and having ability to do more than just end-to-end mode.
	 The scenarios where MOBIKE is needed are not limited to end-to-end;
	e.g., VPN access by remote users.  Also, remains unconvinced of how
	well this works with Mobile IP.  (Pekka disagrees.) PSE stuff should
	go away.

	5 - Chris Christou, BAH - co-author of HCO IPsec draft - HCO IPsec
	also compresses upper layer header, so it does a little more than
	this. Haven't read this draft, but should talk off-line about where
	the two ideas intersect.  Answer: yes, should talk off-line, but
	thinks that this solves a slightly different problem.

	6 - Francis Dupont again - with compression, you can compress almost
	the whole TCP header, which is better than just compressing the
	IPsec header.

Discussion of what to do with the WG
Adopt BEET, move forward; wind up; or something else?

Carsten Bormann (Chair of ROHC) - HCO-IPsec looks like it's going to
split into about 4 drafts.  One of them will have to address IKE (Paul
noted MOBIKE is limited to IKEv2; ROHC will address both). Bottom line
is that if MOBIKE winds up, BEET might move over to ROHC or another WG

James Kempf - discussion in Mobile IP group - what happens if you try to
use Mobile IP and MOBIKE together? Some people believe the answer is
"don't do that". May need an informational draft (as a new work item) to
address that.

Pekka Nikander - one possible utility for BEET might be to provide
MOBIKE support for transport.  (That's not at all what we're doing - the
charter says tunnel mode only.)  BEET could allow MOBIKE to support
transport mode, but there are re-chartering issue because of the dragons
out there.

Michael Richardson  - Have PFKey extensions been done?  They're in the
charter.  Paul - they've died because of lack of interest; if we wind up
we declare partial victory vice full victory.

Unknown speaker, Boeing - Boeing has implemented BEET as part of the
OpenHIP work; would like to ensure that a working group is found to move
BEET forward.

Paul - IETF likes to close working group in a timely manner once their
work is done. If group wants to do something besides BEET, it MUST be
relevant to MOBIKE/the charter.

Pekka (he's a cochair of BTNS group) - recently people raised voices
that BTNS is really only useful for NAT traversal and similar, but it's
only handling transport mode, not tunnel mode. If you want to push BTNS
and MOBIKE together (re-charter with transport mode), you could handle
both cases.
 
Paul - 10 minutes left; need to decide:

1 - ask for a re-charter of the WG to cover transport mode? (Bearing in
mind the ADs could say "no".) Taking a hum of the room: (then hands) -
"recharter" has a slight edge, but no consensus.  Paul: continue the WG
past today, with the task of coming up with the wording of a re-charter.

2 - Pasi Eronen - wants a draft that would represent a work item prior
to re-chartering. That verifies that there's interest in actually doing
the work. Paul: hesitant to ask for that, because it asks someone to do
a lot of work to put a draft together, then pull the rug out from under
them when we don't recharter.

3 - Pekka - thought that the conclusion of the BEET discussion was that
because of other work going on, there's no interest in BEET for tunnel
mode.  If we do transport mode, BEET is a proposal, but it's not a work
item for just tunnel.

4 - Michael Richardson - thinks WG should finish charter and wrap-up.
Pekka should move forward with the BEET draft, and a new home should be
found for it. (And it's almost done already.) Right thing to do might be
to re-spin IPCOMP, move some of the ROHC work there, and put BEET there
too. (Reminder: IPCOMP was about data compression; HCO IPsec is about
header compression.  Those are different.)

Paul - the take-away is that we may continue, but we need to reach
consensus on what change to the charter is needed. There's definitely
interest in IPsec header compression.

Tero - finish now; BEET should be published as-is as an individual
solution.  Transport has no use cases right now; that has to be done as
part of re-chartering.