--------------------

Tero Kivinen (2005-07-12):

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

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

--------------------

Pasi Eronen (2005-07-13):

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

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

--------------------

Tero Kivinen (2005-07-14):

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

Hmm... True, it does make things a simplier in that case.

--------------------

Jari Arkko (2005-07-30):

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

--------------------