Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07

[Paul Wouters <[e-mail]>]

On Thu, 1 Apr 2021, Antony Antony wrote:

> In my experience it would work well when there is no NAT. When there
> there is NAT the IKE and ESP in UDP should use same ports, otherwise
> IKE will get established and ESP packets could get dropped in one
> direction. When there is NAT it would look more like a client-to-server
> than a peer-to-peer.

One idea could be to use MOBIKE probes (without UPDATE_SA) by the
initiator behind NAT to get multiple NAT mappings? It might require
kernel changes depending on how it implements NAT updates :/

> I implemented a proof concept - UDP source port set to 16bit hash of out going SPI.
> Then it occurred to me the hash could collide with other well
> known UDP ports e.g. hash of an SPI or/and IP address could be 53(DNS).
> Some admins may not be happy to see source port 53 for ESP in UDP traffic.

I seen this in the wild already with a large VPN provider blocking port
19 (chargen) and NAT gateways picking port 19 as source port. While this
could be an attack to try and trigger chargen responses from a spoofed
packet, I don't think it is. It might work for TCP, but not really for
UDP as a DoS attack. I think in the end, sadly, we have to expect every port
to be used by badly designed NAT gateways.

However, it would still be a good design to keep UDP source ports in the
ephemeral ranges. This also helps against local policy enforcements,
such as Linux's SElinux policies.

> If you choose ephemeral source ports both sides should know the source
> ports otherwise SADB remap will be generated. If we disable that real NAT
> would break...
> So far I don't have a clean solution which would work with NAT and without NAT
> for our use case.

That is indeed the real problem to solve. I have to do some more
testingwith MOBIKE probes on the same IP with only port differences
and see if the kernel acts like these are port updates or not if it
is only IKEinUDP and not ESPinUDP.

Paul