Re: peer address protection and NAT Traversal

[[e-mail]]

I've now read and understood draft-dupont-transient-pseudonat-01.txt. I'd
like to propose language in the IKEv2 and NAT traversal documents to
address it, but I'm eager to hear from the NAT Traversal folk whether the
fix will break too many real cases.

Francis Dupont <[e-mail]> wrote:
>  The I-D editor has just announced the new version of my I-D about
> the transient pseudo-NAT attack and its application to Mobile IPv4
> (documented in the security section of the NAT traversal extension)
> and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt.
>  I believe we should fix the issue (the security flaw) for the next
> version of the IKEv2 document.

While the threat comes up in many contexts, the easiest serious form of it
involves UDP encapsulation of IKE and ESP packets. If one endpoint of an
IPsec tunnel is behind a NAT, packets it sends will be encapsulated in UDP
and sent with source and destination ports both equal to 3500. That
endpoint must be the one that initiates the IKE connection. The receiving
endpoint will see a different source IP address and UDP port (because they
were mapped by the NAT) and will respond to the address and port it sees.
The NAT will map these back to the original endpoint's address and port
3500. So far, so good.

Mapped UDP port assignments in NATs can be timed out prematurely. When this
happens, packets coming from the Internet to the NAT will be dropped (or
misrouted) and packets coming from the NAT-protected node to the Internet
will be sent with a different source UDP port and possibly different source
IP address. For most protocols, that will cause the connection to fail.
Sometimes the connection will be dynamically reformed if there is retry at
the application layer. A NAT-aware protocol can try to do better. Since
there is an SPI in the header of every ESP and IKE packet that uniquely
identifies the SA, an endpoint can accept packets ignoring the source IP
address and port without confusion. It can send responses to the address
and port from which it received the request fairly safely. But for the SA
to survive the remapping of UDP ports by the NAT, it must also start
sending its own requests and encapsulated ESP packets to the new UDP port
and IP address. This is where the opportunity for mischief occurs.

If an attacker on the path between the two endpoints pretends to be a NAT
and changes the source address and UDP port of a single packet, what should
the recipient do? If he starts sending to the new address, it makes the
IPsec SA very fragile and potentially causes a packet flooding attack
against the node whose IP address was forged in the header. If he doesn't,
all the packets sent will be lost in the case where a genuine NAT remapped
addresses. Since NATs are not generally capable of cryptographic
authentication, there is no reliable way to distinguish these cases.

I could imagine lots of clever ways to try to deal with this... all with
clever countermeasures that allow an attacker to exploit them.

So what I'd like to propose is that IPsec SAs *not* try to survive
mid-connection NAT renumberings. That an IP address and UDP port be
associated with an SA during initialization and that all subsequent traffic
be sent to that address and port until it is timed out and closed. Requests
*from* an unexpected IP address/port should be ignored. (Perhaps there is a
way to respond with an alert to make the timeout process converge faster,
but I couldn't think of one that couldn't be exploited by an attacker).

There is a residual attack here where the attacker gets in the middle of
the initial SA setup and tricks the endpoints into sending to the wrong
address by forwarding all the packets during setup. (If it continues to
forward packets throughout the SA, everything works... essentially it *is*
a NAT. But if it stops it can temporarily get traffic misdirected). This
seems like a difficult attack more easily mounted against other UDP based
protocols. It exists for non-cryptographic protocols even in the absence of
NATs. And preventing it seems to require detecting NATs and refusing to
operate through them. Perhaps there should explicitly be a configuration
parameter in IPsec implementations allowing this.

I'm out of my depth here. What do existing implementations do? Do they not
support mid-connection renumbering or are they subject to the DOS attack?
Is there a known better fix?

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).