RE: Review of draft-ietf-mobike-protocol-00 (issue 21)

Thanks for your review, Lakshminath!

I've filed the editorial comments as issue 21 and the more 
technical comments as issues 22..24 in the issue list:
http://www.vpnc.org/ietf-mobike/issues.html

I'll reply to the technical comments in separate emails
to make the issue tracking easier. Replies to some of the 
editorial comments:

> Abstract
> 
>   This document describes the MOBIKE protocol, a mobility and
>   multihoming extension to IKEv2.  The purpose of MOBIKE is to
>   update the (outer) IP addresses associated with IKE and
>   IPsec Security Associations (SAs).  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.
> 

> <LD> Perhaps the abstract could be revised to include what's
> being done for multihoming as well.  The last sentence could
> be: MOBIKE allows IPsec end points to change addresses (for
> multihoming or due to mobility) without re-establishing all
> SAs with peers.  (that sentence didn't come out all that well,
> but a revision thereof might be better) 
> </LD>

Yes, the abstract was written in a bit of an hurry..:-) How
about rewriting it to

   This document describes the MOBIKE protocol, a mobility and
   multihoming extension to IKEv2.  MOBIKE allows mobile and/or
   multihomed hosts to update the (outer) IP addresses
   associated with IKE and IPsec Security Associations
   (SAs). The main scenario for MOBIKE is making it possible for
   a remote access VPN user to move from one address to another
   while keeping the VPN connection with the gateway active.

>   large amounts of traffic.  Second, a "NAT prevention" 
>   feature ensures
> 
> <LD>  I may have overlooked the discussion on terminology, 
> but prevention doesn't seem to convey the intended meaning.
> </LD>

Hmm... I agree that NAT prevention is perhaps not the best
possible word. Any better suggestions? Would "address integrity
protection" be any better..? Comments from anyone else?

>   Path
> 
>      A particular combination of source IP address and
>      destination IP address (note: this definition does not
>      consider the route taken by the packets in the network).
> 
> <LD> Terminology again: why not use the phrase "address pair" 
> instead of path. I realize that it results in a large number 
> of changes in the document, but this is still a -00-
> </LD>

Mainly because "path" is shorter and leads IMHO to more
understandable text. RFC 2960 (SCTP) also uses the word "path"
with pretty much the same meaning in many places.

> 2.3  Changing path of IPsec SAs
> 
>   In MOBIKE, the initiator of the IKE_SA decides what
>   addresses are used in the IPsec SAs.  That is, the responder
>   never updates any IPsec SAs without receiving an explicit
>   CHANGE_PATH request from the initiator.  (As described
>   below, the responder can, however, update the IKE_SA in some
>   circumstances.)
> 
>   The description in this section assumes that the initiator
>   has already decided what the new addresses should be.  How
>   this decision is made is beyond the scope of this
>   specification.  When this decision has been made, the
>   initiator
> 
>   o  Updates the IKE_SA and IPsec SAs with the new addresses,
>      and sets the "pending_update" flag in the IKE_SA.
> 
>   o  If NAT Traversal is not enabled, and the responder supports
>      NAT Traversal (as indicated by NAT detection payloads in 
>      the IKE_SA_INIT exchange), and the initiator either suspects 
>      or knows that a NAT is likely to be present, enables NAT 
>      Traversal.
> 
>   o  When the window size allows, sends an INFORMATIONAL request
>      containing the CHANGE_PATH notification payload (which does
>      not contain any data), and clears the "pending_update" flag.
> 
> <LD> Since this is optional, suggest using the keyword MAY or 
> OPTIONAL </LD>

Which part are you referring to?

>   o  Updates the IP addresses in the IKE_SA and IPsec SAs with 
>      the values from the IP header.
> 
> <LD>  Suggest adding a sentence here or in a more appropriate 
> place that the address changes are implicit, in that the new 
> addresses are not obtained from the IP header, not IKEv2 or 
> MOBIKE payloads.
> </LD>

Hmm.. it's not "implicit" in the sense that change of address
is explicitly requested by the initiator (as opposed to just
updating the SAs based on some more vague hints that a change
might be needed)...  but I'll add something to clarify this.

>   o  Replies with an INFORMATIONAL response:
> 
>      Initiator                   Responder
>     -----------                 -----------
>                             <--  HDR, SK { N(COOKIE2),
>                                            [N(NAT_DETECTION_*)] }
> 
> <LD>
> Should the other optional Notification payloads be present in 
> this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are 
> discussed below, but are not in the above message.
> </LD>

Hmm, actually no, since this step in the process is never 
reached if the NAT_PREVENTED or UNACCEPTABLE_PATH cases happen
(they're already handled in earlier steps).

> 4.  Security considerations
> 
>   The main goals of this specification are to not reduce the
>   security offered by usual IKEv2 procedures and to counter
>   mobility related threats in an appropriate manner.  In some
>   specific cases MOBIKE is also capable of protecting address
>   changes better than existing NAT Traversal procedures.
> 
> <LD>  Since we cannot use bold or other types of emphasis, I 
> suggest using subsections so that each of the topics below 
> stand out.
> </LD>

Hm... they're pretty short to be separate subsections, but I
could try changing the indentation from 3 to 6 or something...

Best regards,
Pasi