Re: [tsvwg] L4S and the RACK requirement

[Bob Briscoe <[e-mail]>]

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 Briscoehttp://bobbriscoe.net/