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.
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:
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
