Odd length headers and alignment

[John Huttley]

I think an extra byte would be a great idea.
We can use that in the future to implement a user space
IUnknown/O_PONIES  end to end negotiation

--John



On 8/12/2016 7:11 a.m., Jason A. Donenfeld wrote:
> Hey guys,
> 
> Wireguard data packets have a 1 byte type, a 4 byte index, an 8 byte
> nonce, the ciphertext, and then a 16 byte auth tag. Having 13 bytes in
> the beginning means that when we do in-place decryption, the plaintext
> winds up starting at an odd-byte, transferring misalignment down to
> the rest of the stack.
> 
> Now, in my testing on alignment-sensitive MIPS boxes, I've only had
> alignment exceptions with this regarding the first byte, which is the
> version number of the IP header. Since this is just a single byte, the
> alignment doesn't actually matter. But in practice, the compiler
> generates a 16-bit load instead of an 8-bit load, which sucks. I may
> be able to work around this though. Beyond that, I haven't actually
> observed exceptions from elsewhere in the stack regarding
> misalignment.
> 
> So, how much of a problem do you suppose this is? Would it be
> worthwhile to stick an _extra byte_ in the header, just to get even
> alignment? Or an extra three bytes to get 16-byte alignment? Or do you
> suppose this isn't really worth the bloat and MTU loss?
> 
> Just something to think about...
> 
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>