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

Allow reuse of stateless reset tokens #2733

Merged
merged 6 commits into from Jun 4, 2019
Merged

Allow reuse of stateless reset tokens #2733

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
f434be2
Allow reuse of stateless reset tokens
martinthomson May 21, 2019
a5bcc0b
Fixup of reset-oracle links
martinthomson May 22, 2019
6d614fa
Edit for clarity
martinthomson May 22, 2019
5201e2e
More editorial hacking; this is complex
martinthomson May 22, 2019
b645d79
Try again
martinthomson May 22, 2019
7fdaf76
Update draft-ietf-quic-transport.md
janaiyengar Jun 4, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 6 additions & 5 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2478,11 +2478,12 @@ connections at nodes that share a static key.

The same Stateless Reset Token MAY be used for multiple connection IDs on the
same connection. An endpoint that reuses a Stateless Reset Token MUST ensure
that packets that use connection IDs associated with the reused value are
attributed to the active connection, even when the connection ID has been
retired. Otherwise, an attacker might be able to send a packet with a retired
connection ID and cause the endpoint to produce a Stateless Reset that it can
use to disrupt the connection; just as with the attacks in {{reset-oracle}}.
that packets with Destination Connection ID field values that correspond to a
reused Stateless Reset Token are attributed to the same connection, even when
the connection ID has been retired. Otherwise, an attacker might be able to
send a packet with a retired connection ID and cause the endpoint to produce a
Stateless Reset that it can use to disrupt the connection; just as with the
attacks in {{reset-oracle}}.

Note that Stateless Reset packets do not have any cryptographic protection.
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand this text. I can see the issuer of the reset can and should coordinate with load balancers, but the text reads as if the sender is responsible for the receiver matching up the connection ID, or that an active connection should be matched sender side when the reset is transmitted to cancel an unknown connection, which by definition isn't possible. In part it is unclear what is mean by connection ID since there are two kinds.

Copy link
Member

Choose a reason for hiding this comment

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

@mikkelfj can you clarify what this comment is in relation to?

Copy link
Member Author

Choose a reason for hiding this comment

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

I've tweaked the text (there was a grammatical error), but I think that this was related to the change. It was a minor editorial thing. It's really hard to get this right.

Copy link
Contributor

Choose a reason for hiding this comment

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

The text has been changed since I wrote the above, but largely:

An endpoint that reuses a Stateless Reset Token MUST ensure
that any connection ID associated with the reused value is correlated with to
the active connection, even when the connection ID has been retired.

It is not entirely clear what timeframe this pertains to. There is time where the an unknown packet is received and the connection is active from the peers perspective but no longer used from the receivers perspective. And there is the time where the token is issued during connection establishment or path migration. The latter is the intent, but it is not easy to read.

It could perhaps be formulated like

A Stateless Reset Token MUST be unique to a single connection. The same token MAY be reissued for different Connection ID's on the same connection when it can be guaranteed that they all route to the same endpoint for the duration of the connection even after a Connection ID has been retired.

Copy link
Member Author

Choose a reason for hiding this comment

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

That doesn't quite work because it is OK to forget a connection ID if the associated stateless reset token is no longer in use. Maybe I need to try again.


Expand Down