Comments on draft-ietf-mobike-protocol-03.txt

A few comments/questions...

 - Section 4.4

           The initiator receives a NAT_DETECTION_DESTINATION_IP notification
           that does not match the previous UPDATE_SA_ADDRESSES response (see
           Section 4.7 for a more detailed description).
     
      This does not work reliably when IKE rekeying happens which changes the IKE SPIs.
       The initiator is behind NAT, creates the IKE SA and notes the down the
       NAT_DETECTION_DESTINATION_IP notification value (hash of SPI,
       IP address and port). If rekeying happens sometime later but never received
       a NAT_DETECTION_DESTINATION_IP or received one before rekeying happened,
       then the hash may differ because the NAT rebooted causing ports to change OR SPIs
       changed because of rekeying. How do you tell the difference between the two ?
       According to section 4.7, the sender SHOULD send UPDATE_SA message. Though
       there is no harm in sending one, this case should be explained somewhere..

             If the IPsec SAs were updated in the previous step: 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.

       I did not understand this step at all. If the IPsec SAs were updated, then the
       RR check won't be done. What is that got to do with NAT traversal ?

            If there are outstanding IKEv2 requests (requests for which the
             initiator has not yet received a reply), continues retransmitting
             them using the addresses in the IKE_SA (the new addresses).

        This does not have a corresponding section in what the responder. Though, trivial
        would make sense to include them.

- Section 4.5
           - What is the use of "NO_ADDITIONAL_ADDRESS" notification ? At least i did not
               see any description/hint of how one would use it. 

           -   What is the use in adding NO_NATS_ALLOWED along with ADDITIONAL_ADDRESS
                 notification ?  The receiver of ADDITIONAL_ADDRESS takes it from the notification payload
                 and not from the IP header.  Is it just that you want to include NO_NATS_ALLOWED with
                 all possible notifications ? But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA
                 _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and UPDATE_SA, you
                take from the IP header and hence it makes sense. Why do we need it for ADDITIONAL_ADDRESS ?

            - The VPN gateway may have a single address but the client may have multiple addresses.
               In that case it is okay if it does not send ADDITIONAL_ADDRESS notification but
                it needs to process one from the client. The last paragraph states something different.

- Section 4.7

             If the initiator is behind NAT, and if he suspects that the peer is *dead*, he can send a DPD message
             with UPDATE_SA_ADDRESSES to recover faster. This was discussed in the mailing list sometime
             back. But i don't see this suggestion. Why do we have to know that the NAT mapping has changed
             explicitly ? If the path still does not work with UPDATE_SA_ADDRESSES, then probably the
             path has failed.

- Section 4.9
            Can we show the DPD exchange here with possible payloads ?

- Section 6.1
     
       The last paragraph talks about NO_NATS_ALLOWED. The attack of modifying the header
       to cause DoS attack is only possible if the attacker knows that NO_NATS_ALLOWED is
       carried within the payload. As payloads are encrypted, it may not be that easy always. It is
       easy if it is the IKE_SA_INIT message.It might be worth stating when the attack is possible.

- Section 6.3

        Normally such attacks would expire in a short time frame due to the
        lack of responses (such as transport layer acknowledgements) from the
        victim.  However, as described in [Aura02], malicious participants
        would typically be able to spoof such acknowledgements and maintain
        the traffic flow for an extended period of time. 
 
   This attack is possible because the victim does not have a valid SA for the incoming
    ESP traffic and never reaches the TCP layer and hence no TCP RSTs. Might be worth
    mentioning here.

-mohan