Draft: draft-ietf-quic-load-balancers

Commentary: After thinking it through , various XOR schemes were extremely vulnerable to manipulation , so I went with a brute force approach . 
 The server now needs to include this field . For the no - shared state service , we just need language that the Retry service needs to encode enough information validate the packet  as well and drop if it fails validation . If it does , the server MUST use the packet DCID in the retrysourceconnection_id TP . For the shared state service , the retry source connection ID is going to have to be in the token . We might be able to compress this by xoring some fields ; I 'll think about it .
The service must also communicate the source connection ID of the
Retry packet to the server so that it can include it in a transport
parameter for client verification.
Opaque Data: This data MUST contain encrypted information that allows
the retry service to validate the client's IP address, in accordance
with the QUIC specification.  It MUST also encode a secure hash of
the original destination connection ID field to verify that this
field has not been edited.
Upon receipt of an Initial packet with a token that begins with '0',
the retry service MUST validate the token in accordance with the QUIC
specification.  It must also verify that the secure hash of the
Connect ID is correct.  If incorrect, the token is invalid.
In active mode, the service MUST issue Retry packets for all Client
initial packets that contain no token, or a token that has the first
bit set to '1'.  It MUST NOT forward the packet to the server.  The
service MUST validate all tokens with the first bit set to '0'.  If
successful, the service MUST forward the packet with the token
intact.  If unsuccessful, it MUST drop the packet.
RSCIL: The retry source connection ID length.
Retry Source Connection ID: This also in cleartext and authenticated
later.
Opaque Data: This data MUST contain encrypted information that allows
the retry service to validate the client's IP address, in accordance
with the QUIC specification.  It MUST also provide a
cryptographically secure means to validate the integrity of the
entire token.
Upon receipt of an Initial packet with a token that begins with '0',
the retry service MUST validate the token in accordance with the QUIC
specification.
In active mode, the service MUST issue Retry packets for all Client
initial packets that contain no token, or a token that has the first
bit set to '1'.  It MUST NOT forward the packet to the server.  The
service MUST validate all tokens with the first bit set to '0'.  If
successful, the service MUST forward the packet with the token
intact.  If unsuccessful, it MUST drop the packet.  The Retry Service
MAY send an Initial Packet containing a CONNECTION_CLOSE frame with
the INVALID_TOKEN error code when dropping the packet.
If a server receives an Initial Packet with the first bit set to '1',
it could be from a server-generated NEW_TOKEN frame and should be
processed in accordance with the QUIC specification.  If a server
receives an Initial Packet with the first bit to '0', it is a Retry
token and the server MUST NOT attempt to validate it.  Instead, it
MUST assume the address is validated and MUST extract the Original
Destination Connection ID, assuming the format described in nss-
service-requirements.
If a server receives an Initial Packet with the first bit set to '1',
it could be from a server-generated NEW_TOKEN frame and should be
processed in accordance with the QUIC specification.  If a server
receives an Initial Packet with the first bit to '0', it is a Retry
token and the server MUST NOT attempt to validate it.  Instead, it
MUST assume the address is validated and MUST extract the Original
Destination Connection ID and Retry Source Connection ID, assuming
the format described in nss-service-requirements.
Original Destination Connection ID: This is copied from the field in
the client Initial packet.
RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN
frames MUST set this field to zero.
Original Destination Connection ID: The server or Retry Service
copies this from the field in the client Initial packet.
Retry Source Connection ID: The server or Retry service copies this
from the Source Connection ID of the Retry packet.
A server MUST NOT send a Retry packet in response to an Initial
packet that contains a retry token.
After decrypting the token, the server uses the corresponding fields
to populate the original_destination_connection_id transport
parameter, with a length equal to ODCIL, and the
retry_source_connection_id transport parameter, with length equal to
RSCIL.
As discussed in QUIC-TRANSPORT, a server MUST NOT send a Retry packet
in response to an Initial packet that contains a retry token.