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