Hi,
a few remarks regarding interaction with NAT traversal.
1. In case there's a NAT in between and IKE_AUTH is done over TCP,
there's no event of switching to UDP ports 4500 (which usually takes
place in IKE_AUTH).
a) Which ports should use responder if it wants itself to initiate new
Exchange over UDP
or just wants to send a UDP encapsulated ESP packet to initiator? I
see one possibility -
responder must wait untill Initiator initiates any subsequent
Exchange over UDP 4500
or sends some UDP encapsulated traffic - only after that responder
could learn
the ports NAT is allocated for this mapping. But in general this may
never happen -
IKE SA could be established with no triggering packet from initiator
("Connect" button).
b) In case initiator is behind NAT it seems that responder can't use
ephemeral TCP
for any exchange it initiates, can it? And it can't initiate over
UDP untill
get learned the ports NAT has allocated (see clause above).
2. Draft says that retransissions could be done over different transport.
In case IKE_SA_INIT request is first sent over UDP and then
retransmitted
over TCP, what about NAT_DETECTION_SOURCE_IP content? According to
RFC5996 the retransmitted message MUST be identical to original,
but in this case source port of TCP session will most likely be
different
from port original message was sent from, that will lead
to erroneous NAT detection.
3. Related to above: RFC5996 allows to make IKE_SA_INIT request directly to
UDP 4500
instead of 500. The draft says that TCP transport is using port 500.
Because only one NAT_DETECTION_DESTINATION_IP can be included
In IKE_SA_INIT, we again face the problem of erroneous NAT detection.
4. If ports are included in COOKIE calculation, retransmissions of
IKE_SA_INIT containing COOKIE over different transport will be rejected.
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
