[Mobike] summary of BEET discussion

[Jari Arkko]

SUMMARY OF COMMENTS
===================

The following types of issues have been brought up regarding BEET:

(1) Is something like this needed?

     Argument: Tunnel mode performance issues are a real concern over
     some wireless links.

     No counter-arguments presented in MOBIKE BOF or the list.

(2) Is this the right WG?

     Argument: MOBIKE WG is about enhancement of the VPN user's
     experience when mobile/multihomed; BEET is in scope for that.

     Counter-argument: BEET, while potentially useful, is not related
     to the MOBIKE protocol. MOBIKE does not technically involve BEET,
     other than that it is negotiated through IKEv2. Therefore, it
     should be treated in another WG.

     Another counter-argument: BEET applies to transport mode, MOBIKE
     focuses on tunnel mode.

     Yet another counter-argument: Compression and bandwidth issues are
     general, not related to mobility or multihoming.

(3) Right technical approach?

     Argument: BEET is a facilitator for the proposed identifier and
     locator split.

     Counter-argument: It is just a way to add header compression to
     IPsec. Would be better to look at Jan Vilhuber's drafts and
     support them in IPsec WG. No need for the architectural part.

(4) BEET related input on MOBIKE WG scoping:

     Some folks argued that it would be better if MOBIKE WG extended
     its scope to handled more than IKEv2 i.e. mobile VPN experience as
     a whole. (It has been observed that MOBIKE, as proposed, deals
     with IPsec security association movements.)

     This would also have an implication about the naming, and was a
     part of the complaint on why some folks disliked the name MOBIKE.

(5) Detailed technical issues. There were a few, but we do not need to
     deal with these now.

FULL LIST OF COMMENTS
=====================

Full list of comments in the meeting and on the mailing list:

  o  Spencer Dawkins: what do you mean by portability?
     Pekka: portability of key management protocol (e.g. IKE)
     implementations, this is easy to address

  o  David Black: ESP doesn't have modes; what you have here is new SA
     processing mode, and you need IKE to negotiate this node.
     Pekka: the reason why I'm calling this ESP extension, is because
     IPsec WG has said that I can't call this IPsec (because this is
     not 2401)

  o  Francis Dupont: Is BEET relevant for this BOF or not?
     Jari: We will ask that question later.
     Pekka: Really depends whether we want to address transport
     mode or not.

  o  Charlie Kaufman: How this relates to this BOF, since this BOF is
     focused on tunnel mode?
     Pekka: There seems to be need for something like this; if IPsec WG
     would continue, that would be more logical place.

  o  Francis: The BEET mode has *nothing* to do with IKEv2 mob/mh
     support and was already presented in the IPsec WG. Same argument
     could apply to HIP.

  o  Francis: Is beet revelant or no (IMHO it is not, beet is just
     looking for a WG and as it was rejected by IPsec...)

  o  Lauri Tarkkala: The focus of the WG seems to be to enhance the user
     experience in cases where multi-homing is used. I believe BEET is
     relevant here. From my personal experimentation with GPRS links
     (which were in the basic use scenario in the BOF), the sweet spot
     for the MTU when running TCP over GPRS seems to be somewhere in
     the range 250-350 bytes.

     There are at least two reasons why a "small" MTU could be useful.

     - High BER => Larger packets get dropped with significant
       probability.

     - "Slow link" => Allows interactive sessions to grab a piece of
       the action from more throughput intensive ones.

     If the BOF felt (and the BOF still feels) that scenarios where
     small MTU's occur are within the scope, then a savings of >30
     bytes per packet allows one to send >10% more data without
     fragmentation. Not to mention that in cases where packets are
     small, the overhead drops significantly as shown in Pekka
     Nikanders presentation.

     If the IETF has standardized robust header compression for use in
     such environments, I do not see why a scheme like BEET should
     suddenly be considered evil. And if the mobike BOF/WG will tackle
     the use of IPSec in similar environemnts, I feel that BEET falls
     firmly within scope.

  o  Francis Dupont responds: BEET is only a way to add header
     compression in IPsec.  Please read Vilhuber's drafts, for instance
     draft-vilhuber-hcoesp-00.txt.

     I disagree: IMHO the header compression is not
     mobility/multi-homing specific and should be studied by the IPsec
     WG itself, not the mobike one.  And if you'd like to put some
     pressure on the IPsec WG, please count me in people who help you.

  o  Sami Vaarala: I don't personally consider BEET evil; on the
     contrary, it's an interesting tweak to optimize overhead.  We've
     been working on something similar for Mobile IPv4 using a similar
     approach because it retains most of the logical layering but cuts
     down overhead.

     However, I'm a bit confused about what the proposed mobike
     scope should be.  If the focus is not on IKEv2-based IPsec
     mobility (tight scope), what is it?  There are other things
     not related to IKEv2 (other than negotiating for features)
     or mobility we could develop to help operation in GPRS-like
     environments.  I'd find that interesting, but this does not
     seem to match the BOF discussion (nor the BOF name).

     About BEET and mobility, I don't believe BEET facilitates mobility
     any more than ordinary ESP tunneling does; BEET is an almost
     1-to-1 replacement for ordinary tunnel mode in some specific
     scenarios.  Because it is like ordinary tunnel mode in other
     respects, you can update the endpoints of both BEET and ordinary
     tunnel mode SAs in the same way (probably using the same signaling
     as well) while maintaining the same inner addresses for
     applications.  (Assuming you'd be willing to deviate from RFC
     2401, of course.)

     If we're willing to broaden scope from IKEv2, I suggest we discuss
     IPsec mobility in general. There are multiple IKEv1-based
     implementations out there with some form of (proprietary) mobility
     support.

  o  Francis Dupont responds: IMHO we don't need the architectural
     part of BEET, i.e., Vilhuber's drafts are enough, they just need
     *support*.

  o  Pekka Nikander: The natural place to discuss BEET would be
     the IPsec WG.  Unfortunately, the IPsec WG is being
     closed down and they do not take any new working items.
     Hence, working on BEET at IPsec is not a possibility
     due to this process issue.

  o  Pekka Nikander: BEET is not *only* about header compression.
     One can take two different views to BEET, as I tried
     to explain in my presentation.  One view is the header
     compression view, where BEET is just a limited tunnel
     mode with the inner header compressed to zero bytes.
     The second view, however, is that BEET is a facilitator
     for the proposed identifier/locator split.  That is,
     it is revised *transport* mode where the inner addresses
     are identifiers and outer addresses are locators.

     In my personal opinion, BEET is very relevant to mobility.
     Hence, in my humble opinion, mobike is probably the
     best place to work on it.

  o  Steven Bellovin: Russ and I are still a bit uneasy about BEET -- we
     need to understand the objections a bit more.

  o  Jari Arkko: We can see the unease in the group too. Or should I say the
     group seems a bit divided. So we too are going to take a look
     at both the arguments and counter-arguments again.

     And we are going to try and come up with a specific use case and
     tight definition of what it would do, and what specifically would
     its relation be to other parts of MOBIKE... part of the problem in
     the BOF for BEET was that these issues were unclear.

     Assuming we can figure this out, then we can take a fresh look at
     the arguments and counter-arguments again, as well as talk about
     it on the ML.