From 5e06b318a75fdb6bb936bd63ec84ec70e70f6a6a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 18 Jun 2020 15:41:29 +1000 Subject: [PATCH 1/9] Make language in ECN validation clearer This avoids "no smaller than" and other such ambiguities. However, in doing this, I realized that I might interpret the original language as allowing a network to ADD markings. That seems wrong. But it's a non-editorial change. This version has that change. I'll make another PR with the hole left in place. Closes #3733. --- draft-ietf-quic-transport.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 52c3aa80f4..5b09580ecd 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3816,25 +3816,29 @@ validation using ECT(1) counts. #### Receiving ACK Frames {#ecn-ack} -An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits MUST -use the following steps on receiving an ACK frame to validate ECN. +An endpoint that sets ECT(0) or ECT(1) codepoints on packets records the ECN +counts it has received in ACK frames. When processing an ACK frame, the +endpoint MUST validate the increase in ECN counts based on the markings that +were applied to packets that are newly acknowledged. + +ECN validation involves the following checks: * If this ACK frame newly acknowledges a packet that the endpoint sent with - either ECT(0) or ECT(1) codepoints set, and if no ECN feedback is present in - the ACK frame, validation fails. This step protects against both a network - element that zeroes out ECN bits and a peer that is unable to access ECN - markings, since the peer could respond without ECN feedback in these cases. + either ECT(0) or ECT(1) codepoints set, ECN feedback MUST be present in the + ACK frame. This step protects against both a network element that zeroes out + ECN bits and a peer that is unable to access ECN markings, since the peer + could respond without ECN feedback in either case. -* For validation to succeed, the total increase in ECT(0), ECT(1), and CE counts - MUST be no smaller than the total number of QUIC packets sent with an ECT - codepoint that are newly acknowledged in this ACK frame. This step detects - any network remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. +* For validation to succeed, the sum of the increases to ECT(0), ECT(1), and + CE counts in the ACK frame MUST be equal to the number of newly acknowledged + packets that were sent with an ECT codepoint. This step detects any network + remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT or a network that + adds markings to unmarked packets. * Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE - count, MUST be no smaller than the number of packets sent with the - corresponding ECT codepoint that are newly acknowledged in this ACK frame. - This step detects any erroneous network remarking from ECT(0) to ECT(1) (or - vice versa). + count, MUST NOT exceed the number of packets sent with the corresponding ECT + codepoint that are newly acknowledged in this ACK frame. This step detects + any erroneous network remarking from ECT(0) to ECT(1) (or vice versa). Processing ECN counts out of order can result in validation failure. An endpoint SHOULD NOT perform this validation if this ACK frame does not advance From 0cc27c7fc32445326bd0ea7b3a3d7529c585fdcc Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 18 Jun 2020 15:44:11 +1000 Subject: [PATCH 2/9] Remove normative change --- draft-ietf-quic-transport.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5b09580ecd..0257a90529 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3830,10 +3830,9 @@ ECN validation involves the following checks: could respond without ECN feedback in either case. * For validation to succeed, the sum of the increases to ECT(0), ECT(1), and - CE counts in the ACK frame MUST be equal to the number of newly acknowledged + CE counts in the ACK frame MUST be at least the number of newly acknowledged packets that were sent with an ECT codepoint. This step detects any network - remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT or a network that - adds markings to unmarked packets. + remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. * Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE count, MUST NOT exceed the number of packets sent with the corresponding ECT From 2c168299e72a17ca9aff36c529f49fb9710c7bcb Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 18 Jun 2020 16:41:29 +1000 Subject: [PATCH 3/9] Don't use MUST for ECN validation It is not an interoperability problem if the ECN counts don't match up, it's just that ECN can't be used. Avoid using normative language for this, which implies non-compliance by a peer: the non-compliance is likely somewhere in the network. --- draft-ietf-quic-transport.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0257a90529..bb6ee170e7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3824,20 +3824,21 @@ were applied to packets that are newly acknowledged. ECN validation involves the following checks: * If this ACK frame newly acknowledges a packet that the endpoint sent with - either ECT(0) or ECT(1) codepoints set, ECN feedback MUST be present in the - ACK frame. This step protects against both a network element that zeroes out - ECN bits and a peer that is unable to access ECN markings, since the peer - could respond without ECN feedback in either case. - -* For validation to succeed, the sum of the increases to ECT(0), ECT(1), and - CE counts in the ACK frame MUST be at least the number of newly acknowledged - packets that were sent with an ECT codepoint. This step detects any network - remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. - -* Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE - count, MUST NOT exceed the number of packets sent with the corresponding ECT - codepoint that are newly acknowledged in this ACK frame. This step detects - any erroneous network remarking from ECT(0) to ECT(1) (or vice versa). + either ECT(0) or ECT(1) codepoints set, ECN validation fails if ECN counts + are not present in the ACK frame. This step protects against both a network + element that zeroes out ECN bits and a peer that is unable to access ECN + markings, since the peer could respond without ECN feedback in either case. + +* ECN validation fails if the sum of the increases to ECT(0), ECT(1), and CE + counts in the ACK frame are less than the number of newly acknowledged + packets that were sent with an ECT codepoint. This step detects any + network remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. + +* ECN validation fails if any increase in either ECT(0) or ECT(1) counts, plus + any increase in the CE count, exceeds the number of packets sent with the + corresponding ECT codepoint that are newly acknowledged in this ACK frame. + This step detects any erroneous network remarking from ECT(0) to ECT(1) (or + vice versa). Processing ECN counts out of order can result in validation failure. An endpoint SHOULD NOT perform this validation if this ACK frame does not advance From 49507b4c9e38c201919a7241d70cc45b2f962fe0 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 18 Jun 2020 16:53:05 +1000 Subject: [PATCH 4/9] Rework ECN validation rules This attempts to create rules that won't break down unnecessarily. It's a little overwrought though, so I'm OK if we go with something less than this. The new check number 3 could be removed if we were comfortable with the simplified check number 2 and the addition of the check for unused markings. Closes #3778. --- draft-ietf-quic-transport.md | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bb6ee170e7..3d96df38ed 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3825,20 +3825,31 @@ ECN validation involves the following checks: * If this ACK frame newly acknowledges a packet that the endpoint sent with either ECT(0) or ECT(1) codepoints set, ECN validation fails if ECN counts - are not present in the ACK frame. This step protects against both a network - element that zeroes out ECN bits and a peer that is unable to access ECN + are not present in the ACK frame. This check protects against both a network + element that removes ECN markings or a peer that is unable to access ECN markings, since the peer could respond without ECN feedback in either case. -* ECN validation fails if the sum of the increases to ECT(0), ECT(1), and CE - counts in the ACK frame are less than the number of newly acknowledged - packets that were sent with an ECT codepoint. This step detects any - network remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. - -* ECN validation fails if any increase in either ECT(0) or ECT(1) counts, plus - any increase in the CE count, exceeds the number of packets sent with the - corresponding ECT codepoint that are newly acknowledged in this ACK frame. - This step detects any erroneous network remarking from ECT(0) to ECT(1) (or - vice versa). +* ECN validation fails if the sum of the increase in ECT(0) and ECT(1) counts, + plus any increase in the ECN-CE count is less than the number of packets sent + with the corresponding ECT codepoint. This check can detect removal of ECN + markings. + +* ECN validation fails if any unaccounted for increase in the sum of ECT(0) and + ECN-CE counts, plus any unaccounted for increase in the sum of ECT(1) and + ECN-CE counts, less any unaccounted for increase in the sum of the ECT(0), + ECT(1), and ECN-CE counts is not between zero and the overall increase to the + ECN-CE count from this ACK frame. An unaccounted for increase is determined + by subtracting the number of newly acknowledged packets that were originally + sent with the corresponding mark from the increase in counts reported in the + ACK frame. This check can detect erroneous changes between ECT(0) and + ECT(1) markings in the network. + +An endpoint MAY also validate total counts based on the total number of packets +that it sent with with a given marking. In that case, ECN validation can also +be performed based on total counts rather than increases. As a special case, +an endpoint that never applies a particular marking can fail validation when a +non-zero count for that marking is received. This check can detect when +packets are marked ECT(0) or ECT(1) in the network. Processing ECN counts out of order can result in validation failure. An endpoint SHOULD NOT perform this validation if this ACK frame does not advance From b760aa929a353f76cddf6e0fc0ff6c417d66d703 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 19 Jun 2020 14:51:20 +1000 Subject: [PATCH 5/9] Remove the complicated check, simplify --- draft-ietf-quic-transport.md | 69 +++++++++++++++--------------------- 1 file changed, 29 insertions(+), 40 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3d96df38ed..67f88d1cdc 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3817,49 +3817,38 @@ validation using ECT(1) counts. #### Receiving ACK Frames {#ecn-ack} An endpoint that sets ECT(0) or ECT(1) codepoints on packets records the ECN -counts it has received in ACK frames. When processing an ACK frame, the -endpoint MUST validate the increase in ECN counts based on the markings that -were applied to packets that are newly acknowledged. - -ECN validation involves the following checks: - -* If this ACK frame newly acknowledges a packet that the endpoint sent with - either ECT(0) or ECT(1) codepoints set, ECN validation fails if ECN counts - are not present in the ACK frame. This check protects against both a network - element that removes ECN markings or a peer that is unable to access ECN - markings, since the peer could respond without ECN feedback in either case. - -* ECN validation fails if the sum of the increase in ECT(0) and ECT(1) counts, - plus any increase in the ECN-CE count is less than the number of packets sent - with the corresponding ECT codepoint. This check can detect removal of ECN - markings. - -* ECN validation fails if any unaccounted for increase in the sum of ECT(0) and - ECN-CE counts, plus any unaccounted for increase in the sum of ECT(1) and - ECN-CE counts, less any unaccounted for increase in the sum of the ECT(0), - ECT(1), and ECN-CE counts is not between zero and the overall increase to the - ECN-CE count from this ACK frame. An unaccounted for increase is determined - by subtracting the number of newly acknowledged packets that were originally - sent with the corresponding mark from the increase in counts reported in the - ACK frame. This check can detect erroneous changes between ECT(0) and - ECT(1) markings in the network. - -An endpoint MAY also validate total counts based on the total number of packets -that it sent with with a given marking. In that case, ECN validation can also -be performed based on total counts rather than increases. As a special case, -an endpoint that never applies a particular marking can fail validation when a -non-zero count for that marking is received. This check can detect when -packets are marked ECT(0) or ECT(1) in the network. +counts it has received in ACK frames. An endpoint validates the ECN counts by +comparing the counts in each new ACK frame against the last ACK frame that was +successfully processed. The increase in ECN counts is validated based on the +markings that were applied to packets that are newly acknowledged in the ACK +frame. -Processing ECN counts out of order can result in validation failure. An -endpoint SHOULD NOT perform this validation if this ACK frame does not advance -the largest packet number acknowledged in this connection. +If an ACK frame newly acknowledges a packet that the endpoint sent with either +ECT(0) or ECT(1) codepoints set, ECN validation fails if ECN counts are not +present in the ACK frame. This check detects a network element that zeroes out +ECN bits or a peer that is unable to access ECN markings. + +ECN validation fails if the sum of the increase in ECT(0) and ECN-CE counts is +less than the number of newly acknowledged packets sent with an ECT(0) marking. +Similarly, if the sum of the increases to ECT(1) and ECN-CE counts is less than +the number of newly acknowledged packets sent with an ECT(1) marking. These +checks can detect removal of ECN markings in the network. + +ECN validation MAY fail if the total count for an ECT(0) or ECT(1) marking +exceeds the total number of packets sent with the corresponding marking. In +particular, an endpoint that never applies a particular marking can fail +validation when a non-zero count for the corresponding marking is received. +This check can detect when packets are marked ECT(0) or ECT(1) in the network. An endpoint could miss acknowledgements for a packet when ACK frames are lost. -It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts -to be greater than the number of packets acknowledged in an ACK frame. When -this happens, and if validation succeeds, the local reference counts MUST be -increased to match the counts in the ACK frame. +It is therefore possible for the total increase in ECT(0), ECT(1), and ECN-CE +counts to be greater than the number of packets acknowledged in an ACK frame. +This is why counts are permitted to be larger than might be accounted for by +newly acknowledged packets. + +Processing ECN counts out of order can result in validation failure. An +endpoint SHOULD skip ECN validation when an ACK frame does not increase the +largest acknowledged packet number. #### Validation Outcomes From 7ed70077c8006566c7acd27bbc06fe131140580e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 19 Jun 2020 15:01:30 +1000 Subject: [PATCH 6/9] Tweak language more --- draft-ietf-quic-transport.md | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 67f88d1cdc..27ed98ffe5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3816,12 +3816,12 @@ validation using ECT(1) counts. #### Receiving ACK Frames {#ecn-ack} -An endpoint that sets ECT(0) or ECT(1) codepoints on packets records the ECN -counts it has received in ACK frames. An endpoint validates the ECN counts by -comparing the counts in each new ACK frame against the last ACK frame that was -successfully processed. The increase in ECN counts is validated based on the -markings that were applied to packets that are newly acknowledged in the ACK -frame. +Erroneous application of markings in the network can result in ECN marking +providing bad information. Before using ECN counts, an endpoint validates the +ECN counts by comparing the counts in each ACK frame it processes against the +last ACK frame that was successfully processed. The increase in ECN counts is +validated based on the markings that were applied to packets that are newly +acknowledged in the ACK frame. If an ACK frame newly acknowledges a packet that the endpoint sent with either ECT(0) or ECT(1) codepoints set, ECN validation fails if ECN counts are not @@ -3829,16 +3829,11 @@ present in the ACK frame. This check detects a network element that zeroes out ECN bits or a peer that is unable to access ECN markings. ECN validation fails if the sum of the increase in ECT(0) and ECN-CE counts is -less than the number of newly acknowledged packets sent with an ECT(0) marking. -Similarly, if the sum of the increases to ECT(1) and ECN-CE counts is less than -the number of newly acknowledged packets sent with an ECT(1) marking. These -checks can detect removal of ECN markings in the network. - -ECN validation MAY fail if the total count for an ECT(0) or ECT(1) marking -exceeds the total number of packets sent with the corresponding marking. In -particular, an endpoint that never applies a particular marking can fail -validation when a non-zero count for the corresponding marking is received. -This check can detect when packets are marked ECT(0) or ECT(1) in the network. +less than the number of newly acknowledged packets that were originally sent +with an ECT(0) marking. Similarly, if the sum of the increases to ECT(1) and +ECN-CE counts is less than the number of newly acknowledged packets sent with +an ECT(1) marking. These checks can detect removal of ECN markings in the +network. An endpoint could miss acknowledgements for a packet when ACK frames are lost. It is therefore possible for the total increase in ECT(0), ECT(1), and ECN-CE @@ -3846,6 +3841,12 @@ counts to be greater than the number of packets acknowledged in an ACK frame. This is why counts are permitted to be larger than might be accounted for by newly acknowledged packets. +ECN validation MAY fail if the total count for an ECT(0) or ECT(1) marking +exceeds the total number of packets sent with the corresponding marking. In +particular, an endpoint that never applies a particular marking can fail +validation when a non-zero count for the corresponding marking is received. +This check can detect when packets are marked ECT(0) or ECT(1) in the network. + Processing ECN counts out of order can result in validation failure. An endpoint SHOULD skip ECN validation when an ACK frame does not increase the largest acknowledged packet number. From 56370b0f6111a90f61a6800bafea05515bf65f45 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 19 Jun 2020 20:50:07 +1000 Subject: [PATCH 7/9] Small improvements Co-authored-by: Jana Iyengar --- draft-ietf-quic-transport.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 27ed98ffe5..cd171c9dbe 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3816,11 +3816,12 @@ validation using ECT(1) counts. #### Receiving ACK Frames {#ecn-ack} -Erroneous application of markings in the network can result in ECN marking -providing bad information. Before using ECN counts, an endpoint validates the -ECN counts by comparing the counts in each ACK frame it processes against the -last ACK frame that was successfully processed. The increase in ECN counts is -validated based on the markings that were applied to packets that are newly +Erroneous application of ECN marks in the network can result in degraded +connection performance. An endpoint that receives an ACK frame with ECN +counts therefore validates the counts before using them. An endpoint validates +these counts by comparing newly received counts against those from the last +successfully processed ACK frame. Any increase in ECN counts is validated +based on the markings that were applied to packets that are newly acknowledged in the ACK frame. If an ACK frame newly acknowledges a packet that the endpoint sent with either @@ -3848,7 +3849,7 @@ validation when a non-zero count for the corresponding marking is received. This check can detect when packets are marked ECT(0) or ECT(1) in the network. Processing ECN counts out of order can result in validation failure. An -endpoint SHOULD skip ECN validation when an ACK frame does not increase the +endpoint SHOULD skip ECN validation on an ACK frame that does not increase the largest acknowledged packet number. From 911dbe41ac275d8c3f188fe07e768ee57b1069d9 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 19 Jun 2020 20:51:30 +1000 Subject: [PATCH 8/9] Similarly --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cd171c9dbe..01c293ade4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3831,10 +3831,10 @@ ECN bits or a peer that is unable to access ECN markings. ECN validation fails if the sum of the increase in ECT(0) and ECN-CE counts is less than the number of newly acknowledged packets that were originally sent -with an ECT(0) marking. Similarly, if the sum of the increases to ECT(1) and -ECN-CE counts is less than the number of newly acknowledged packets sent with -an ECT(1) marking. These checks can detect removal of ECN markings in the -network. +with an ECT(0) marking. Similarly, ECN validation fails if the sum of the +increases to ECT(1) and ECN-CE counts is less than the number of newly +acknowledged packets sent with an ECT(1) marking. These checks can detect +removal of ECN markings in the network. An endpoint could miss acknowledgements for a packet when ACK frames are lost. It is therefore possible for the total increase in ECT(0), ECT(1), and ECN-CE From b3efc66dfc41fee56bf0663ad766f83fe80df4eb Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 24 Jun 2020 08:27:32 +1000 Subject: [PATCH 9/9] it performs... Co-authored-by: Jana Iyengar --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 01c293ade4..c44c4aa41a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3818,8 +3818,8 @@ validation using ECT(1) counts. Erroneous application of ECN marks in the network can result in degraded connection performance. An endpoint that receives an ACK frame with ECN -counts therefore validates the counts before using them. An endpoint validates -these counts by comparing newly received counts against those from the last +counts therefore validates the counts before using them. It performs this +validation by comparing newly received counts against those from the last successfully processed ACK frame. Any increase in ECN counts is validated based on the markings that were applied to packets that are newly acknowledged in the ACK frame.