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

Hi Pasi,

Please see inline:

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Tue 7/12/2005 1:41 AM
To: Dondeti, Lakshminath; [email protected]
Subject: RE: [Mobike] 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.

<LD>
Sounds ok.  We can revisit that later too.  I guess my point was that 
multihoming is also what this protocol sets out to handle, so as long 
that gets similar prominence, we are ok.
</LD>

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

<LD>
Address integrity protection sounds fine, but having the word NAT in 
there might help.  Let us see if anyone has some ideas.
</LD>

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

<LD>
I read that draft just now and found this definition:

"Path: The route taken by the SCTP packets sent by one SCTP
      endpoint to a specific destination transport address of its peer
      SCTP endpoint.  Sending to different destination transport
      addresses does not necessarily guarantee getting separate paths."

That is closer to the dictionary definition of the word path than MOBIKE 
uses, no?  I think address pair is still better, while not as convenient 
path, it imparts the correct meaning.

</LD>

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

<LD>
Ok, this may be a bit of nitpicking but I am trying to have documents 
"spell out" what's clearly optional.
"When the window size allows" does mean that sending CHANGE_PATH 
notification is optional.  Or are you saying that "when the window size 
allows" it is a MUST.
</LD>

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


<LD>
Thanks.
</LD>

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

<LD>
Ok, I should have read a bit more carefully!  There is some 
inconsistency in that page though.  The case of UNACCEPTABLE_PATH is 
inline with the text and the case of  NAT_DETECTION_* is specified with 
headers and such.  Please make it consistent in the future versions -- 
or perhaps use my suggestion and say that the resultant message after 
considering all the steps would be HDR, SK{N(COOKIE2), [N()], N[]}.  
Perhaps your way of separating them out is better, but please make it 
consistent.

</LD>

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

<LD>
Others on the list had some suggestions on this section.  Let us wait 
and see how it evolves.
</LD>

At this point, let me say again that you did a great job for a -00-.  
The draft is already on an excellent path already (hope there are no 
NATs in the way) :-).

cheers,
Lakshminath


Best regards,
Pasi