Draft: draft-ietf-quic-load-balancers

Commentary: I will probably delete the Stream Cipher algorithm entirely , but consider this an intermediate step . 
 Merging to enable the next round of edits
Upon receipt of a QUIC packet that is not of type Initial or 0-RTT,
the load balancer extracts as many of the earliest octets from the
destination connection ID as necessary to match the nonce length.
The server ID immediately follows.
Upon receipt of a QUIC packet, the load balancer extracts as many of
the earliest octets from the destination connection ID as necessary
to match the nonce length.  The server ID immediately follows.
Pass 2: The load balancer decrypts the nonce octets using 128-bit
AES Electronic Codebook (ECB) mode, much like QUIC header
protection, using the server-id intermediate as "nonce" for this
pass.  The server-id intermediate octets are zero-padded to 16
octets.  AES-ECB encrypts this padded server-id intermediate using
its key to generate a mask which it applies to the encrypted
nonce.  This provides the decrypted nonce value.
Pass 2: The load balancer decrypts the nonce octets using 128-bit
AES ECB mode, using the server-id intermediate as "nonce" for this
pass.  The server-id intermediate octets are zero-padded to 16
octets.  AES-ECB encrypts this padded server-id intermediate using
its key to generate a mask which it applies to the encrypted
nonce.  This provides the decrypted nonce value.
Pass 3: The load balancer decrypts the server ID using 128-bit AES
Electronic Codebook (ECB) mode, much like QUIC header protection.
The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts
this nonce using its key to generate a mask which it applies to
the intermediate server id.  This provides the dercypted server
ID.
This three pass algorithm is a simplified version of the FFX
algorithm.  It has the same connection ID length requirements as the
Stream Cipher CID Algorithm, with the additional property that each
encrypted nonce value depends on all server ID bits, and each
encrypted server ID bit depends on all nonce bits and all server ID
bits.  This mitigates attacks against stream ciphers in which
attackers simply flip encrypted server-ID bits.
Pass 3: The load balancer decrypts the server ID using 128-bit AES
ECB mode.  The nonce octets are zero-padded to 16 octets.  AES-ECB
encrypts this nonce using its key to generate a mask which it
applies to the intermediate server id.  This provides the
decrypted server ID.
This three-pass algorithm is a simplified version of the FFX
algorithm.  It has the same connection ID length requirements as the
Stream Cipher CID Algorithm, with the additional property that each
encrypted nonce value depends on all server ID bits, and each
encrypted server ID bit depends on all nonce bits and all server ID
bits.  This mitigates attacks against stream ciphers in which
attackers simply flip encrypted server-ID bits.
When generating a routable connection ID, the server writes arbitrary
bits into its nonce octets, and its provided server ID into the
server ID octets.  Servers MAY opt to have a longer connection ID
beyond the nonce and server ID.  The nonce and additional bits MAY
encode additional information, but SHOULD appear essentially random
to observers.
When generating a routable connection ID, the server writes arbitrary
bits into its nonce octets, and its provided server ID into the
server ID octets.  Servers MAY opt to have a longer connection ID
beyond the nonce and server ID.  The additional bits MAY encode
additional information, but SHOULD appear essentially random to
observers.
If the decrypted nonce bits increase monotonically, that guarantees
that nonces are not reused between connection IDs from the same
server.