netdev - Re: [PATCH] netfilter: nf_conntrack: Add conntrack helper for ESP/IPsec

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <82faec0c7d403a76781372b0fd7911c9c08bb87a.camel@alliedtelesis.co.nz>
Date:   Thu, 6 May 2021 02:59:49 +0000
From:   Cole Dishington <Cole.Dishington@...iedtelesis.co.nz>
To:     "fw@...len.de" <fw@...len.de>, "jengelh@...i.de" <jengelh@...i.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "pablo@...filter.org" <pablo@...filter.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kadlec@...filter.org" <kadlec@...filter.org>,
        "coreteam@...filter.org" <coreteam@...filter.org>
Subject: Re: [PATCH] netfilter: nf_conntrack: Add conntrack helper for
 ESP/IPsec

On Wed, 2021-05-05 at 14:16 +0200, Jan Engelhardt wrote:
> On Wednesday 2021-04-14 17:40, Florian Westphal wrote:
> > 
> > Preface: AFAIU this tracker aims to 'soft-splice' two independent
> > ESP
> > connections, i.e.: saddr:spi1 -> daddr, daddr:spi2 <- saddr. [...]
> > This can't
> > be done as-is, because we don't know spi2 at the time the first ESP
> > packet is
> > received. The solution implemented here is introduction of a
> > 'virtual esp id',
> > computed when first ESP packet is received,[...]
> 
> I can't imagine this working reliably.
> 
> 1. The IKE daemons could do an exchange whereby just one ESP flow is
> set up (from
> daddr to saddr). It's unusual to do a one-way tunnel, but it's a
> possibility.
> Then you only ever have ESP packets going from daddr to saddr.
> 
> 2. Even if the IKE daemons set up what we would consider a normal
> tunnel,
> i.e. one ESP flow per direction, there is no obligation that saddr
> has to
> send anything. daddr could be contacting saddr solely with a protocol
> that is both connectionless at L4 and which does not demand any L7
> responses
> either. Like ... syslog-over-udp?
> 
> 3. Even under best conditions, what if two clients on the saddr
> network
> simultaneously initiate a connection to daddr, how will you decide
> which of the daddr ESP SPIs belongs to which saddr?

1 and 2 are limitations of treating two one-way ESP SAs as a single
connection. I think 1 and 2 would be less of an issue with Florian
Westphal's latest comments requesting expectations (although an
expectation for the other side would still be setup). 3 is handled by
assuming the first ESP packet will get the first ESP response. I think
the only way past 1 (and a more reliable approach to 3) would be by
processing ISAKMP messages.

However, considering that the ESP connection tracker's primary use is
to allow clients behind a NAT that doesn't support (or use) NAT-T a
method of establishing a connection wihout manually configuring
specific NAT rules, these limitations might be acceptable.

Thanks