Subject: [Mobike] Issue 62: Editorial comments from Francis (was: review of draft-ietf-mobike-protocol-04.txt)

From: <[email-masked]>
Date: Fri, 21 Oct 2005 15:06:54 +0300

Francis Dupont wrote:
> - in 1 page 3
> 
>    IKEv2 is used for performing mutual authentication and establishing
>    and maintaining IPsec Security Associations (SAs).
> 
> => too many "and"s

Ok, I'll rephrase that.

> - in 3.1 page 5
> 
>   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 a better position to decide
>   which of its network interfaces should be used for both upstream and
>   downstream traffic.
>
> => as this has some limitations IMHO there should be a pointer to
> the section 3.4 "Limitations".

Earlier I've received comments that the document has too many pointers
back and forth, so I've tried to avoid them (unless the paragraph will
be difficult to understand with them).  Here section 3.4 just provides
some additional information the reader doesn't yet need at this point,
and she/he will get to that section eventually :)

> - in 3.2 page 6 and others
>
>      Initiator                  Responder
>     -----------                -----------
>   1) HDR, SAi1, KEi, Ni,
>           N(NAT_DETECTION_*_IP)  -->
>
>                            <--  HDR, SAr1, KEr, Nr,
>                                      N(NAT_DETECTION_*_IP)
>   ...
>
> => I believe the illustration needs the IP addresses and ports from
> IP and UDP headers. If someone finds a good way to add them, the 
> whole stuff will become far more readable.

Yes, that's a good suggestion. How about something like this:

   1) (IP_I1:500 -> IP_R1:500) 
      HDR, SAi1, KEi, Ni,
           N(NAT_DETECTION_*_IP)  -->

                            <--  (IP_R1:500 -> IP_I1:500)
                                 HDR, SAr1, KEr, Nr,
                                      N(NAT_DETECTION_*_IP)
   <snip>

   3) (IP_I2:500 -> IP_R1:500)
      HDR, SK { N(UPDATE_SA_ADDRESSES),
                N(NAT_DETECTION_*_IP) }  -->

That is, use IP_I1,IP_I2,,.. for initiator addresses and IP_R1,IP_R2,...
for responder addresses...?

> - in 4.3 page 10
> 
>    Note that if some of the initiator's interfaces are behind a
>    NAT (from the responder's point of view), the addresses
>    received by the responder will be incorrect.  This means the
>    procedure for changing responder addresses described in
>    Section 4.5 does not fully work when the initiator is behind a
>    NAT.  For the same reason, the peers also SHOULD NOT use this
>    information for any other purposes than what is explicitly
>    described in this document.
> 
> => I have a problem with "this document". I propose to relax it in
> "MOBIKE documents".

How about rephrasing that to "...for any other purpose than what is
explicitly described either in this document or a future specification
updating it" ?

> - in 4.4 page 11
>
>   The reasons why the initiator wishes to change the addresses
>   are largely beyond the scope of MOBIKE.  Typically, triggers
>   include information received from lower layers, such as changes
>   in IP addresses or link-down indications.  Some of this
>   information can be unreliable: for instance, ICMP messages
>   could be spoofed by an attacker.  Unreliable information itself
>   MUST NOT be used to conclude than an update is needed: instead,
>   the initiator SHOULD trigger dead peer detection (that is, send
>   an INFORMATIONAL request).  
>
> => this at the first read seems to conflict with path testing
> (4.9).  IMHO some clarification is needed, I propose something
> like (after "an update is needed") "because the current path
> seems to be no more usable"...

Hmm, yes, the paragraph needs some clarification. In some sense, 
most of the information available to the host is to some degree 
unreliable, and there's no way to avoid using some of that.

How about rewriting the last sentence as follows?

   "Unreliable information SHOULD be treated only as a hint that there
   might be a problem, and the initiator SHOULD trigger dead peer
   detection (that is, send an INFORMATIONAL request) to determine if
   the current path is still usable."

<snip>

> - in 4.6 page 15
>
>   To ensure that the peer cannot generate the correct
>   INFORMATIONAL response without seeing the request, a new
>   payload is added to INFORMATIONAL messages.  The sender of an
>   INFORMATIONAL request MAY include a COOKIE2 notification, and
>   if included, the recipient of an INFORMATIONAL request MUST
>   copy the notification as-is to the response.  When processing
>   the response, the original sender MUST verify that the value is
>   the same one as sent.  If the values do not match, the IKE_SA
>   MUST be closed.
>
> => there is no explanation about COOKIE2, I propose an explicit
> pointer to section 5.6.

Ok, will be added.

> - in 4.9 page 17

>   IKEv2 Dead Peer Detection allows the peers to detect if the
>   currently used path has stopped working.  However, if either of
>   the peers has several addresses, Dead Peer Detection alone does
>   not tell which of the other paths might work.
>
> => this text is fine but perhaps a bit late in the document
> (i.e., path testing should be in the overview too)?

Since this is not really new to MOBIKE, but just explains that
the existing Informational exchange works, I'm not sure
if adding more forward pointers would make any difference
to the reader?

> - in 5
>
> => I believe "notification" is better English than "notify" but
> as the IKEv2 document uses "notify payloads"...

I've tried to make this reasonably consistent with the IKEv2 spec
(but yes, IKEv2 could have been more consistent itself :-).

<snip>

> - in 6.1 page 20
>
>   MOBIKE introduces the NO_NATS_ALLOWED notification that is used
>   to detect modification, by outsiders, of the addresses in the
>   IP header.  When this notification is used, communication
>   through NATs and other address translators is impossible, so it
>   is sent only when not doing NAT Traversal.  This feature is
>   mainly intended for site-to-site VPN cases, where the
>   administrators may know beforehand that valid NATs are not
>   present, and thus any modification to the packet can be
>   considered an attack.
>
> => IPv6 environments are other obvious candidates for
> NO_NATS_ALLOWED!

Yes, Tero also pointed this out (see issue 59 for my proposal
for text).

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Oct 2005 18:09:35 +0200

Earlier I've received comments that the document has too many pointers
   back and forth, so I've tried to avoid them (unless the paragraph will
   be difficult to understand with them).
   
=> this is a matter of taste: with pointers you have to turn pages when
you read the document, without pointers you have to read it twice to
catch the whole thing... I don't know what is the best for everybody,
for me it is the first (pointers).

   

   
   
=> this seems fine, thanks!

   
=> in the documents I thought about the "transport mode" one which uses
the additional addresses but can't be qualified as "updating".
I believe my proposal is better (and simpler/shorter).

   
   
   <snip>
   
=> fine.

   
   
=> it was just a suggession.

   
=> I'll try to reread all the other comments in time.

Thanks

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike