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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
