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

Symmetric connection IDs #1151

Merged
merged 18 commits into from Mar 13, 2018
Merged

Symmetric connection IDs #1151

Changes from 1 commit
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
8ecd955
wip
martinthomson Mar 2, 2018
d55ddf8
Symmetric connection IDs
martinthomson Mar 2, 2018
d925ba0
Address review comments, closes #1052
martinthomson Mar 5, 2018
d8a59b3
Review-based tweakin'
martinthomson Mar 5, 2018
b6db6fa
Closes #1146 too
martinthomson Mar 5, 2018
5343125
Closes #821 too
martinthomson Mar 6, 2018
acf8bfe
Let's not flip around too often unnecessarily
martinthomson Mar 6, 2018
febac4d
Fix length labels
martinthomson Mar 6, 2018
436786f
-n
martinthomson Mar 6, 2018
2764c5c
Reducing minimum connection ID length to 4 octets
martinthomson Mar 6, 2018
7bfa8ab
Sums iz haard
martinthomson Mar 6, 2018
d7a18a0
Moar bad numerz
martinthomson Mar 8, 2018
dc887e8
My sed-fu is lacking
martinthomson Mar 8, 2018
c6c06e5
For @siyengar/@ianswett regarding connection ID construction
martinthomson Mar 8, 2018
3ea70b9
Some review-related changes and polish
martinthomson Mar 9, 2018
4e837b2
Fixups
martinthomson Mar 12, 2018
0d51024
Small tweaks regarding the change to dcid
martinthomson Mar 13, 2018
9d1512f
Jana's improvements
martinthomson Mar 13, 2018
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
2 changes: 1 addition & 1 deletion draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -779,7 +779,7 @@ value of the Source Connection ID that they receive.

During the handshake, an endpoint might receive multiple packets with the long
header, and thus be given multiple opportunities to update the Destination
Connection ID it sends. An client MUST only change the value it sends in the
Connection ID it sends. A client MUST only change the value it sends in the
Destination Connection ID field in response to the first packet of each type
(Retry, or Handshake) that it receives; a server MUST only change its value
Copy link
Contributor

Choose a reason for hiding this comment

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

I think an algorithm based on packet number might be more robust than specifying the first packet of each type? Largest packet number wins?

Also, I would say the server MUST set it's value based on an Initial packet. Given there was no connection before, I wouldn't call it a change of connection ID.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1. I can't reason about packet type changes easily, but largest packet number seems robust.

Copy link
Contributor

Choose a reason for hiding this comment

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

There is a discussion on list about version negotiation attacks by man-on-the-side. One proposed solution was to queue some packets and wait for the best outcome. I'm not so sure what is best, but it overlaps with the considerations in the above text and comments.

Copy link
Member Author

Choose a reason for hiding this comment

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

Largest packet number fails for the simple reason that it might allow for multiple changes. Lowest packet number works better. And that's all I'm looking for. Latching is what we are looking for, not a continuous sequence of changes.

Also, I added a note to ignore packets with different Source Connection ID values. That deals neatly with the problem where two server instances both attempt to start a connection with you as a result of you sending multiple Initial packets.

based on an Initial packet. This avoids problems that might arise from
Expand Down