Comments on draft-ietf-mobike-protocol-00.txt

Considering all the discussions we had, this draft is simple to read. 

The details on exactly on how the protocol works (section 2.3)
needs to be expanded more in the future revision. Also, the NAT traversal
details need a little more detail :-) Here are some of my comments..

Technical
----------
-Section 2.3:

   - Does not explain, what happens when the "window size does not allow ?
     It retransmits the existing message with the new address and responder
     sends back to the new address but without updating the SAs ? This is sort
     of implicit in the text because the SAs are updated with the new address pair in the
     first step and any retransmissions will happen with the new address.

   - What is "latest_update_received" counter ? Where else is it used other than this step?
      Either the counter is updated or not. It is not clear what this counter is used for as
      it just appears in this step alone.

-Path testing: 
    - The security impact of this is not discussed in the Security consideration
      section ?
    - It states that the reason for new message type is to support window size 1.
      But it does not state why it can't be secure ? You can still have a separate
      window space for this message and still provide security, right ? This
      was discussed in the mailing list. Do you see problems with it ?

- Section 2.7 - NAT Prevention stuff..
       This specification addresses the issue as follows.  When an IPsec SA
        is created, the tunnel header IP addresses (and port if doing UDP
        encapsulation) are taken from the IKE_SA, not the message IP header.
        The NAT_PREVENTION payload is used to guarantee that NATs have not
        modified the address used in IKE_SA.  However, all response messages
        are still sent to the address and port the corresponding request came
        from.  

  If we are reached the stage of creating the IPsec SA and we have used NAT_
  PREVENTION, the IP header and value carried in the NAT_PREVENTION
  payload is same. So, just taking from the IP header should be fine. Is this
  talking about not updating from the IP header of the IPsec packets (as
  required by standard NAT-T) in general ?   

Editorial
--------

- section 1.1,

        In some cases, the the problem can be solved by simply creating new
        IKE and IPsec SAs after the IP address has changed.  In static
        multihoming scenarios, it may even be possible to have several IKE
        and IPsec SAs simultaneously, and perform some kind of dynamic
        routing over them [RFC3884].  However, this can be problematic for
        several reasons.  Creating a new IKE_SA may require user interaction
        for authentication (entering a code from a token card, for instance).
        Creating new SAs often also involves expensive calculations and
        possibly a large number of roundtrips.  Due to these reasons, a
        mechanism for updating the IP addresses of existing IKE and IPsec SAs
        is needed.  The MOBIKE protocol described in this document provides
        such a mechanism.

    This paragraph is trying to provide the real motivation but things don't
    seem well connected. The multihoming and creating a new IKE SA with user
    interaction does not seem to go well. The following is one possible rewording.

       Though the problem can be solved by creating new IKE and IPsec SAs after
        the IP address has changed, this may not be optimal for serveral reasons.
        In some cases, creating a new IKE SA may require user interaction
        for authentication (entering a code from a token card, for instance).
        Creating new SAs often also involves expensive calculations and
        possibly a large number of roundtrips.  Due to these reasons, a
        mechanism for updating the IP addresses of existing IKE and IPsec SAs
        is needed.  The MOBIKE protocol described in this document provides
        such a mechanism.

     And move the static multihoming to the previous paragraph where different
     scenarios are described

- section 1.1, 

        The main scenario for MOBIKE is making it possible for a remote
        access VPN user to move from one address to another without re-
        establishing all security associations with the VPN gateway. 
        ....

        More complex scenarios arise when the VPN gateway also has several
        network interfaces

    Though the more complex scenario is supported, the wording does not indicate
    that.

-In section 1.2,

       Making the decision at the initiator is consistent with how normal
        IKEv2 works: the initiator decides which addresses it uses when
        contacting the responder.  It also makes sense especially when the
        initiator is the mobile node: it is in better position to decide
        which of its network interfaces should be used for both upstream and
        downstream traffic.

    Can we not talk about NAT also here ?

-In section 1.2,

          Here MOBIKE assumes that the initiator is the party "behind" the
          NAT, and does not fully support the case where the responder's
          addresses change when NATs are present.

     What do you mean by "fully" ?

-mohan



    Here it says "values from IP header" ? This is for the IKE SA i guess.