Re: WGLC on the design draft

 In your previous mail you wrote:

   We are now starting the Working Group Last Call on
   the design document.
   
=> here are my comments:

Abstract

   ...

   This document discusses the involved network entities, and the
   relationship between IKEv2 signaling and information provided by
   other protocols.  Design decisions for the MOBIKE protocol,
   background information and discussions within the working group are
   recorded.

=> there is nothing about the fact the design and the protocol are about
a first version of the MOBIKE tools. I support anyone who'd like to
make it an issue as the current solution addresses only one part of
the charter scenarios.

1.  Introduction

   ...
   single pair in the outer IP headers.  Existing documents make no
   provision to change this pair after an IKE SA is created.

=> this is not true: RFC 3775 and 3776 K bit stuff does exactly this.

3.2.  Multihoming Scenario

   ...
   Note that MOBIKE does not aim to support load balancing between
   multiple IP addresses.  That is, each peer uses only one of the
   available IP addresses at a given point in time.

=> this is not the common definition of load balancing (where the
restriction to only one address is per communication).

3.3.  Multihomed Laptop Scenario

   ...
   GPRS adaptor, a Bluetooth interface or USB hardware.  Not all
   interfaces are used for communication all the time for a number of
   reasons (e.g., cost, network availability, user convenience).  The

=> "not all" is not "only one".

5.3.  Scope of SA Changes

   ...
   If IPsec SAs should be updated separately then a more efficient
   format than the Notify payload is needed to preserve bandwidth.  A
   Notify payload can only store one SPI per payload.  A separate
   payload could have a list of IPsec SA SPIs and the new preferred
   address.  If there is a large number of IPsec SAs, those payloads can
   be quite large unless ranges of SPI values are supported.  If we

=> ranges of SPI values don't make sense: please use a reasonnable
argument or no argument at all!

   automatically move all IPsec SAs when the IKE SA moves, then we only
   need to keep track of which IKE SA was used to create the IPsec SA,
   and fetch the IP addresses from the IKE SA, i.e. there is no need to
   store IP addresses per IPsec SA.  Note that IKEv2 [I-D.ietf-ipsec-

=> I don't believe there is an implementation which doesn't store IP
addresses per IPsec SA.

   If we do allow address set of each IPsec SA to be updated separately,
   then we can support scenarios where the machine has fast and/or cheap
   connections and slow and/or expensive connections, and wants to allow
   moving some of the SAs to the slower and/or more expensive
   connection, and prevent the move, for example, of the news video
   stream from the WLAN to the GPRS link.

=> exactly

   On the other hand, even if we tie the IKE SA update to the IPsec SA
   update, then we can create separate IKE SAs for this scenario, e.g.,
   we create one IKE SA which has both links as endpoints, and it is
   used for important traffic, and then we create another IKE SA which
   has only the fast and/or cheap connection, which is then used for
   that kind of bulk traffic.

=> we can drop the whole MOBIKE stuff using the same argument.

   The working group decided to move all IPsec SAs implicitly when the
   IKE SA address pair changes.  If more granular handling of the IPsec
   SA is required, then multiple IKE SAs can be created one for each set
   of IPsec SAs needed.

=> please keep this and not try to give poor arguments to defend
the decision (it is the WG decision ".")

5.4.  Zero Address Set Functionality

(I've stopped here, I'll put comments about next stuff in another message).

Regards

[email protected]