On Wed, 27 May 2020 at 21:16, Paul Wouters <[email protected]> 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
