[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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. 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. Anyways it MUST not send NAT_DETECTION_* packets back to
initiator if it does not want to allow NAT-T. 

> 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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/