That doesn't make it particularly good, however. I've looked at it a few times in hopes of implementing my VPN's with it, and there doesn't seem to be any simple intelligible documentation on how to implement it with the basic Linux / FreeBSD tools. It feels like getting into birdwatching with all the different Swans and the weird jargon. Until now, OpenVPN has prevailed.
I'm hoping WireGuard [1] will get widescale support soon enough.
> Until now, OpenVPN has prevailed.
Which is somewhat funny, as FreeS/WAN derivatives are much more convenient to configure than OpenVPN with its tons of options that you need to put either on server side or client side (and those differ greatly) and routing that is very, very easy to screw up.
Also, I always say that OpenVPN is a weird case of a program open source from the ground up that has a closed communication protocol. No specification and extracting the protocol from the source is difficult in this case.
The middle and lower layers of the network stack are historically big-endian, and the ones published as RFCs also tend to be the same, but I've seen many more proprietary little-endian application-layer protocols. That's probably because most systems are LE today and so it's simpler overall to read into memory and operate directly on the values without having to reconvert them, but in crypto there is a real benefit in working with multibyte integers, since carries propagate forward.
I saw one working group designed a protocol such that the serialiazation format was equivalent to how gcc on 64 bit, intel linux machineas would pack C structures.
This was of course never mentioned in the official description, as it was supposed to be architecture/compiler/machine neutral, but I kept wondering why the odd padding here and there, and then it dawned on me.
So if someone was going to play fast and loose, they could just simply cast packet data directly to a C struct. If anyone happens to have a different, compiler / architecture / etc they'd have to jump through hoops a bit inserting seemingly awkward pad bytes and do le-to-be conversions.
