Re: NAT-T, IKEv2, Vendor ID, port floating??

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   Francis Dupont writes:
   >    Both ends should only enable NAT-T if they have both sent and received
   >    NAT_DETECTION_* notifications, and detected that there is NAT between.
   >    If the NAT-T is disabled by configuration then the end MUST NOT send
   >    NAT_DETECTION_* payloads, because if there is NAT between the other
   >    end will enable the NAT-T and there is no way to tell it otherwise. 
   > => I don't understand how the second sentence applies to the responder:
   > when a NAT is detected and NAT-T not supported or enabled, the IKE
   > session has to be dropped before the end of the IKE_AUTH exchange.
   
   It depends on the implementation.

=> I forgot to specify I considered enviroments where NATs are not smart
and there can be more than one initiator behind, i.e., as we have a
NAT-T mechanism, I considered things work with a NAT only when NAT-T
is used.

   If the NAT-T is disabled on the responder it might not even check
   the NAT_DETECTION_* notifications sent by the initiator, thus it
   might not even notice there is NAT between.

=> I'd like the responder always notices because either there is a
real NAT and NAT-T is needed, or there is an attacker playing NAT
and I'd like to know this.

   Anyways it MUST not send NAT_DETECTION_* packets back to
   initiator if it does not want to allow NAT-T. 
   
=> this MUST is not in the document so at least we should agree
something important is not in the document.

   > Not to put NAT_DETECTION_* notifications will enable the initiator
   > to send the third message but it is not enough.
   
   It depends. If the NAT is smart enough and there is only one initiator
   behind the NAT the ipsec might still work even when NAT-T is disabled. 

=> I don't believe in this case: we have a nice NAT-T mechanism which
works in all cases.

Thanks

Francis.Dupont@enst-bretagne.fr