Re: FW: external mobike-protocol-02 review (technical) (issue 42)

[email protected] wrote:

>Yes, this is something that probably deserves a slightly longer
>explanation (but I don't think we should spend too much time on
>it). How about this?
>
>1.3  MOBIKE and Network Address Translation (NAT)
>
>   In some MOBIKE scenarios the network may contain NATs or stateful
>   packet filters (for brevity, the rest of this document talks simply
>   about NATs).  The NAT Traversal feature specified in [IKEv2] allows
>   IKEv2 to work through NATs in many cases, and MOBIKE can leverage
>   this functionality: when the addresses used for IPsec SAs are
>   changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.
>
>   Nevertheless, there are some limitations.  NATs usually introduce an
>   asymmetry in the network: packets reaching the NAT from the "inside"
>   are treated differently from packets coming from the "outside".  This
>   asymmetry leads to restrictions on what MOBIKE can do.  To give a
>   concrete example, consider a situation where both peers have only a
>   single address, and the initiator is behind a NAT.  If the
>   responder's address now changes, it needs to send a packet to the
>   initiator using its new address.  However, if the NAT is, for
>   instance, of the "restricted cone" type (see [STUN] for one
>   description of different NAT types), this is not possible: the NAT
>   will drop packets sent from the new address (unless the initiator has
>   previously sent a packet to that address -- which it cannot do until
>   it knows the address).
>
>   For simplicity, MOBIKE does not attempt to handle all possible NAT-
>   related scenarios.  Instead, MOBIKE assumes that if NATs are present,
>   the initiator is the party "behind" the NAT, and does not fully
>   support the case where the responder's addresses change.
>
>   "Does not fully support" means that no special effort is made to
>   support this functionality.  However, if the alternative is losing
>   connectivity completely, the responder can still attempt to proceed
>   with the change, and depending on, e.g., the exact type of NAT, it
>   may succeed.  However, analyzing the exact circumstances when this
>   will or will not work is not done in this document.
>  
>
Works for me.



>>==> "relatively long timeout intervals" is pretty ambiguous.
>>While this may not affect the interoperability, shouldn't we be
>>a bit more precise what kind of order of magnitude we're
>>talking about here?  Seconds?  Ten seconds?  30 sec?  Minutes?
>>10 minutes? Hours?
>>    
>>
>
>This is to some degree also a matter of local policy... but I
>guess it would be useful to at least give a reasonable example.
>
>Tero, do you have an opinion about what would a good
>recommendation be? Maybe something like
>
>   "While no specific timeout lengths are required, it is
>   suggested that responders continue retransmitting IKEv2
>   requests for at least five minutes before giving up."
>  
>
Ok. The key point is that the responder side should
not be aggressive in this regard.

>>   The data associated with this notification is the SHA-1 
>>   hash [FIPS180-2] of the following data:
>>
>>==> this spec is not algorithm-agile. (I can't find the ref
>>right now where this is encouraged.)  In this case, maybe it
>>doesn't need to be considering the impact (I don't take a
>>stance on that) -- but this probably deserves at least brief
>>discussion in the security considerations section.
>>    
>>
>
>This part is basically copied from IKEv2 NAT detection payloads,
>which also use SHA-1 (and IKEv2 spec didn't include any
>discussion about this either)....
>
>However, here the situation might actually be slightly different,
>since the security implications of NAT_DETECTION_*_IP payloads
>and NO_NATS_ALLOWED are different. The simplest solution might
>  
>
Right.

>be just to place the IP addresses in this payload (and mandate
>comparing them with the IP header)...
>  
>
That seems simplest.

--Jari