On Wed, 9 Oct 2019 at 00:37, Paul Wouters <[email protected]> wrote: > > On Tue, 8 Oct 2019, Andrew Cagney wrote: > > > find_connection: looking for policy for connection: 192.0.3.254:1/8 > > -> 192.0.2.254:1/0 > > > > perhaps this helps (or confuses)? > > Yes, it is the encoding of types/subtypes into ports as per > https://tools.ietf.org/html/rfc7296#section-3.13.1
Ah, so xfrm is following the model put forward in the RFC. > > subnet from endpoint 192.0.3.254:8 (in netlink_acquire() at > > kernel_netlink.c:1782) > > add bare shunt 0x7f943c3fdf78 192.0.3.254/32:8 --1--> > > 192.0.2.254/32:0 => %hold 0 %acquire-netlink > > > > since this is happening when an acquire is triggered by a ping packet, > > 1 is maybe ICMP and 8 is something found in the acquire's .sport > > field (but what?) > > > > Two problems: > > > > - the syntax is terrible: :1 isn't a port, /8 isn't a mask - even > > 192.0.3.254:(1/8) would be better > > I guess ideally it would be: 192.0.3.254/32 --1/8--> 192.0.2.254/32:0 192.0.3.254/32 --ICMP.PING--> 192.0.2.254/32:0 although this doesn't help the log line: subnet from endpoint 192.0.3.254:8 (in netlink_acquire() at kernel_netlink.c:1782) but I suspect here the problem is that the code's abusing ip_subnet so that record_and_initiate_opportunistic() signature doesn't need to be changed > > - there's a subnet kicking round with a bogus port 8, does it get > > scrubbed, or do we get away with this because the IKEv2 TS code is > > instead looking at end.port and that's zero ... > > It might get wiped in the "broadening" of the shunt. And it cannot work > without broadening, because you cannot have a narrowed policy for only > 1/8 (well it makes no sense, you could only send pings but not ping > replies). The widening for proto 1 should probably be 1/0 (eg no > sub-types) > > Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
