Subject: [Mobike] Comments on draft-ietf-mobike-protocol-03.txt

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 2 Oct 2005 18:27:10 -0700

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

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Oct 2005 12:51:42 +0300

Hi Mohan, and thanks a lot for your
comments!

Pasi, can you register this as an issue?
Or break down per section, Mohan's
issues are quite separate below.

>       there is no harm in sending one, this case should be explained somewhere..
I think you are correct. I agree though that this does not cause
a serious problem.

>       RR check won't be done. What is that got to do with NAT traversal ?
Good question. I don't they have much to do with each other.
It seems that the actions in this step should be done in any
case.

Also, "enables NAT traversal" is a bit vague. Presumably we
are sending payloads and making specific actions on the results
of seeing payloads come back.

>        would make sense to include them.
Yes.

>               see any description/hint of how one would use it. 
Missing text, I think. Section 4.5 or 5.3 should
include something along the following lines:

   The ADDITIONAL_*_ADDRESS notification MUST be used
   when there's more than one address to be communicated
   to the peer. The NO_ADDITIONAL_ADDRESSES notification
   MUST be used when there is only one address, and the peer
   was previously informed of multiple addresses. As a result,
   NO_ADDITIONAL_ADDRESSES notification is not needed
   in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES
   notification is needed in the the initial exchange only if there
   is more than one address.

>                take from the IP header and hence it makes sense. Why do we need it for ADDITIONAL_ADDRESS ?
I can't answer this. Pasi?

>                it needs to process one from the client. The last paragraph states something different.
Agreed, this is an issue. I think we wanted to say that
clients that do not intend to use more than one address
do not have to send ADDITIONAL_*_ADDRESS notifications.
But they still need to be able to handle them. This is a part
of the basic mobike protocol that devices supporting this rfc-to-be
should support.

>             explicitly ? If the path still does not work with UPDATE_SA_ADDRESSES, then probably the
Tero, Pasi, can you say something about this?

>            Can we show the DPD exchange here with possible payloads ?
We have an example in Section 3.2. Would that be sufficient,
or do you want more?

>       easy if it is the IKE_SA_INIT message.It might be worth stating when the attack is possible.
Right. Thanks for spotting this!

>    ESP traffic and never reaches the TCP layer and hence no TCP RSTs. Might be worth
Ok.

--Jari