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.

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

switch to using 3xmaxPTO between key updates #257

Merged
merged 4 commits into from
Jul 10, 2023
Merged
Changes from 3 commits
Commits
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
35 changes: 10 additions & 25 deletions draft-ietf-quic-multipath.md
Original file line number Diff line number Diff line change
Expand Up @@ -651,32 +651,17 @@ The general principles of key update are not changed in this
specification. Following QUIC version 1, the Key Phase bit is used to
indicate which packet protection keys are used to protect the packet.
The Key Phase bit is toggled to signal each subsequent key update.

Because of network delays, packets protected with the older key might
arrive later than the packets protected with the new key. Therefore,
the endpoint needs to retain old packet keys to allow these delayed
packets to be processed and it must distinguish between the new key
and the old key. In QUIC version 1, this is done using packet numbers
so that the rule is made simple: Use the older key if packet number is
lower than any packet number frame the current key phase.

When using multiple packet number spaces on different paths,
some care is needed when initiating the Key Update process,
as different paths use different packet number spaces but share
a single key. When a key update is initiated on one path, packets sent to
another path needs to know when the transition is complete. Otherwise,
it is possible that the other paths send packets with the old keys,
but skip sending any packets in the current key phase and directly
jump to sending packet in the next key phase. When that happens,
as the endpoint can only retain two sets of packet protection keys
with the 1-bit Key Phase bit, the other paths cannot distinguish
which key should be used to decode received packets, which results in
a key rotation synchronization problem.

To address such a synchronization issue, if key update is
initialized on one path, the sender SHOULD send at least one packet
with the new key on all active paths. Further, an endpoint MUST NOT
initiate a subsequent key update until a packet with the current key
has been acknowledged on each path.
arrive later than the packets protected with the new key, however receivers
can solely rely on the Key Phase bit to determine the corresponding packet
protection key, assuming that there is sufficient interval between two
consecutive key updates ({{Section 6.5 of QUIC-TLS}}).

When this specification is used, endpoints SHOULD wait for at least three times
the largest PTO among all the paths before initiating a new key update
after receiving an acknowledgement that confirms receipt of the previous key
update.
kazuho marked this conversation as resolved.
Show resolved Hide resolved

Following {{Section 5.4 of QUIC-TLS}}, the Key Phase bit is protected,
so sending multiple packets with Key Phase bit flipping at the same time
Expand Down