Allowing space for packet headers in Wintun Tx/Rx

[Daniel Lenski]

On Thu, Apr 8, 2021 at 7:37 AM David Woodhouse <dwmw2 at infradead.org> wrote:
>  =============
>  PPP over DTLS
>  =============
>
> We just added support for the PPP-based protocols (Fortinet, F5) and
> I'm not sure we even know what the DTLS-based version looks like on the
> wire, do we? If the header is 4 bytes or fewer, the same nasty trick
> works that I suggest for Cisco DTLS above. And a PPP header even with
> accomp and pfcomp *would* fit in 4 bytes. For the TCP transports we
> have an additional framing but I'm hoping those aren't there in DTLS?
>
> If we do need a header larger than 4 bytes, then we are forced to do
> things properly by adding support in the kernel driver instead of just
> abusing the existing header while we know the kernel isn't looking at
> it.

This is probably too much "inside baseball" for the non-(OpenConnect
developers) here, but I *have* confirmed that the PPP-over-DTLS
encapsulation is identical to the PPP-over-TLS encapsulation for the 2
PPP-based protocols that we support already. Both F5 and Fortinet
essentially opted for the thinnest veneer of UDP-ization possible for
their protocols.

> So, what do we want, and what's the bare minimum we actually *need*
> from Wintun to be able to avoid those memcpys?
>
> The bare minimum is either exposing enough of the TUN_SESSION to let us
> manage the rings for ourselves, or a function which can resize the
> *last* allocated packet from the Tx ring before we call
> WintunSendPacket() on it. That's purely userspace in wintun.dll.
>
> The next request would be to expand the TUN_HEADER to include head/tail
> space, and a parameter in the TUN_REGISTER_RINGS structure which
> configures the amount of head/tail space to leave between received
> packets. That's a change in the kernel API and is more complex to
> manage, and as noted we *could* live without it for now although it's
> kind of ugly, still involves *some* copying at the tail of outbound ESP
> packets, and depends on those PPP headers not exceeding the 4 bytes
> that are currently available for us to abuse :)

The tl;dr for OpenConnect is that we really would need support for
arbitrary head/tail space in order not to have to do *any* memcpy.

Dan