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. Tom Henderson, 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.