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

Remove requirement for reciprocal connection ID change #2386

Merged
merged 3 commits into from Mar 11, 2019
Merged

Remove requirement for reciprocal connection ID change #2386

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
63e1803
Remove requirement for reciprocal connection ID change
martinthomson Jan 30, 2019
23014c8
remove redundant word
ianswett Jan 30, 2019
48002d0
Editorial changes
martinthomson Feb 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
22 changes: 7 additions & 15 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2108,21 +2108,13 @@ genuine migrations. Changing port number can cause a peer to reset its
congestion state (see {{migration-cc}}), so the port SHOULD only be changed
infrequently.

Endpoints that use connection IDs with length greater than zero could have their
activity correlated if their peers keep using the same destination connection ID
after migration. Endpoints that receive packets with a previously unused
Destination Connection ID SHOULD change to sending packets with a connection ID
that has not been used on any other network path. The goal here is to ensure
that packets sent on different paths cannot be correlated. To fulfill this
privacy requirement, endpoints that initiate migration and use connection IDs
with length greater than zero SHOULD provide their peers with new connection IDs
before migration.

Caution:

: If both endpoints change connection ID in response to seeing a change in
connection ID from their peer, then this can trigger an infinite sequence of
changes.
Endpoints that supply connection IDs with length greater than zero could have
their activity correlated if their peers keep using the same destination
connection ID after migration. To ensure that packets sent on different paths
cannot be correlated, endpoints SHOULD provide with new connection IDs before
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
cannot be correlated, endpoints SHOULD provide with new connection IDs before
cannot be correlated, endpoints SHOULD supply new connection IDs to their peers before the peers migrate.

And drop the rest of this paragraph, I don't think it adds anything.

Copy link
Member Author

Choose a reason for hiding this comment

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

#2414 might be the better PR to review then. I've removed the duplicated text.

Copy link
Contributor

Choose a reason for hiding this comment

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

I like the text there better, I've left a comment as well. Do you want to close this PR off in favor of that one?

Copy link
Member Author

Choose a reason for hiding this comment

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

This should close when that does. Closing this might have side-effects.

peers migrate. To fulfill this privacy requirement, endpoints that initiate
migration and use connection IDs with length greater than zero SHOULD provide
their peers with new connection IDs before migration.


## Server's Preferred Address {#preferred-address}
Expand Down