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.

Sign up for GitHub

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

Jump to bottom

Simplify receiver verification of ECN counters #1565

Merged
merged 3 commits into from
Jul 17, 2018
Merged

Simplify receiver verification of ECN counters #1565

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9fed56d
Simplify receiver verification of ECN corruption
janaiyengar Jul 14, 2018
0af5876
add text about allowing endpoints to detect corruption
janaiyengar Jul 14, 2018
037b418
no more no lesser
janaiyengar Jul 17, 2018
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
25 changes: 12 additions & 13 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1755,7 +1755,8 @@ counters in subsequent (see {{processing-and-ack}}) ACK_ECN frames (see
{{frame-ack-ecn}}).

A packet detected by a receiver as a duplicate does not affect the receiver's
local ECN codepoint counts to mitigate security concerns ({{security-ecn}}).
local ECN codepoint counts; see ({{security-ecn}}) for relevant security
concerns.

If an endpoint receives a packet without an ECT or CE codepoint, it responds per
{{processing-and-ack}} with an ACK frame.
Expand All @@ -1771,20 +1772,18 @@ the expectation that either the network or the peer no longer supports ECN.
To protect the connection from arbitrary corruption of ECN codepoints by the
network, an endpoint verifies the following when an ACK_ECN frame is received:

* The total increase in ECT(0), ECT(1), and CE counters reported in the ACK_ECN
frame MUST be equal to the total number of packets newly acknowledged in this
ACK_ECN frame.

* The increase in ECT(0) and ECT(1) counters MUST be no greater than the number
* The increase in ECT(0) and ECT(1) counters MUST be no lesser than the number
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"no lesser" isn't a turn of phrase I'm comfortable with. "MUST be at least the number of newly acknowledged packets"

of packets newly acknowledged that were sent with the corresponding codepoint.

* If the increase in the ECT(0), ECT(1) and CE counters are greater than
the number of newly acknowledged packets, and the received ACK's
smallest acknowledged is larger than the previous largest acknowledged,
then it's likely acknowledgements were missed, and the above comparison
MUST NOT be performed. Instead a new comparison point is stored by the
sender so that only changes after this point will be used in the future
comparisons.
* The total increase in ECT(0), ECT(1), and CE counters reported in the ACK_ECN
frame MUST be no lesser than the total number of packets newly acknowledged in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

this ACK_ECN frame.

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
counters to be greater than the number of packets acknowledged in an ACK frame.
When this happens, the local reference counts MUST be increased to match the
counters in the ACK frame.

Upon successful verification, an endpoint continues to set ECT codepoints in
subsequent packets with the expectation that the path is ECN-capable.
Expand Down