Draft: draft-ietf-quic-transport

Commentary: Question for reviewers : do you think it necessary to point out that this distinction does n't need to be hidden from other entities ? That 's almost obvious based on the way that this results in different behaviour from servers , but should it be written down ? 
 We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable , but an error in a Retry token is fatal . I do n't see why this ca n't be MUST . If we make it " MUST " , then we can rely on this property in the design . 
 Agreed , that 'd be a useful property to rely on . 
 Does that property need to hold if there are bit flips in the token ? If you ’re encrypting the token , this would be easy to ensure : put the distinguishing bit under crypto cover . If you ’re using a map lookup , you ’ll probably have to work a little bit harder . 
 Please ignore my last post , I mixed up Retry packets and Initials . Tokens in the client ’s Initial are part of the AAD , so we do n’t have to worry about bit flips . 
 One suggestion to change a normative to a MUST , on existing text . Some small suggestions , but LG
Paragraph (version B):
A token sent in a NEW_TOKEN frames or a Retry packet MUST be
constructed in a way that allows the server to identity how it was
provided to a client.  These tokens are carried in the same field,
but require different handling from servers.
Paragraph (version A):
A token SHOULD be constructed in a way that allows the server to
distinguish it from tokens that are sent in Retry packets as they are
carried in the same field.
Paragraph (version A):
The token MUST NOT include information that would allow it to be
linked by an on-path observer to the connection on which it was
issued.  For example, it cannot include the connection ID or
addressing information unless the values are encrypted.
Paragraph (version B):
A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an on-path observer to the connection on
which it was issued, unless the values are encrypted.  For example,
it cannot include the previous connection ID or addressing
information.  Information that allows the server to distinguish
between tokens from Retry and NEW_TOKEN MAY be accessible to entities
other than the server.
Paragraph (version A):
A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame.  A token obtained
in a Retry packet MUST be used immediately during the connection
attempt and cannot be used in subsequent connection attempts.
Paragraph (version A):
A client SHOULD NOT reuse a token in different connections.  Reusing
a token allows connections to be linked by entities on the network
path; see migration-linkability.  A client MUST NOT reuse a token if
it believes that its point of network attachment has changed since
the token was last used; that is, if there is a change in its local
IP address or network interface.  A client needs to start the
connection process over if there is any change in its local address
prior to completing the handshake.
Paragraph (version B):
A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame.  In comparison, a
token obtained in a Retry packet MUST be used immediately during the
connection attempt and cannot be used in subsequent connection
attempts.
Paragraph (version B):
A client SHOULD NOT reuse a NEW_TOKEN token for different connection
attempts.  Reusing a token allows connections to be linked by
entities on the network path; see migration-linkability.  A client
MUST NOT reuse a token if it believes that its point of network
attachment has changed since the token was last used; that is, if
there is a change in its local IP address or network interface.  A
client needs to start the connection process over if there is any
change in its local address prior to completing the handshake.