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

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.

Inline:

>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..
>  
>
I think you are correct. I agree though that this does not cause
a serious problem.

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

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

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

>           -   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 ?
>  
>
I can't answer this. Pasi?

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

>- 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.
>  
>
Tero, Pasi, can you say something about this?

>- Section 4.9
>            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?

>- 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.
>  
>
Right. Thanks for spotting this!

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

--Jari