make a start on transparent ipsec interception, based on bridge(4).
authordlg <dlg@openbsd.org>
Tue, 23 Feb 2021 11:40:28 +0000 (11:40 +0000)
committerdlg <dlg@openbsd.org>
Tue, 23 Feb 2021 11:40:28 +0000 (11:40 +0000)
commit3d3101d2b9e4ce45cf9b56a9ba6359a740b34337
tree001b99a1dfc1128dc449a03b19654b8abbcebf49
parentedebe3b8a33eb989d593f05d5442220a10c7a0cb
make a start on transparent ipsec interception, based on bridge(4).

i found the Transparent Network Security Policy Enforcement paper
by angelos and jason was useful for understanding the background
and why you'd want to do this.

the implementation is a little bit different to the bridge one
because i've tweaked the order that pf and ipsec processing happens,
depending on which direction the packet is going over the bridge.
bridge always runs ipsec processing before pf, no matter which
direction the packet is going. packets going into veb, pf runs first
and then ipsec input processing is allowed to happen. in the outgoing
direction ipsec happens first and then pf. pf runs before ipsec in
the inbound direction so pf can apply policy to ipsec encapsulated
packets before they hit pf. this allows you to apply policy to both
the encrypted and unencrypted packets in both directions.

the code is disabled for now. this is mostly because i want veb(4)
to have a good chance at operating outside the netlock, and i'm
pretty sure the ipsec stack isn't ready for that yet. the other
reason why it's disabled is getting a test setup is effort, but i
want to sleep.
sys/net/if_veb.c