In addition to the Peer-ID/DATA_V2 protocol change proposal,
here are a couple more proposed extensions for AEAD mode and
Compression V2 that we can discuss at the upcoming Munich
hackathon.
James
OpenVPN Protocol extensions
1. DATA_V2 opcode with 24-bit peer ID
2. AEAD mode
To support AEAD crypto modes such as AES-GCM, some protocol
changes are in order. AES-GCM, for example, requires a 12
byte unique nonce for every packet. I would propose that 4
bytes be taken from the Packet ID which increments for every
packet and therefore provides uniqueness. The remaining 8
bytes would be derived from the random key material that would
normally be used to key the HMAC key. This is possible since
AEAD modes use a combined key for encryption and integrity
checking, therefore the random key material for HMAC is
unused and can be repurposed as an AEAD nonce source. The 8
byte nonce component derived from the HMAC keying material
would remain constant for a given Key State. Only the 4 byte
Packet ID would increment for each packet. Because AEAD
encryption can be compromised if the nonce ever repeats for
a given key, the implementation MUST disable encryption
for a key if the 32-bit packet ID wraps. In practical usage,
renegotiation usually preempts wrapping, so the
disable-encryption-on-wrap feature is a failsafe.
AEAD Nonce:
[ Packet ID ] [ HMAC keying material ]
[ 4 bytes ] [ 8 bytes ]
[ AEAD nonce total: 12 bytes ]
TLS wire protocol:
[ DATA_V2 opcode ] [ Packet ID ] [ AEAD Auth tag ] [ ciphertext ]
[ 4 bytes ] [ 4 bytes ] [ 16 bytes ]
Static Key wire protocol:
[ DATA_V2 opcode ] [ Packet ID ] [ Nonce tail (random) ] [ AEAD Auth tag
] [ ciphertext ]
[ AEAD nonce ]
[ 4 bytes ] [ 8 bytes ] [ 4 bytes ] [ 16 bytes ]
Note that because the HMAC keying material used to derive the
last 8 bytes of the AEAD nonce is negotiated once per key
as part of the control channel handshake, we can omit it from the
data channel packets, thereby saving 8 bytes per packet. So
only the 4-byte Packet ID component of the nonce must be
transmitted with every packet.
Also note that that the TLS wire protocol overhead is only 24
bytes, including the new 4 byte DATA_V2 opcode that includes
the Peer ID! Compare that with traditional AES-CBC mode and
DATA_V1 opcode: 1 (DATA_V1 opcode) + 20 (HMAC-SHA1 hash)
+ 8 (IV) + 4 (Packet ID) + 1-8 (PKCS#7 padding) = 34-41 bytes.
3. Compression V2
I have observed that compression in many cases, even when
enabled, often does not produce packet size reduction
because much of the packet data typically generated by web
sessions is already compressed. Further, the single byte that
precedes the packet and indicates whether or not compression
occurred has the unfortunate side effect of misaligning the IP
packet in cases where compression did not occur. To remedy this,
I propose a Compression V2 header that is optimized for the
case where compression does not occur.
a. No compression occurred and first byte of IP/Ethernet packet
is NOT 0x50 (0 bytes of overhead and maintains alignment):
[ uncompressed IP/Ethernet packet ]
b. No compression occurred and first byte of IP/Ethernet packet
is 0x50 (2 bytes of overhead but unlikely since no known
IP packet can begin with 0x50):
[ 0x50 ] [ 0x00 ] [ uncompressed IP/Ethernet packet ]
c. Compression occurred (2 bytes of overhead):
[ 0x50 ] [ compression Alg ID ] [ compressed IP/Ethernet packet ]
Compression Alg ID is one-byte algorithm identifier
for LZ4 (0x1), LZO (0x2), or Snappy (0x3).
This approach has several beneficial effects:
1. In the common case where compression does not occur, no
compression op is required, therefore there is zero overhead.
2. When compression does not occur, the IP/Ethernet packet
alignment is retained.
3. This technique does not require any byte swapping with
the tail of the packet which can potentially incur an
expensive cache miss.
