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

Andrew Cagney andrew.cagney at gmail.com
Thu May 28 14:58:10 UTC 2020

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 dst proto icmp type 8 code 0 dev eth0
> >> + sel src dst 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 dst 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 ( - and the source port and
>     IP protocol from the packet and the second containing ( -
> 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 <-> tunnel. Then when
> doing this, the gateway could signal in the first TSi
> entry that proto 1 port 8 (icmp echo request) triggered
> the subnet-to-subnet request.
> The responder _could_ narrow the tunnel to <-> to
> 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

More information about the Swan-dev mailing list