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

Change connection ID with Transport Parameters #1041

Closed
wants to merge 3 commits into from
Closed

Change connection ID with Transport Parameters #1041

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cec74a6
Change connection ID with Transport Parameters
ianswett Jan 9, 2018
44e4741
Fix trailing whitespace
ianswett Jan 9, 2018
7ba0b53
Martin's comments.
ianswett Jan 9, 2018
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
19 changes: 14 additions & 5 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -639,7 +639,7 @@ A Handshake packet uses long headers with a type value of 0x7D. It is
used to carry acknowledgments and cryptographic handshake messages from the
server and client.

The connection ID field in a Handshake packet contains a connection ID
The connection ID field in a Handshake packet may contain a connection ID
that is chosen by the server (see {{connection-id}}).

The first Handshake packet sent by a server contains a randomized packet number.
Expand Down Expand Up @@ -690,14 +690,16 @@ The client MUST choose a random connection ID and use it in Initial packets
({{packet-initial}}) and 0-RTT packets ({{packet-protected}}).

When the server receives a Initial packet and decides to proceed with the
handshake, it chooses a new value for the connection ID and sends that in a
Handshake packet ({{packet-handshake}}). The server MAY choose to use the value
that the client initially selects.
handshake, it MAY choose a new value for the connection ID and sends that in
the server_connection_id transport parameter
({{transport-parameter-definitions}}).

Once the client receives the connection ID that the server has chosen, it MUST
If the client receives a new connection ID that the server has chosen, it MUST
use it for all subsequent Handshake ({{packet-handshake}}) and 1-RTT
({{packet-protected}}) packets but not for 0-RTT packets ({{packet-protected}}).

The server MUST NOT switch to the new connection ID until has received a
packet containing the connection ID from the client. In particular, the
Copy link
Member

Choose a reason for hiding this comment

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

I think that it is easier to make the switch with the change to 1-RTT protected packets. Creating another mini-protocol here complicates things considerably. Outside of cases with packet loss (where you can't rely on the client being able to recover the transport parameters), the only real difference is that you are changing the connection ID sent with the client's second flight (it's set of Handshake packets).

Now, I agree that there is potentially some value in having the right markings on the client Handshake packets, but maybe the right answer here is to use NEW_CONNECTION_ID.

Copy link
Contributor Author

@ianswett ianswett Jan 9, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

One of the goals of this change is to allow connection ID changes to occur before switching to 1RTT, so only allowing the switch with 1RTT packets defeats half the point.

NEW_CONNECTION_ID wouldn't change the encryption level issues. And we'd have to allow it during the handshake, which we don't today. It seems more complex than this approach, but it's probably doable.

Copy link
Member

Choose a reason for hiding this comment

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

I agree with @ianswett, that the client should be the one that starts using the new connection ID first. Otherwise, you are back to one of the original problems of multiple clients on the same 4-tuple and it is impossible to determine which of them to deliver the newly received packet to.

Server's Version Negotiation ({{packet-version}}) and Retry ({{packet-retry}})
packets MUST use connection ID selected by the client.

Expand Down Expand Up @@ -1078,6 +1080,7 @@ language from Section 3 of {{!I-D.ietf-tls-tls13}}.
stateless_reset_token(6),
ack_delay_exponent(7),
initial_max_stream_id_uni(8),
server_connection_id(9),
(65535)
} TransportParameterId;

Expand Down Expand Up @@ -1215,6 +1218,11 @@ ack_delay_exponent (0x0007):
value is also used for ACK frames that are sent in Initial, Handshake, and
Retry packets. Values above 20 are invalid.

server_connection_id (0x0009):
: An 8 byte value to be used by the client on all future packets sent to the
server. The server will switch to sending this connection ID once it
receives a packet using the connection ID from the client.


### Values of Transport Parameters for 0-RTT {#zerortt-parameters}

Expand Down Expand Up @@ -3776,6 +3784,7 @@ The initial contents of this registry are shown in {{iana-tp-table}}.
| 0x0006 | stateless_reset_token | {{transport-parameter-definitions}} |
| 0x0007 | ack_delay_exponent | {{transport-parameter-definitions}} |
| 0x0008 | initial_max_stream_id_uni | {{transport-parameter-definitions}} |
| 0x0009 | server_connection_id | {{transport-parameter-definitions}} |
{: #iana-tp-table title="Initial QUIC Transport Parameters Entries"}


Expand Down