From e744ba17d4bc151e4f2dc4c596929f8154874d9a Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Thu, 6 Jul 2023 14:05:14 +0900 Subject: [PATCH 1/4] switch to using 3xmaxPTO between key updates --- draft-ietf-quic-multipath.md | 40 ++++++++++++++---------------------- 1 file changed, 15 insertions(+), 25 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index aff5d6a1..b9b1ecf3 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -651,32 +651,22 @@ 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. QUIC v1 defines two +ways of dealing with such packets arriving out of order. Receivers can either +retain up to three decryption keys and use the packet number in conjunction with +the Key Phase bit to determine the decryption key, or retain up to two +decryption keys and solely rely on the Key Phase bit +({{Section 6.5 of QUIC-TLS}}). To accommodate the latter approach, senders are +encouraged to wait for at least three times the PTO after receiving an +acknowledgement confirming the receipt of the previous key update before +initiating a new key update. + +As this specification allows the use of multiple paths with separate packet +number spaces, the latter approach is adopted with the period between the +confirmation of the previous key update and the initiation of new key update +being extended to three times the largest PTO among all the paths. 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 From ca448e1aa6ae273ae1c448e1ec8d6313c53b1aad Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Thu, 6 Jul 2023 14:07:52 +0900 Subject: [PATCH 2/4] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index b9b1ecf3..31983212 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -653,7 +653,7 @@ 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. QUIC v1 defines two +arrive later than the packets protected with the new key. QUIC version 1 defines two ways of dealing with such packets arriving out of order. Receivers can either retain up to three decryption keys and use the packet number in conjunction with the Key Phase bit to determine the decryption key, or retain up to two From 8fe2d5781ce9928234a26e7c200585eb739d4f3c Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Thu, 6 Jul 2023 15:16:20 +0900 Subject: [PATCH 3/4] reduce explanation of v1 --- draft-ietf-quic-multipath.md | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 31983212..3acd1c4b 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -653,20 +653,15 @@ 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. QUIC version 1 defines two -ways of dealing with such packets arriving out of order. Receivers can either -retain up to three decryption keys and use the packet number in conjunction with -the Key Phase bit to determine the decryption key, or retain up to two -decryption keys and solely rely on the Key Phase bit -({{Section 6.5 of QUIC-TLS}}). To accommodate the latter approach, senders are -encouraged to wait for at least three times the PTO after receiving an -acknowledgement confirming the receipt of the previous key update before -initiating a new key update. - -As this specification allows the use of multiple paths with separate packet -number spaces, the latter approach is adopted with the period between the -confirmation of the previous key update and the initiation of new key update -being extended to three times the largest PTO among all the paths. +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. 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 From 096d8f5f08337d9186970ca0dec45682f4a93570 Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Fri, 7 Jul 2023 11:55:51 +0900 Subject: [PATCH 4/4] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 3acd1c4b..2450346a 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -661,7 +661,7 @@ 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. +update. This interval is different from that of QUIC version 1 which used three times the PTO of the only one active path. 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