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

Re: a proposal of address management for IKEv2



Francis Dupont writes:
> => I still don't believe this is the good solution. In fact the initiator
> knows there is a NAT only with the reply: my proposal is to keep the
> unspecified address as the secret one and to rely on the reply (which
> will contain the address received by the responder). The only difference

Note, that either one of the ends can be behind NAT. We need to detect
which one (or both) is behind the NAT, to enable keepalives.

> is the responder can believe there is a NAT in the path when there is none
> but we have to handle the case where a NAT is inserted or removed from
> the path so this is not a problem...

I don't think there are cases where NAT is inserted or removed in the
path during the IPsec connection, thus we do not need to take care of
those cases. There are cases where the other ends IP address either
changes or does not change (i.e mobile ip) in transit, but those cases
are NOT NAT cases, as we do know when the address changes and we can
send explicit notification about that.

In my talks NAT is the box in the path that will not give out any
notifications and there is no way to modify its functionality. The
Mobile IP cases are not NAT cases, as we can get information when and
how they modify the ip-addresses.

To fix various attacks, the NAT-T handling MUST NOT be enabled if
there is no NAT between. 

> BTW what is the best mechanism for the switch between ports 500 and 4500?

Immediately when the NAT is detected we switch to 4500 and we stay
there as long as the connection is open (i.e all rekeying etc happens
in that port). When the IKE SA is deleted we SHOULD still remember to
use port 4500 for few minutes (i.e in case we reconnect we should use
the port 4500 for reconnection for next few minutes). After few
minutes there is no need to remember to use port 4500 as the NAT has
already deleted the mapping because we do not send keepalives anymore.
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/