- add protocol-flag aead-packet-format-v2 This signals the client to switch to the new data channel format.

And finally have the data channel format. Since this format is negotiated like the cipher, there is no need to use another opcode if keep the peer id to just 24 bit. But we might want to extend the format to have it 8 byte aligned to also allow peer-id to be extended in the future.

I'd at least consider to not send the upper 32 bits of the counter over the wire. With some simple arithmetic you can detect the counter overflow and keep the high bits internal to the application. I'd expect such per-packet arithmetic to be much cheaper than transmitting 4 bytes extra for each packet.

If you take that approach, you would not even need to change the wire format.

Even more, you might not even have to negotiate the option with the peer, because the peer will initiate a renegotiation after 0xFF000000 packets if it doesn't support the "implicit long PID". New peers will postpone the reneg to 0xFF00000000000000 packets.

Even as nice as that sounds, I am not super convinced that we should be the "odd protocol" here that takes a different approach than all other protocol. All other protocols that I looked at, rather use longer IV instead of doing some hidden counter that is not transmitted.

So I would rather err on the safe side here and go for a 8 byte IV instead.


Openvpn-devel mailing list

Reply via email to