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
