Re: Comments on draft-ietf-mobike-protocol-00.txt (issue 25)

Fine with the changes you proposed.

-mohan

----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>; <[email protected]>
Sent: Tuesday, July 12, 2005 2:08 AM
Subject: RE: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt (issue 25)


Hi Mohan,

I've filed your comments as issues 25 (editorial), 26 (window
size/latest_update counter), 27 (security and path testing) and
24 (details of NAT prevention)

I'll start with the editorial ones:

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

Best regards,
Pasi