Draft: draft-ietf-quic-transport

Commentary: We do n't want to prohibit the use of long headers in other versions - in case they want to share the stateless reset design , but there is no sense in sending long headers . 
 While I agree with the issue , the PR says that other versions might want to reset with a long header and therefore the receiver must inspect long headers anyway . I can see this , but given that , I think it is pointless to require the current version to only send resets for short headers . A general advice ought to suffice since the MUST is not enforceable anyway . 
 The requirement exists to protect those packets from detection . 
 Please do n't close issues until AFTER consensus is declared ( not just called ) . 
 I suspect  was confused because this issue was tagged has - proposal 15 days ago . 
 Right . The trigger is , not . 
 But it 's understandable Martin would have assumed this was one of the issues that was sent out in the batch of issues a week and a half ago , given this has been tagged with has - proposal for 15 days .
Paragraph (version A):
An endpoint that receives a packet where removal of packet protection
fails MUST check the last 16 bytes of that packet.  If the last 16
bytes of the packet are identical to a stateless reset token
corresponding to a packet that was recently sent, the endpoint MUST
NOT send any further packets; all state for the connection can then
be discarded.
Paragraph (version A):
An endpoint MAY send a stateless reset in response to a packet with a
long header.  This would not be effective if the stateless reset
token was not yet available to a peer.  In this QUIC version, packets
with a long header are only used during connection establishment.
Because the stateless reset token is not available until connection
establishment is complete or near completion, ignoring an unknown
packet with a long header might be more effective.
Paragraph (version B):
Endpoints MUST send stateless reset packets formatted as a packet
with a short header.  However, endpoints MUST treat any packet ending
in a valid stateless reset token as a stateless reset, as other QUIC
versions might allow the use of a long header.
Paragraph (version B):
An endpoint MAY send a stateless reset in response to a packet with a
long header.  Sending a stateless reset is not effective prior to the
stateless reset token being available to a peer.  In this QUIC
version, packets with a long header are only used during connection
establishment.  Because the stateless reset token is not available
until connection establishment is complete or near completion,
ignoring an unknown packet with a long header might be as effective
than sending a stateless reset.
Paragraph (version A):
An endpoint detects a potential stateless reset when a incoming
packet with a short header either cannot be associated with a
connection, cannot be decrypted, or is marked as a duplicate packet.
The endpoint then compares the last 16 bytes of the packet with the
Stateless Reset Token provided by its peer, either in a
NEW_CONNECTION_ID frame or the server's transport parameters.  If
these values are identical, the endpoint MUST enter the draining
period and not send any further packets on this connection.  If the
comparison fails, the packet can be discarded.
Paragraph (version B):
An endpoint detects a potential stateless reset when an incoming
packet either cannot be associated with a connection, cannot be
decrypted, or is marked as a duplicate packet.  The endpoint MUST
then compare the last 16 bytes of the packet with all Stateless Reset
Tokens that are associated with connection IDs that are currently in
use.  This includes Stateless Reset Tokens from NEW_CONNECTION_ID
frames and the server's transport parameters.  An endpoint MUST NOT
check for any Stateless Reset Tokens associated with connection IDs
it has not used or for connection IDs that have been retired.
Paragraph (version B):
If the last 16 bytes of the packet values are identical to a
Stateless Reset Token, the endpoint MUST enter the draining period
and not send any further packets on this connection.  If the
comparison fails, the packet can be discarded.
Paragraph (version A):
Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once.  This method for
choosing the Stateless Reset Token means that the combination of
connection ID and static key cannot occur for another connection.  A
denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the
same static key (see reset-oracle).  A connection ID from a
connection that is reset by revealing the Stateless Reset Token
cannot be reused for new connections at nodes that share a static
key.
Paragraph (version B):
Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once.  This method for
choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the
same static key (see reset-oracle).  A connection ID from a
connection that is reset by revealing the Stateless Reset Token MUST
NOT be reused for new connections at nodes that share a static key.