Allowing space for packet headers in Wintun Tx/Rx
dlenski at gmail.com
Sat Apr 10 18:32:03 UTC 2021
On Sat, Apr 10, 2021 at 7:35 AM David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sat, 2021-04-10 at 13:38 +0000, Simon Rozman wrote:
> > Hi David,This is my proposal:
> > https://git.zx2c4.com/wintun/commit/?id=eebd6aea4f75551f6e847a1d4fff857450bac6e9
> > Awaiting review and zx2c4 approval.
> > Regards, Simon
> Looks good to me; thanks. Just need to work out how to cross-build it
> (I can muster up a Windows VM for testing, but *building* on it is
> beyond my tolerance of Windows for now).
+1 to all that.
> We'll also need to be able to WintunAllocateSendPacket() of the full
> possible MTU, then receive and decrypt into that, and send only the
> actual size of the packet we received.
> A per-packet tail would have let us do that, but I agree that we don't
> want to expand the TUN_PACKET header if we can avoid doing so.
> Perhaps a WintunShrinkAndSendPacket() — which can only *shrink*, of
> course, and which can only be used on the *last* packet allocated,
> checking that its tail *is* the Session->Receive.Tail before adjusting
> the latter accordingly.
In addition to the use case for chopping ESP trailers and
less-than-full-size packets, OpenConnect has the case of "PPP packets
in HDLC-like framing" which need to be "un-HDLC-ed" in a way that can
only cause them to shrink.
There are two cases worth considering where the packet size could
1) Some VPN protocols support compression of the tunneled packets. It
would be bad behavior to use this to stuff a packet of >(advertised
MTU) bytes in <(advertised MTU) bytes, but it wouldn't surprise me if
it exists in the wild. We now deal with receipt of
larger-than-expected-MTU packets in OpenConnect in a relatively
uniform way: allocate MAX(mtu, 16384) bytes for packets coming from
the VPN (if using TLS transport) or MAX(mtu, 2048) if using DTLS.
2) Some VPN protocols concatenate multiple packets into a single
aggregate on the wire. On Linux we can decrypt, truncate, and send to
the tunnel interface without further copying.
Case (1) can be handled with overallocate-and-shrink. Case (2) is
pretty rare among the protocols that OpenConnect supports, so fallback
to memcpy seems fine.
More information about the WireGuard