[Swan-dev] F32(5.6.8-100.fc30.x86_64) Kernel not reporting ICMP shunt events correctly?

[Andrew Cagney]

On Wed, 27 May 2020 at 21:16, Paul Wouters <paul at nohats.ca> wrote:
>
> On Wed, 27 May 2020, Andrew Cagney wrote:
>
> > How the kernel reports a ping seems to have changed.  However, is
> > there also a problem with what pluto does next?
>
> >> - sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 8 code 0 dev eth0
> >> + sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 0 code 0 dev eth0
>
> It seems to have broadened the acquire from "icmp type echo" to "icmp".
> Normally, this is supposed to convey the trigger packet src/dst
> exactly, so we can put that in a TS for the other side, so they get
> a regular TSi/TSr and one for the trigger. It helps the remote the pick
> the right tunnel.

Ah (yes), so this is a regression regardless.

> > Picking up from IRC.
> >
> > Going by some of the comments I'm reading in the code, OE should set
> > up a tunnel for all-protocols and all-ports.
>
> It depends, we do support protoport specific OE, because some people
> insisted on being able to do OE for a single port (or exclude a single
> port). See the following test cases:

This is interesting, there's many cases in the oe code where it:

- takes the information from the acquire and squeezes it into an
address (it typically has a non-zero port) and stuffs it into an
endpoint (address+port) masquerading as an address
(whack triggered oe doesn't set the port)
- converts it to a subnet
- forces the port to 0

It must be then, using further convoluted logic to, possibly put the port back.

> newoe-18-poc-cop-port22
> newoe-18-poc-cop-port22-both
> newoe-18-poc-cop-port22-both-reorder
> newoe-18-poc-cop-port22-transport
>
> So we should find the most precise match first.
>
> >  Hence, no matter what
> > the kernel indicates, the port/protocol should be stripped and:
> >> + sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 0 code 0 dev eth0
> > installed?
>
> Not "no matter what". See above, we technically should put the trigger
> packet into a TS:
>
> RFC 7296 Section 2.9: https://tools.ietf.org/html/rfc7296#section-2.9
>
>     To enable the responder to choose the appropriate range in this case,
>     if the initiator has requested the SA due to a data packet, the
>     initiator SHOULD include as the first Traffic Selector in each of TSi
>     and TSr a very specific Traffic Selector including the addresses in
>     the packet triggering the request.  In the example, the initiator
>     would include in TSi two Traffic Selectors: the first containing the
>     address range (198.51.100.43 - 198.51.100.43) and the source port and
>     IP protocol from the packet and the second containing (198.51.100.0 -
>     198.51.100.255) with all ports and IP protocols.  The initiator would
>     similarly include two Traffic Selectors in TSr.  If the initiator
>     creates the Child SA pair not in response to an arriving packet, but
>     rather, say, upon startup, then there may be no specific addresses
>     the initiator prefers for the initial tunnel over any other.  In that
>     case, the first values in TSi and TSr can be ranges rather than
>     specific values.
>
>
> Now, for icmp it is useful to send src/dst ip address, but protoports
> wouldn't be very useful. But I see no good reason not to send it.
>
> So if you have a 192.0.1.0/24 <-> 192.0.2.0/24 tunnel. Then when
> doing this, the gateway 192.1.2.23 could signal in the first TSi
> entry that 192.0.1.254 proto 1 port 8 (icmp echo request) triggered
> the subnet-to-subnet request.
>
> The responder _could_ narrow the tunnel to 192.0.1.254 <-> to
> 192.0.2.254 based on that if that matches the "trigger packet"
> in the TS it received. It _could_ narrow it down to a specific
> udp/port too if that was the case.
>
> > (segway, is protoport=tcp/10 valid on an OE template connection?)
>
> You dont specify these as protoport= entries, but you would specify
> them in the "foodgroup" entries to have more specific protoports.
> See the above test cases.
>
> Paul