Draft: draft-ietf-quic-load-balancers

Commentary: the server no longer has discretion to lengthen the CID . Also , the algorithms are more aligned so there has to be less unique text associated with each algorithm . 
 In any given deployment , the server use length should be consistent . The load balancer does n't strictly need to know what it is , but obviously not doing this will lead to observable correlations . 
 As we 've generalized the concept of a nonce , we should abolish the concept of " server use " and make it all a nonce . If the servers need to use the same length to prevent linkability , best to make it part of the configuration .
A load balancer that sees a connection ID with config rotation bits
set to '11' MUST revert to 5-tuple routing.
A load balancer that sees a connection ID with config rotation bits
set to '11' MUST revert to 5-tuple routing.  These connection IDs may
be of any length; however, see cid-entropy for limits on this length.
Each configuration specifies the length of the Server ID and Nonce
fields, with limits defined for each algorithm.
The Nonce is selected by the server when it generates a CID.  As the
name implies, a server MUST use a nonce no more than once when
generating a CID for a given server ID and unique set of
configuration parameters.  Limits on the length of the nonce are
different for each algorithm.
The First Octet, Server ID, and Nonce comprise the minimum length
Connection ID for any given algorithm.  The load balancer need not
know the full connection ID length to successfully process a packet,
given that it is of minimum size.
The For Server Use field has any value and length chosen by the
server, within the connection ID length limits in the operative QUIC
version.  It SHOULD appear random and SHOULD NOT link two connection
IDs to the same connection, or indicate they originate from the same
server.
Each configuration specifies the length of the Server ID and Nonce
fields, with limits defined for each algorithm.  When using a given
configuration, the server MUST generate CIDs of length equal to the
lengths of these three fields.
The Nonce is selected by the server when it generates a CID.  As the
name implies, a server MUST use a nonce no more than once when
generating a CID for a given server ID and unique set of
configuration parameters.
The nonce length MUST be at least 4 octets.  Additional limits on its
length are different for each algorithm.  See cid-entropy for limits
on nonce generation.
As QUIC version 1 limits connection IDs to 20 octets, the server ID
and nonce lengths MUST sum to 19 octets or less.
For static SID allocation, the server ID length is limited to 16
octets.  The nonce length MUST be zero.
On each incoming packet, the load balancer extracts consecutive
octets, beginning with the second octet.  These bytes represent the
server ID.
The server chooses how many octets to reserve for its own use, which
MUST be at least one octet.
When a server needs a new connection ID, it encodes one of its
assigned server IDs in consecutive octets beginning with the second.
See cid-format.
On each incoming packet, the load balancer extracts consecutive
octets, beginning with the second octet.  These bytes represent the
server ID.  It ignores the nonce.
When a server needs a new connection ID, it encodes one of its
assigned server IDs in consecutive octets beginning with the second
and chooses a nonce.  This nonce MUST appear to be random (see cid-
entropy).
The nonce length MUST be no fewer than 4 and no more than 16 octets.
The server ID length and nonce length MUST sum to 19 or fewer octets,
and SHOULD sum to 15 or fewer octets to allow space for server use.
The nonce length MUST be no fewer than 4 octets.
The configuration agent also selects an 16-octet AES-ECB key to use
for connection ID decryption.
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.
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.  See cid-entropy for nonce generation
considerations.
The server ID length MUST be no more than 12 octets.  The server ID
length and nonce length MUST sum to exactly 16 octets.
The server ID length MUST be no more than 12 octets.  The nonce and
server ID MUST sum to at least 16 octets.
The decrypted plaintext contains the server id and opaque server data
in that order.  The load balancer uses the server ID octets for
routing.
The server encrypts both its server ID and a nonce in 16-octet block
with the configured AES-ECB key.
The first octets of the plaintext contains the server id.
The server encrypts both its server ID and enough octets in a nonce
to form a 16-octet block using the configured AES-ECB key.  Note that
any remaining octets in the nonce are transmitted as plaintext, and
should consider the constraints in cid-entropy.
All algorithm configurations can have a server ID length, nonce
length, and key.  However, for Plaintext CID, the key is not used and
the nonce length is always zero.  For Block Cipher CID, the nonce
length is directly computed from the server ID length.
All algorithm configurations can have a server ID length, nonce
length, and key.  However, for Plaintext CID, there is no key.
If a server ever reuses a nonce in generating a CID for a given
configuration, it risks exposing sensitive information.  Given the
same server ID, the CID will be identical (aside from a possible
difference in the first octet).  This can risk exposure of the QUIC-
LB key.  If two clients receive the same connection ID, they also
have each other's stateless reset token unless that key has changed
in the interim.
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.
Both the Plaintext CID and Block Cipher CID algorithms send parts of
their nonce in plaintext.  Servers MUST generate nonces so that the
plaintext portion appears to be random.  Observable correlations
between plaintext nonces would provide trivial linkability between
individual connections, rather than just to a common server.
For any algorithm, 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.
When sizing a nonce that is to be randomly generated, the
configuration agent SHOULD consider that a server generating a N-bit
nonce will create a duplicate about every 2^(N/2) attempts, and
therefore compare the expected rate at which servers will generate
CIDs with the lifetime of a configuration.