--------------------

Mohan Parthasarathy (2005-07-11):

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..

(issue list maintainer's note: technical issues filed separately.)

- 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" ?

--------------------

Pasi Eronen (2005-07-12):

> - 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

Hmm... I rewrote that to 

   Although the problem can be solved by creating new IKE and
   IPsec SAs when the addresses need to be changed, this may not
   be optimal for several reasons. In some cases, creating a new
   IKE_SA may require user interaction [...]

The "when the addresses need to be changed" tries to capture any
reasons why the address needs to be changed, mobility or
otherwise.

> -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 ?

The section does talk about NATs a couple of paragraphs down;
I'm not sure if mentioning them already in this point would
be necessary..

> -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" ?

There's no special effort done to support it, and in most
cases it does not work (and even can't be made to work), 
but there are some cases where it works anyway (or making
it not work would take some extra effort), mainly involving 
"full cone" NATs.

--------------------

Mohan Parthasarathy (2005-07-13):

Fine with the changes you proposed.

--------------------

Pasi Eronen (2005-07-18):

Clarified text based on discussion on mailing list.

--------------------

Issue closed on 2005-07-25.

--------------------