FW: Review of draft-ietf-mobike-protocol-03.txt

Pete McCann's review was posted to the list, but
hit the non-subscriber filter. Thanks Pete for the
review! Forwarding contents:

Pete McCann wrote:

>Overall this draft is in good shape and it looks almost done.  I have
>only one technical comment and the rest are editorial.
>  
>
and attachment:

Section 1 Introduction

   For
   instance, a user could start from fixed Ethernet in the office, and
   then disconnect the laptop and move to office wireless LAN. 
SHOULD BE:
   For
   instance, a user could start from fixed Ethernet in the office and
   then disconnect the laptop and move to the office's wireless LAN. 

   When
   leaving the office the laptop could start using GPRS, and switch to a
   different wireless LAN when the user arrives home.
SHOULD BE:
   When
   leaving the office, the laptop could start using GPRS.  When the
   user arrives home, the laptop could switch to a
   home wireless LAN.

   MOBIKE updates
   only the outer (tunnel header) addresses of IPsec SAs, and the
   addresses and others traffic selectors used inside the tunnel stay
   unchanged. 
SHOULD BE:
   MOBIKE updates
   only the outer (tunnel header) addresses of IPsec SAs, and the
   addresses and other traffic selectors used inside the tunnel stay
   unchanged. 


Section 2 Terminology and Notation

   In some cases, the diagrams also show what
   payloads defined in [IKEv2] would be typically included in, for
   instance, the IKE_AUTH exchange. 
SHOULD BE:
   To provide context, some diagrams also show the existing
   IKEv2 payloads in existing exchanges: for example, the IKE_AUTH
   exchange contains an encrypted AUTH payload.

Throughout the document: don't use references like ``[IKEv2]'' as nouns in
the sentence.  A reference should augment the existing text [like so],
not serve as a subject or object.


Section 3.1  Basic Operation

   First, the parties have may preferences about which
   interface should be used, due to performance and cost reasons, for
   instance.
SHOULD BE:
   First, the parties may have preferences about which interface
   should be used due to performance and/or cost differences.

   (the "client" in remote access VPN scenario)
SHOULD BE:
   (the "client" in a remote access VPN scenario)

   is responsible for deciding which address pair is used for
   the IPsec SAs, and collecting the information
SHOULD BE:
   is responsible for deciding which address pair is used for
   the IPsec SAs and for collecting the information

   (the "gateway" in remote access VPN scenario)
SHOULD BE:
   (the "gateway" in a remote access VPN scenario)

   simply tells the initiator what addresses it has, but does not update
SHOULD BE:
   simply tells the initiator what addresses it has but does not update

   and when a decision needs to be
   changed, are largely beyond the scope of MOBIKE.
SHOULD BE:
   and when a decision needs to be
   changed are largely beyond the scope of MOBIKE.

   For
   instance, link layer and IP layer mechanisms can be used to track the
   status of connectivity within the local link [RFC2461], movement
   detection is being specified in for both IPv4 and IPv6 [DNA4] [DNA6],
   and so on.
SHOULD BE:
   For
   instance, link layer and IP layer mechanisms can be used to track the
   status of connectivity within the local link [RFC2461], movement
   detection is being specified for both IPv4 and IPv6 [DNA4] [DNA6],
   and so on.



Section 3.2 Example Protocol Runs

   (Initiator gets information from lower layers that its attachment
   point and address has changed.)
SHOULD BE:
   (Initiator gets information from lower layers that its attachment
   point and address have changed.)

   In step 3, the initiator
   notices a change in its own address, and informs the responder about
   this.  At this point, it also starts to use the new address as a
   source address in its own outgoing ESP traffic.  The responder
   records the new address, and if so required by policy, performs a
   return routability check of the address.  When this check completes,
   the responder starts to use the new address as the destination for
   its outgoing ESP traffic.
Perhaps add some verbiage here about the essential mechanism used to
update the SA.  It isn't quite clear how this happens to the un-initated
reader.  Something like the following might help:
   In step 3, the initiator notices a change in its own address, and
   informs the responder about this by sending the UPDATE_SA_ADDRESSES
   payload within an IKEv2 packet that uses the new IP address pair
   but that has the same initiator and responder SPIs.  At this point,
   the initiator also starts to use the new address as a source
   address in its own outgoing ESP traffic.  Upon receiving and
   validating the integrity of the UPDATE_SA_ADDRESSES payload, the
   responder records the new address from the header of the containing
   packet, and if so required by policy, performs a return routability
   check of the address in step 4.  When this check completes, the
   responder starts to use the new address as the destination for its
   outgoing ESP traffic.

   Another protocol run in multihoming scenario is illustrated below.
SHOULD BE:
   Another protocol run in a multihoming scenario is illustrated below.


Section 4.7  Changes in NAT Mappings

  have changed (for example, if the keepalive internal is too long, or
SHOULD BE:
  have changed (for example, if the keepalive interval is too long, or


Section 6 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. 
SHOULD BE:
   The main goals of this specification are to maintain the security
   offered by usual IKEv2 procedures and to counter mobility related
   threats in an appropriate manner while allowing updates to the
   IP addresses of the IKE_SA and CHILD_SAs. 

   See [IKEv2] for
   security considerations for IKEv2 in general.
SHOULD BE:
   See IKEv2 [IKEv2] for
   security considerations for IKEv2 in general.


Section 6.1  Traffic Redirection and Hijacking

   However, just like with normal IKEv2,
SHOULD BE:
   However, as with normal IKEv2,