Increase the size of connection ID #1052
Labels
-transport
design
An issue that affects the design of the protocol; resolution requires consensus.
has-consensus
An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Comments
martinthomson
added
design
Closed
martinthomson
added a commit
that referenced
this issue
Jan 31, 2018
This comes out of the discussion about what it takes to construct a sensible connection ID for NEW_CONNECTION_ID. Trying to cram sufficient routing state into a 64-bit identifier is tricky, especially since that information needs to be encrypted and probably also authenticated (at least a little). Using a block cipher would be ideal, but all the 64-bit ciphers are pretty bad, whereas all the 128-bit ones are both faster and more available. The extra 8 bits is for accounting. If you want to manage key rotation, a key identifier is helpful. Having extra space allows for that to be added without forcing the block cipher to protect less than 128 octets, which can be hard. The way that packet overheads are managed are different for long and short headers. In long headers, the overheads are much higher, but we don't send many of those, so it's not a big deal. For short headers, each endpoint sends a truncate_connection_id transport parameter which sets the length of the connection ID that will be used in short headers. Each endpoint sets their own limit and their peer has to follow this limit. Anywhere from 0 (no connection ID) to 17 (all of the connection ID) can be set. This also closes the discussion about whether connection ID is a number or not. With truncation, treating it as a number no longer makes sense. Note that this change shows the corresponding changes to the invariants draft on the assumption that it will need to be changed at the same time. Closes #1052, #821, #834, #833, #881.
martinthomson
added a commit
that referenced
this issue
Jan 31, 2018
This comes out of the discussion about what it takes to construct a sensible connection ID for NEW_CONNECTION_ID. Trying to cram sufficient routing state into a 64-bit identifier is tricky, especially since that information needs to be encrypted and probably also authenticated (at least a little). Using a block cipher would be ideal, but all the 64-bit ciphers are pretty bad, whereas all the 128-bit ones are both faster and more available. The extra 8 bits is for accounting. If you want to manage key rotation, a key identifier is helpful. Having extra space allows for that to be added without forcing the block cipher to protect less than 128 octets, which can be hard. The way that packet overheads are managed are different for long and short headers. In long headers, the overheads are much higher, but we don't send many of those, so it's not a big deal. For short headers, each endpoint sends a truncate_connection_id transport parameter which sets the length of the connection ID that will be used in short headers. Each endpoint sets their own limit and their peer has to follow this limit. Anywhere from 0 (no connection ID) to 17 (all of the connection ID) can be set. This also closes the discussion about whether connection ID is a number or not. With truncation, treating it as a number no longer makes sense. Note that this change shows the corresponding changes to the invariants draft on the assumption that it will need to be changed at the same time. Closes #1052, #821, #834, #833, #881.
martinthomson
added a commit
that referenced
this issue
Mar 5, 2018
mnot
added
the
has-consensus
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@vasilvv raised the question on the list.
64 bits seems like a lot until you start thinking about using cryptography, adding structured information to the identifier. When you consider collision probabilities, those 64 bits seem a little tight. Expanding connection ID to 128 bits, which might allow a little more space and enable simple encryption strategies.
On the other hand, a 64-bit overhead on every packet is already pretty costly. We spent a lot of effort on shaving other parts of the protocol overhead down, sometimes at a fair expense in complexity. Doubling the size would put the overhead equivalent to our AEAD.
The text was updated successfully, but these errors were encountered: