-------------------- Pete McCann (2005-10-11): https://www.machshav.com/pipermail/mobike/2005-October/001114.html >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, --------------------