From 7f3cda841c01bcb677892e61e03341be06bef5a7 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 22 Mar 2020 10:27:56 -0400 Subject: [PATCH 1/6] Clarify PTO packets count towards amplification limit Fixes #3413 --- draft-ietf-quic-recovery.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index bd4da6048e..294494e39f 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -534,7 +534,8 @@ Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent, then the PTO alarm MUST NOT be armed until datagrams have been received from -the client. +the client, because packets sent on PTO count against the anti-amplification +limit. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server From eb47fe039e4eb2a94d91e2db11784e3c52d6b0e4 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 22 Mar 2020 10:49:25 -0400 Subject: [PATCH 2/6] Update draft-ietf-quic-recovery.md Add a note which came up in #3340 about 0-RTT being accepted, but not path/address validation. --- draft-ietf-quic-recovery.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 294494e39f..191a707d05 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -530,20 +530,6 @@ PATH_RESPONSE to set the initial RTT (see kInitialRtt in {{ld-consts-of-interest}}) for a new path, but the delay SHOULD NOT be considered an RTT sample. -Until the server has validated the client's address on the path, the amount of -data it can send is limited to three times the amount of data received, -as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent, -then the PTO alarm MUST NOT be armed until datagrams have been received from -the client, because packets sent on PTO count against the anti-amplification -limit. - -Since the server could be blocked until more packets are received from the -client, it is the client's responsibility to send packets to unblock the server -until it is certain that the server has finished its address validation -(see Section 8 of {{QUIC-TRANSPORT}}). That is, the client MUST set the -probe timer if the client has not received an acknowledgement for one of its -Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. - Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client. To allow the client to improve its RTT @@ -559,6 +545,22 @@ keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. +#### Before Path Validation + +Until the server has validated the client's address on the path, the amount of +data it can send is limited to three times the amount of data received, +as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent, +then the PTO alarm MUST NOT be armed until datagrams have been received from +the client, because packets sent on PTO count against the anti-amplification +limit. The server could fail to validate the path even if 0-RTT is accepted. + +Since the server could be blocked until more packets are received from the +client, it is the client's responsibility to send packets to unblock the server +until it is certain that the server has finished its address validation +(see Section 8 of {{QUIC-TRANSPORT}}). That is, the client MUST set the +probe timer if the client has not received an acknowledgement for one of its +Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. + ### Speeding Up Handshake Completion When a server receives an Initial packet containing duplicate CRYPTO data, From 99796822b309ecd39bee7d648d4916c4edcdfc99 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 22 Mar 2020 10:50:10 -0400 Subject: [PATCH 3/6] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 191a707d05..a556ca83c2 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -545,14 +545,15 @@ keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. -#### Before Path Validation +#### Before Address Validation Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent, then the PTO alarm MUST NOT be armed until datagrams have been received from the client, because packets sent on PTO count against the anti-amplification -limit. The server could fail to validate the path even if 0-RTT is accepted. +limit. The server could fail to validate the client's address even if 0-RTT is +accepted. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server From 90ffa0a9f47780511e6ae18456669cb36696c9fe Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 23 Mar 2020 10:26:10 -0400 Subject: [PATCH 4/6] Update draft-ietf-quic-recovery.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index a556ca83c2..fe38f06149 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -549,7 +549,7 @@ have been set for a now discarded packet number space. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, -as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent, +as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no additional data can be sent, then the PTO alarm MUST NOT be armed until datagrams have been received from the client, because packets sent on PTO count against the anti-amplification limit. The server could fail to validate the client's address even if 0-RTT is From 1320c22506454ff42bc867250fa55eaaa1accdd7 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 23 Mar 2020 10:29:49 -0400 Subject: [PATCH 5/6] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index fe38f06149..763f60d7f2 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -549,11 +549,11 @@ have been set for a now discarded packet number space. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, -as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no additional data can be sent, -then the PTO alarm MUST NOT be armed until datagrams have been received from -the client, because packets sent on PTO count against the anti-amplification -limit. The server could fail to validate the client's address even if 0-RTT is -accepted. +as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no additional data can be +sent, then the PTO alarm MUST NOT be armed until datagrams have been received +from the client, because packets sent on PTO count against the +anti-amplification limit. The server could fail to validate the client's +address even if 0-RTT is accepted. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server From 95e46952fcec6da8297f40eaef105ce0538563c1 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 29 Mar 2020 19:20:17 -0400 Subject: [PATCH 6/6] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 763f60d7f2..a65924c548 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -550,10 +550,10 @@ have been set for a now discarded packet number space. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no additional data can be -sent, then the PTO alarm MUST NOT be armed until datagrams have been received -from the client, because packets sent on PTO count against the -anti-amplification limit. The server could fail to validate the client's -address even if 0-RTT is accepted. +sent, the server's PTO alarm MUST NOT be armed until datagrams have been +received from the client, because packets sent on PTO count against the +anti-amplification limit. Note that the server could fail to validate the +client's address even if 0-RTT is accepted. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server