Re: [tsvwg] L4S and the RACK requirement

[Neal Cardwell <[e-mail]>]

Thanks, Bob. FWIW, as a co-author on the [Savage-TCP
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-26#ref-Savage-TCP>]
paper and the RACK-TLP RFC [RFC8985], I agree wholeheartedly with your
description of the misbehaving receiver attacks from that paper and their
implications with respect to RACK-TLP and L4S. I also agree it is best to
just remove these two lines from the draft.

best regards,
neal

On Thu, Jul 21, 2022 at 10:43 AM Bob Briscoe <[e-mail]> wrote:

> Wes, Lloyd,
>
> I'm dredging up this old 2019 thread, because a Security Directorate
> review just asked us to provide more background on these two lines in
> ecn-l4s-id that resulted from this thread. Specifically:
>
>    The recommendation to detect loss in time units prevents the ACK-
>    splitting attacks described in [Savage-TCP <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-26#ref-Savage-TCP>].
>
>
> Lloyd actually originally said "ACK-splitting and packet counting"
> attacks. Having looked into all three attacks in [Savage-TCP], I believe
> that detecting loss in time units (as opposed to ACK counting) doesn't
> prevent or mitigate any of them (details below). Lloyd might have meant
> attack #2 in the paper (DupACK spoofing). But that concerns how the CC
> guesses whether packets are leaving the network when it doesn't have any
> other info (i.e. no SACK). This is an orthogonal question to whether to use
> time rather than ACK counting to deem whether there has been a loss. So,
> it's not relevant to the point being made about loss-detection, so doesn't
> belong in this L4S draft.
>
> Therefore, we've decided to just remove these two lines from the draft
> (which Wes originally argued for on similar, but not quite the same,
> grounds).
>
>
> Details of the 3 attacks in Savage-TCP:
> #1 ACK division Description:
>     The receiver exploits a sender's CC that increases cwnd by one segment
> per ACK rather than per SMSS bytes.
> Effect:
>     The receiver causes the sender's CC to be more aggressive for its flow.
> Mitigated by RACK?
>     *No* (anyway this attack was since mitigated by the byte counting
> (ABC) RFC)
>
> #2 DupACK spoofing Description:
>     The receiver exploits the fast recovery algorithm that inflates cwnd
> by one segment for every 3 DupACKs received in addition to the first three
> that triggered fast-retransmit/fast recovery.
>     Before an RTO timeout, the attacking receiver can move on to
> repeatedly DupACK'ing a later packet.
> Effect:
>     The receiver causes the sender's CC to open cwnd indefinitely by
> continually repeating the same DupACK, without needing to acknowledge new
> data.
> Mitigated by RACK?
>     *Not specifically.* RACK replaces the trigger for FR/FR (by counting
> in time not DupACKs). But RACK-TLP [RFC8985] doesn't say anything about
> whether fast recovery still increments cwnd every 3 DupACKs after that. And
> it doesn't need to, because this vulnerability in TCP fast recovery was
> already highlighted in the latest spec of fast recovery [RFC5681; §3.2;
> step 4] with a suggested mitigation.
> #3 Optimistic ACKing Description
>     The receiver sends a stream of ACKs that anticipate future data
> Effect:
>     The receiver causes the sender's CC to open cwnd more aggressively
> than the standard expects
> Mitigated by RACK-TLP?
>     *No.*
>
>
>
> Bob
>
> On 23/02/2019 00:03, Wesley Eddy wrote:
>
> On 2/18/2019 7:36 AM, [e-mail] wrote:
>
> Am I the only person who remembers Savage attacks from ack splitting and
> packet counting?
>
> http://cseweb.ucsd.edu/~savage/papers/CCR99.pdf
>
> there's the support for the MUST NOT, at least. I's not the lack of scale
> that is the major issue there, it's being open to abuse. ack counting
> didn't work...
>
> I think it's only sort-of related, but not really.
>
> The tricks described there are ways to get a sender to be overly
> aggressive if it doesn't implement ABC (or other mitigations) so is growing
> a congestion window based on units of packets rather than bytes.  The L4S
> requirement here is about retransmission / loss detection though (reducing
> the window) happening based on units of time vs packets (rather than bytes
> vs packets).
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>