Re: Re: new draft for the minimum value setting mechanism of HTTP2.0 Window and Window_update

Hi Martin,
please see inline.
 
From: Martin Thomson
Date: 2021-02-16 06:30
To: ietf-http-wg
Subject: Re: new draft for the minimum value setting mechanism of HTTP2.0 Window and Window_update
On Mon, Feb 15, 2021, at 18:55, Meiling Chen wrote:
>  * 1 byte block at a time is not mandatory in our use case we talk 
> about a range of smaller values,  we consider the addition of a small 
> window and the few adjusted Windows to be an unusual attack, this 
> attack looks similar to CVE-2019-9511, you can see in the use case 
> section 3, we did an analysis, normally, it's almost impossible to have 
> simultaneous small cases for Window and Window_update. 
 
I don't think that this is rare.  Even during normal operation.  RFC 813, Section 3 describes the same problem.  And I would not read the CVE so literally; 1 byte is the worst case, but it's fairly clear that 2 bytes is also bad.
[Meiling]Exactly, a bunch of small values are bad.
 
Hence my original question about 128 being special.  My understanding is that the value you choose is just down to a trade-off of cost of processing vs. value of sensitivity and responsiveness.  Smaller values could be faster if the processing cost and overheads can be justified.
[Meiling]Your understanding is correct, there are trade-offs to consider,  so we just take 128 as example, and provides a mechanism to set it which may depend on the state of the network and the state of the processor.
 
Implementations could just withhold small flow control updates.  Is there a specific reason for having a setting here?
 [Meiling] I don't quite understand the question, maybe the answer is not so accurate, we simply provide a way to set the minimum value to prevent some attacks that exploit the smaller value or because there is no default agreed minimum which lead to a normal message is mistaken as an attack.