Maximum Path ID value

[gloinul]

Sectionm 5.2: "Section 19 of [QUIC-TRANSPORT] encodes the Connection ID Sequence Number as a variable-length integer, allowing values up to 2^62-1; in this specification, a range of less than 2^32-1 values MUST be used before updating the packet protection key"

I think this is unlikely to cause a real issue, but is sloppy writing. At no point in time may a sequence number n and its next wrapped value ( n+2^32) be protected by the same packet protection key. This is unlikely to ever happen due to AEAD limits of at least current ciphers. But I think it would be good to be formally correct here.

I will note that there is duplication of the imprecise requirement in the last paragraph of the seciton too: "Due to the way the nonce is constructed, endpoints MUST NOT use more than 2^32 Connection IDs without a key update."

[Yanmei-Liu]

I think we have consensus here to limit the upper bound of Path ID to 2^32-1 and avoid reuse of nonce here. I've updated the description in PR #292.

[mirjak]

Before I close this issue:

The text says:

the Path ID is an integer between 0 and 2^32 - 1 (inclusive).

Do we need normative language here? Also do we need to specify what to do if a larger path ID is sent? Can that even happen?

[MikeBishop]

32 bits is an odd boundary in this case. It's being sent in a varint, which means its size boundaries are at 62 bits, 30 bits, 14 bits, and 6 bits. I understand the rationale for the 2^32 cap due to the nonce, but that means we're spilling over into eight-byte representations without taking advantage of the eight-byte space.

I would suggest either:

• Cap the number of path IDs per connection to 2^30 -1 and never use the 62-bit representation
• Allow path IDs to go up to 2^62 - 1, but keep the requirement that key rotation must happen at most every 2^32-1 paths.

A larger path ID can definitely be sent in frames, so we should be sure there are normative requirements around it. (Several may be covered by existing requirements about larger Path IDs than have been permitted by the peer, however.)

[mirjak]

I don't really understand so much the point of cutting down to 2^30 -1. As its is a var int, you only use 8 byte if you would actually use the high path ID. So I don't see a reason for limiting it further.

[mirjak]

PR #394 add a normative requirement to the max value of initial_max_paths. there is already a normative requirement for the MAX_PATHS frame in the respectively frame section 7.7.

I believe we can close this issue when the PR is merged, otherwise please speak up!