Re: [PATCH ipsec-next,v4] xfrm: support sending NAT keepalives in ESP in UDP states

On Tue, Jun 11, 2024 at 10:58 AM Paul Wouters [off-list ref] wrote:

On Tue, Jun 11, 2024 at 1:08 PM Eyal Birger [off-list ref] wrote:

quoted

quoted

One curious question: What happens if the NAT gateway in between returns an
ICMP unreachable error as a response? If the IKE daemon was sending it,
IKEd would notice the ICMP errors and possibly take action. This is
something to consider. For example, this might be important to handle when
offloading on an Android phone use case. Somehow, the IKE daemon should be
woken up to handle these errors; otherwise, you risk unnecessary battery
drain. Or if you are server, flodding lot of nat-keep-alive.

07:33:30.839377 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 29)
    192.1.3.33.4500 > 192.1.2.23.4500: [no cksum] isakmp-nat-keep-alive
07:33:30.840014 IP (tos 0xc0, ttl 63, id 17350, offset 0, flags [none], proto ICMP (1), length 57)
    192.1.2.23 > 192.1.3.33: ICMP 192.1.2.23 udp port 4500 unreachable, length 37
        IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 29)
    192.1.3.33.4500 > 192.1.2.23.4500: [no cksum] isakmp-nat-keep-alive

That's an interesting observation. Do IKE daemons currently handle this
situation?

libreswan logs these messages but since the ICMPs are not encrypted, it cannot act on it by itself.

quoted

If the route between hosts isn't available, any traffic related to the xfrm
state would fail in a similar way, which the IKE daemon could observe as well.
Is there such handling done today?

I would let the regular IKE liveness/DPD handle this. Unless the keepalives could cause the kernel
to suppress further messages as some sort of rate limit protection? If which case it should just ignore
these kepalives and not dp icmp for them?

I also feel this handling should be done based on IKE and not as part of this
feature.

Note that it is perfectly valid to send these keepalives with a TTL=2 in which case these don't traverse the
whole internet but only pass your NAT gateway so it knows to keep the mapping open. The other end just
silently eats these anyway without any other side effects.

Personally I feel TTL=2 is a bit too aggressive as we do have setups with
multipli NATted VMs and CGNs. Currently the patch uses ip_select_ttl() under
the hood which relies on the system defaults and routing configuration.
If needed, we can later add support for tuning the TTL for our socket based on
a sysctl.

Eyal.