review of draft-ietf-mobike-protocol-04.txt

Here is my review of draft-ietf-mobike-protocol-04.txt.
I've seen some comments in the list but had not enough time to
really read them, so I apologize if I point some already known problems...

- in 1 page 3

   IKEv2 is used for performing mutual authentication and establishing
   and maintaining IPsec Security Associations (SAs).

=> too many "and"s

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

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

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

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

- about 4.4: if/when we'd like to extend the mechanism, two things
seem to be interesting:
 - the capability to move to another addresses (than the addresses in
   the IP header of the message), for instance for network controlled
   mobility.
 - the capability to limit the update to a SA set (i.e., partial update).
Both will be easier with a payload...

- in 4.5 page 14

   As described in Section 4.3, both the initiator and responder can
   send a list of additional addresses in the IKE_AUTH exchange.  This
   information can be updated by sending an INFORMATIONAL exchange
   request message that contains either one or more ADDITIONAL_IP4/
   6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification.

=> there is no explanation about NO_ADDITIONAL_ADDRESSES: 4.3 can't help
because it doesn't use it. I propose to move or copy some text from
5.3 where the notification is described.

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

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

- in 5

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

- in 5.3 page 18

   The NO_ADDITIONAL_ADDRESSES notification can be included in an
   INFORMATIONAL exchange request message to indicate that the exchange
   initiator does not have addresses beyond the one used in the exchange
   (see Section 4.5 for more detailed description).

=> in fact in the *current* document there is no description at all
of NO_ADDITIONAL_ADDRESSES...

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

Regards

[email protected]