On Thu, Apr 8, 2021 at 7:37 AM David Woodhouse <[email protected]> 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
