- 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.
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
