CVSROOT: /cvs
Module name: src
Changes by: d...@cvs.openbsd.org 2025/02/14 06:14:13
Modified files:
sys/net : if_bridge.c if_sec.c
sys/netinet : ip_ipsp.h ip_output.c ipsec_output.c
sys/netinet6 : ip6_output.c
Log message:
add tunneldf support to sec(4)
sec(4) is a very thin wrapper around the existing ipsec output
processing for encapsulating packets, and inherited the behaviour
that the DF flag was propagated from the encapsulated packet to the
outer ip header.
this means if the sec(4) interface has a large mtu and is carrying
packets with DF set over a network that can't transport large(r)
packets, these packets are effectively dropped. ipsec applied via
the SPD copes with this by having SAs figure out the path mtu and
using that when applying policy, but sec(4) is an interface, so the
network stack uses the interface mtu rather than the associated
SA path mtu.
rfc4459 discusses this kind of problem has offers a variety of
solutions. this implements one of the simpler options, which is to
allow the tunnel endpoints to manage the DF regardless of the payload
and reassemble the encapsulated packets.
to actually do this, ipsec output packet processing has to be able
to take an argument that says how you want DF to be handled.
in the future we're going to look at how we can use the path mtu
determined by the ipsec SA to try and implement one of the other
solutions from the RFC, which is to signal the lower mtu to the
sources of tunnelled packets.
tested by and ok claudio@
