Draft: draft-ietf-quic-load-balancers

Commentary: Make sure each algorithm always provides 2 - 3 octets for server use . The current SID limits do n't do that .
The configuration agent selects a length for the server ID encoding.
This length MUST have enough entropy to have a different code point
for each server.
The configuration agent selects a length for the server ID encoding.
This length MUST have enough entropy to have a different code point
for each server.  The length MUST be no more than 15 octets to
provide sufficient entropy for server use.
The configuration agent also selects a nonce length and an 16-octet
AES-ECB key to use for connection ID decryption.  The nonce length
MUST be at least 8 octets and no more than 16 octets.  The nonce
length and server ID length MUST sum to 19 or fewer octets.
The configuration agent also selects a nonce length and an 16-octet
AES-ECB key to use for connection ID decryption.  The nonce length
MUST be at least 8 octets and no more than 16 octets.  The nonce
length and server ID length MUST sum to 19 or fewer octets, but
SHOULD sum to 15 or fewer to allow space for server use.
They server ID length MUST be no more than 16 octets and SHOULD be no
more than 12 octets, to provide servers adequate space to encode
their own opaque data.
The server ID length MUST be no more than 12 octets, to provide
adequate entropy in the encrypted block.
When generating a routable connection ID, the server MUST choose a
connection ID length between 17 and 20 octets.  The server writes its
provided server ID into the server ID octets and arbitrary bits into
the remaining bits.  These arbitrary bits MAY encode additional
information, and MUST differ between connection IDs.  Bits in the
eighteenth, nineteenth, and twentieth octets SHOULD appear
essentially random to observers.  The first octet is reserved as
described in first-octet.
When generating a routable connection ID, the server MUST choose a
connection ID length between 17 and 20 octets.  The server writes its
provided server ID into the server ID octets and arbitrary bits into
the remaining bits.  These arbitrary bits MAY encode additional
information, and MUST differ between connection IDs.  The encrypted
arbitrary bits MUST be unique for each CID the server generates; the
easiest way to do so is to start the nonce at zero and simply
increment by one for each CID.
Bits in the eighteenth, nineteenth, and twentieth octets SHOULD
appear essentially random to observers.  The first octet is reserved
as described in first-octet.
The Stream Cipher and Block Cipher algorithms need to generate
different cipher text for each generated Connection ID instance to
protect the Server ID.  To do so, at least four octets of the Block
Cipher CID and at least eight octets of the Stream Cipher CID are
reserved for a nonce that, if used only once, will result in unique
cipher text for each Connection ID.
If servers simply increment the nonce by one with each generated
connection ID, then it is safe to use the existing keys until any
server's nonce counter exhausts the allocated space and rolls over to
zero.  Whether or not it implements this method, the server MUST NOT
reuse a nonce until it switches to a configuration with new keys.
Configuration agents SHOULD implement an out-of-band method to
discover when servers are in danger of exhausting their nonce space,
and SHOULD respond by issuing a new configuration.  A server that has
exhausted its nonces MUST either switch to a different configuration,
or if none exists, use the 4-tuple routing config rotation codepoint.
In order to protect against collisions, the 96 bit unique token
numbers should be generated using a cryptographically secure
pseudorandom number generator (CSPRNG), as specified in Appendix C.1
of the TLS 1.3 specificationRFC8446.  With proper random numbers, if
fewer than 2^40 tokens are generated with a single key, the risk of
collisions is lower than 0.001%.
In order to protect against collisions, the 96 bit unique token
numbers should be generated using a cryptographically secure
pseudorandom number generator (CSPRNG), as specified in Appendix C.1
of the TLS 1.3 specification RFC8446.  With proper random numbers, if
fewer than 2^40 tokens are generated with a single key, the risk of
collisions is lower than 0.001%.