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

From: "Meiling Chen" <[email-masked]>
Date: Tue, 9 Feb 2021 16:44:43 +0800

Hello all, 
We find a problem when using http2.0 protocol,  actually happening in our  network, in the course of the interaction when window_size_increment in the window update frame less
than 128 bytes and the increased window size also less than 128 bytes, then network connection will come to an error.  We describe it in detail in the draft draft-chen-httpbis-window-size-use-case-00(https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size-use-case/).
Meanwhile,  we proposed a solution to the problem, by define the minimum value setting mechanism of HTTP2.0 Window and Window_update, and a Window_update frame sending
mechanism. We describe interactive process in detail in the draft draft-chen-httpbis-window-size-00 (https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size/) .

Comments are welcome.

Best Wishes
(Chen Meiling)
--------------------------------------------------------------------------------------
Research Institute of China Mobile Communications Co. Ltd
Institute of Safety Technology
Email address: [email-masked]
Phone: 13810149515
Telephone: 15801696688-34283
Address: No. 32, Xuanwumen West Street, Xicheng District, Beijing (Mobile Innovation Building)

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Feb 2021 20:56:03 +1100

Hi,

Thanks for sharing this.  I think that I understand the problem you describe, but I'm not sure that I can see how this differs from CVE-2019-9511 “Data Dribble”[1].  Can you explain how this is different?  Is the number 128 somehow special?  The CVE talks about 1-byte increases; is this just that the problem exists for a range of smaller values?

[1] https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md

On Tue, Feb 9, 2021, at 19:44, Meiling Chen wrote:
> Hello all, 
> We find a problem when using http2.0 protocol,  actually happening in 
> our  network, in the course of the interaction when 
> window_size_increment in the window update frame less
> than 128 bytes and the increased window size also less than 128 bytes, 
> then network connection will come to an error.  We describe it in 
> detail in the draft 
> draft-chen-httpbis-window-size-use-case-00(https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size-use-case/).
> Meanwhile,  we proposed a solution to the problem, by define the 
> minimum value setting mechanism of HTTP2.0 Window and Window_update, 
> and a Window_update frame sending
> mechanism. We describe interactive process in detail in the draft 
> draft-chen-httpbis-window-size-00 
> (https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size/) .
> 
> Comments are welcome.
> 
> Best Wishes
> 
> (Chen Meiling)
>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 9 Feb 2021 10:38:32 +0000

Hiya,

To add to what Martin asked, I'd like to understand if there is really
_any_ minimum value that is safe to use. It seems that an attacker could
always try to game the system, so implementations should be defensive.

Picking too granular a minimum value also seems prone to problems. I can
see the possibility for some deadlocks to happen here unless endpoints can
commit to buffering.

Cheers
Lucas

---

From: "Meiling Chen" <[email-masked]>
Date: Mon, 15 Feb 2021 15:55:09 +0800

Hi Martin,
Sorry reply late because of the holiday.
The attack in CVE-2019-9511 consists of two actions: manipulate the window size and stream priority to force the server to queue data in 1-byte blocks.
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. 

Best Wishes,
Meiling Chen
From: Martin Thomson
Date: 2021-02-09 17:56
To: ietf-http-wg
Subject: Re: new draft for the minimum value setting mechanism of HTTP2.0 Window and Window_update
Hi,

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 16 Feb 2021 09:30:42 +1100

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.

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.

Implementations could just withhold small flow control updates.  Is there a specific reason for having a setting here?

---

From: "Meiling Chen" <[email-masked]>
Date: Wed, 17 Feb 2021 12:57:08 +0800

Hi Martin,
please see inline.
 
From: Martin Thomson
Date: 2021-02-16 06:30
To: ietf-http-wg
 
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.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 17 Feb 2021 16:34:29 +1100

> >  [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 b…

You suggest that implementations always ensure that their updates are large enough.  This is a good recommendation.  However, you also describe a setting.  Why does one endpoint need to provide this value to the other endpoint?  Can endpoints just do the right thing themselves?

---

From: "Meiling Chen" <[email-masked]>
Date: Wed, 17 Feb 2021 14:22:53 +0800

Hi Martin,
Please see inline.
 
From: Martin Thomson
Date: 2021-02-17 13:34
To: ietf-http-wg
 
You suggest that implementations always ensure that their updates are large enough.  This is a good recommendation.  However, you also describe a setting.  Why does one endpoint need to provide this value to the other endpoint?  Can endpoints just do the right thing themselves?
[Meiling] Yes, we describe a setting. There are two ways of setting, one is  the default value setting, the other is the endpoint flexible setting.