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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 11 Jun 2024 11:22:53 -0700
From: Eyal Birger <eyal.birger@...il.com>
To: Paul Wouters <paul.wouters@...en.io>
Cc: Antony Antony <antony@...nome.org>, davem@...emloft.net, dsahern@...nel.org, 
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	steffen.klassert@...unet.com, herbert@...dor.apana.org.au, 
	pablo@...filter.org, nharold@...gle.com, mcr@...delman.ca, 
	devel@...ux-ipsec.org, netdev@...r.kernel.org
Subject: 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 <paul.wouters@...en.io> wrote:
>
>
> On Tue, Jun 11, 2024 at 1:08 PM Eyal Birger <eyal.birger@...il.com> wrote:
>
>>
>> > 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.
>
>>
>> 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.