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

[Cole Dishington]

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