[Swan-dev] what is 192.0.3.254:1/8

[Andrew Cagney]

On Wed, 9 Oct 2019 at 00:37, Paul Wouters <paul at nohats.ca> 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