[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKEv2 and NAT traversal unclear
Ari Huttunen writes:
> > The IKE responder MUST include in its IKE_SA_INIT response Notify
> > payloads of type NAT_DETECTION_SOURCE_IP and
> > NAT_DETECTION_DESTINATION_IP. The IKE initiator MUST check these
> > payloads if present and if they do not match the addresses in the
> > outer packet MUST tunnel all future IKE, ESP, and AH packets
> > associated with this IKE_SA over UDP port 4500. To tunnel IKE
> > packets over UDP port 4500, the IKE header has four octets of zero
> > prepended and the result immediately follows the UDP header. To
> > tunnel ESP packets over UDP port 4500, the ESP header immediately
> > follows the UDP header. Since the first four bytes of the ESP
> > header contain the SPI, and the SPI cannot validly be zero, it is
> > always possible to distinguish ESP and IKE messages.
>
> Is it really so that the NAT_DETECTION_* payloads are only sent in one
> direction in IKEv2, while in IKEv1 they are sent both ways? Remember that
> in IKEv1 the NAT-D payload is sent both ways because an endpoint only knows
> that a NAT exist when a NAT-D payload it *receives* doesn't match the packet
> header. Then in IKEv2 the responder will know that a NAT exists iff the
> initiator switches ports? What if the initiator initiates to 4500 at the
> beginning already?
I think they MUST be sent both ways, but of course only the initiator
can do the decision to move to port 4500. The responder needs to see
the NAT_DETECTION_* payloads from the initiator to know if it is
behind (propably static) NAT, so it can start sending keepalives, and
whether it should allow dynamic updating of the the initiator (i.e if
initiator is behind NAT). The initiator needs to see the
NAT_DETECTION_* payload from the responder to see which end is behind
NAT. If initiator detects either end is behind NAT it needs to change
to port 4500, and if it detects it itself is behind NAT it should
start sending keepalives.
If it detects responder is behind NAT, it might enable dynamic address
update (if the responder is behind dynamic NAT the initiator propably
needs some other protocol to find out the responder and the responder
needs to somehow inform the NAT about the incoming IKE requests so
they will be forwarded to it).
> Disclaimer: I've not read the whole IKEv2 draft, just searched for NAT..
I am currently in the progress of reading the draft completely, and I
have some other comments, but when I read the 2.23 and noticed this
same error myself, I remembered that you complained about this
earlier. I had assumed this had been fixed already, but it wasn't.
So here is a new proposed text for the NAT-T:
----------------------------------------------------------------------
IKE MUST listen on port 4500 as well as port 500. IKE MUST respond
to the IP address and port from which packets arrived.
Both IKE initiator and responder MUST include in their
IKE_SA_INIT packets Notify payloads of type
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those
payloads can be used to detect if there is NAT between the
hosts, and which end is behind the NAT. The location of the
payloads in the IKE_SA_INIT packets are just after the Ni and Nr
payloads (before the optional CERTREQ payload).
If none of the NAT_DETECTION_SOURCE_IP payload(s) received
matches the hash of the source IP and port found from the IP
header of the packet containing the payload, it means that the
the other end is behind NAT (i.e someone along the route changed
the source address of the original packet to match the address
of the NAT box). In this case this end should allow dynamic
update of the other ends IP address, as described later.
If the NAT_DETECTION_DESTINATION_IP payload received does not
match the hash of the destination IP and port found from the IP
header of the packet containing the payload, it means that this
end is behind NAT (i.e the original sender sent the packet to
address of the NAT box, which then changed the destination
address to this host). In this case the this end should start
sending keepalive packets as explaind in [Hutt02].
The IKE initiator MUST check these payloads if present and if
they do not match the addresses in the outer packet MUST tunnel
all future IKE, ESP, and AH packets associated with this IKE_SA
over UDP port 4500.
To tunnel IKE packets over UDP port 4500, the IKE header has
four octets of zero prepended and the result immediately follows
the UDP header. To tunnel ESP packets over UDP port 4500, the
ESP header immediately follows the UDP header. Since the first
four bytes of the ESP header contain the SPI, and the SPI cannot
validly be zero, it is always possible to distinguish ESP and
IKE messages.
The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [Hutt02])
are obtained from the Traffic Selectors associated with the
exchange. In the case of NAT-T, the Traffic Selectors MUST
contain exactly one IP address which is then used as the
original IP address.
There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too
long, or the NAT box is rebooted). To recover in these cases,
hosts that are not behind a NAT SHOULD send all packets
(including retranmission packets) to the IP address and port
from the last valid authenticated packet from the other end (i.e
dynamically update the address). A host behind a NAT SHOULD NOT
do this because it opens a DoS attack possibility. Any
authenticated IKE packet or any authenticated UDP encapsulated
ESP packet can be used to detect that the IP address or the port
has changed.
----------------------------------------------------------------------
i will come back to the other comments later.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/