Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Move stateless reset token to the end #842

Merged
merged 6 commits into from
Oct 12, 2017
Merged

Move stateless reset token to the end #842

Changes from 2 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
83e2881
Move stateless reset token to the end
martinthomson Oct 9, 2017
53466f0
Define the packet type more precisely
martinthomson Oct 9, 2017
b67d605
Define what termination means for stateless reset
martinthomson Oct 9, 2017
d63e582
Larger packet number encodings make identification easier
martinthomson Oct 10, 2017
0484dea
Clients can dump state on stateless reset
martinthomson Oct 10, 2017
d167ca1
Corrections suggested by @ianswett
martinthomson Oct 11, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1576,9 +1576,9 @@ The Packet Number field is set to a randomized value. The server SHOULD send a
packet with a short header and a type of 0x01. This produces the shortest
possible packet number encoding, which minimizes the perceived gap between the
last packet that the server sent and this packet. A server MAY use a different
short header type, indicating a different packet number length, but this allows
for the message to be identified as a stateless reset more easily using
heuristics.
short header type, indicating a different packet number length, but a longer
packet number encoding might allow this message to be identified as a stateless
reset more easily using heuristics.

After the first short header octet and optional connection ID, the server
includes the value of the Stateless Reset Token that it included in its
Expand All @@ -1604,10 +1604,9 @@ A client detects a potential stateless reset when a packet with a short header
either cannot be decrypted or is marked as a potential duplicate. The client
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I'd go with "is marked as a duplicate packet."

then performs a constant-time comparison of the last 16 octets of the packet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to mention it's constant time?

with the Stateless Reset Token provided by the server in its transport
parameters. If this comparison is successful, the connection MUST be terminated
immediately, with the client entering the draining period. The client MUST NOT
send any further packets on this connection after receiving a stateless
reset. If the comparison is unsuccessful, the packet can be discarded.
parameters. If this comparison is successful, the client MUST discard all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of successful, how about "If they are identical" ?

connection state and not send any further packets on this connection. If the
comparison is unsuccessful, the packet can be discarded.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is unsuccessful => fails?



#### Calculating a Stateless Reset Token
Expand Down