Re: Allowing space for packet headers in Wintun Tx/Rx

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Thu, 2021-04-08 at 09:42 -0700, Daniel Lenski wrote:
> On Thu, Apr 8, 2021 at 7:37 AM David Woodhouse <dwmw2@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.

Ok, so that's the PPP header plus either 6 bytes for Fortinet or 4
bytes for F5? The important part for the purpose of this conversation
is "more than four".

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

Right. I'm almost relieved at that, since it's certainly a lot *nicer*
to do it that way than any of the hacks I just described.

We can extend the TUN_PACKET header structure to have Headroom and
Tailroom fields, then add a new ioctl which enables the new TUN_PACKET
format and sets the headroom/tailroom to be used in the Rx ring.
Implementing that should be relatively simple and unintrusive; the
trickiest part of it is maintaining backward compatibility with the
existing TUN_PACKET structure.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]