Issue 33: Changing ports 500/4500 and RR

Tero Kivinen wrote:

>> 2.7  NAT prevention
>...
>>    If the IKE_SA_INIT request included NAT_DETECTION_*_IP
>>    payloads but no NAT_PREVENTION payload, the situation is
>>    different since the initiator may at this point change
>>    from port 500 to 4500.  In this case, the responder
>>    initializes (local_address, local_port, peer_address,
>>    peer_port) from the first IKE_AUTH request.  It may also
>>    decide to perform a return routability check soon after
>>    the IKE_AUTH exchanges have been completed.

> Why does it need to do the return routability check? IKEv2
> NAT-T does not do return routability checks there, why should
> we do? Note, that the initiator will not see any IPsec packets
> thus he cannot for example start TCP sessions, as those are
> not retransmittede to secondary addresses. I cannot really see
> how he could mount any real attack at this phase.

Hmm.. you're probably right, there's no good reason to do
the return routability check at this stage. I guess we can
delete the last sentence..?

>>    IKEv2 requires that if an IPsec endpoint discovers a NAT
>>    between it and its correspondent, it MUST send all
>>    subsequent traffic to and from port 4500.  To simplify
>>    things, implementations that support both this
>>    specification and NAT Traversal MUST change to port 4500
>>    if the correspondent also supports both, even if no NAT
>>    was detected between them.
>
> What does that simplify? In normal case implementations will
> never do that as it wastes 4 bytes for each IKE packet.

We don't need to change ports later if we move to a path that
has a NAT (if we would change ports, we'd need to specify when
exactly the changes happen and how, etc.). (I don't think
wasting 4 bytes in IKE (not ESP) packets is a big problem...)

Best regards,
Pasi