Draft: draft-ietf-quic-load-balancers

Commentary: Hopefully this will close the gap between what we want Retry Services to do and reality . 
 It would help the anti - DDoS properties if the Retry Service could receive explicit instructions about which QUIC versions the server might support . This provides a way to deploy new versions without having to upgrade the retry service software or hardware .
A retry service MUST forward all packets for a QUIC version it does
not understand.  Note that if servers support versions the retry
service does not, this may increase load on the servers.  However,
dropping these packets would introduce chokepoints to block
deployment of new QUIC versions.  Note that future versions of QUIC
might not have Retry packets, require different information in Retry,
or use different packet type indicators.
A configuration agent MUST distribute a list of QUIC versions the
Retry Service supports.  It MAY also distribute either an "Allow-
List" or a "Deny-List" of other QUIC versions.  It MUST NOT
distribute both an Allow-List and a Deny-List.
The Allow-List or Deny-List MUST NOT include any versions included
for Retry Service Support.
The Configuration Agent MUST provide a means for the entity that
controls the Retry Service to report its supported version(s) to the
configuration Agent.  If the entity has not reported this
information, it MUST NOT activate the Retry Service and the
configuration agent MUST NOT distribute configuration that activates
it.
The configuration agent MAY delete versions from the final supported
version list if policy does not require the Retry Service to operate
on those versions.
The configuration Agent MUST provide a means for the entities that
control servers behind the Retry Service to report either an Allow-
List or a Deny-List.
If all entities supply Allow-Lists, the consolidated list MUST be the
union of these sets.  If all entities supply Deny-Lists, the
consolidated list MUST be the intersection of these sets.
If entities provide a mixture of Allow-Lists and Deny-Lists, the
consolidated list MUST be a Deny-List that is the intersection of all
provided Deny-Lists and the inverses of all Allow-Lists.
If no entities that control servers have reported Allow-Lists or
Deny-Lists, the default is a Deny-List with the null set (i.e., all
unsupported versions will be admitted).  This preserves the future
extensibilty of QUIC.
A retry service MUST forward all packets for a QUIC version it does
not support that are not on a Deny-List or absent from an Allow-List.
Note that if servers support versions the retry service does not,
this may increase load on the servers.
Note that future versions of QUIC might not have Retry packets,
require different information in Retry, or use different packet type
indicators.
The configuration agent distributes a list of QUIC versions to be
served by the Retry Service.
See common-requirements.
The configuration agent generates and distributes a "token key", a
"token IV", a key sequence, and a list of QUIC versions the service
supports.  It must also inform the service if a NAT lies between the
service and the servers.
The configuration agent generates and distributes a "token key", a
"token IV", a key sequence, and the information described in common-
requirements.
A non-shared-state Retry Service need only be configured with the
QUIC versions it supports.  A shared-state Retry Service also needs
the token key, and to be aware if a NAT sits between it and the
servers.
A non-shared-state Retry Service need only be configured with the
QUIC versions it supports, and an Allow- or Deny-List.  A shared-
state Retry Service also needs the token key, and to be aware if a
NAT sits between it and the servers.