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

RE: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt



Andrew Krywaniuk writes:
> One more issue that I just noticed. When rekeying a phase 1 w/ NAT-T, you
> automatically send packets to port 4500. Does this mean that we shouldn't
> include the NAT-D payloads during the phase 1 rekey? What about the vendor
> ids?

The NAT-T protocol stuff does not change even if you start directly on
port 4500 (rekey or preconfiguration), i.e you send normal Vendor-ID,
NAT-D etc stuff and detect NAT normally. Only thing that is left out
is the changing of the port if NAT is detected.

There is also possibility that some clients start directly to port
4500 instead of 500 if they know that the other end support NAT-T (i.e
preconfigured). They will do that before they know if there is NAT
between. If the NAT is then detected they will use the UDP
encapsulation otherwise they will use normal IPsec transport / tunnel
mode. 
----------------------------------------------------------------------
...
Similarly, if the responder needs to rekey the phase 1 SA, then he MUST
start the negotiation using UDP(4500,Y). Any implementation that
supports NAT traversal, MUST support negotiations that begin on port
4500. If a negotiation starts on 4500, then it doesn't need to change
anywhere else in the exchange.
...
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/