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

[Tero Kivinen <kivinen@ssh.fi>]

Francis Dupont writes:
>    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.

The current document is missing pieces of the NAT-T text. There have
been text proposed to be added, so I am currently waiting for the next
version of the ikev2 document to see if we still need more text there
or not... I will comment this more when the next version is out, and I
can see what is already added there, and how it was added. 

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

If the adminstrator decided to disable NAT-T then we have two options,
either we fail immediately always when there is NAT between (your
option), or we just try to see if it works through the NAT without
NAT-T (I said we should leave this option also open). If it does not
work through the NAT and adminstrator has disabled the NAT-T, then
we are going to fail later anyways. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/