idnits 2.17.1 draft-chen-httpbis-window-size-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 160: '...w size of 2^31-1 MUST be treated as a ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Dec 15, 2021) is 861 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis M. Chen 3 Internet-Draft Li. Su 4 Intended status: Standards Track China Mobile 5 Expires: June 18, 2022 Dec 15, 2021 7 http2 window size setting 8 draft-chen-httpbis-window-size-02 10 Abstract 12 This document proposed the minimum value setting mechanism for 13 HTTP2.0 Window and Window_update, and a Window_update frame sending 14 mechanism, used to solve the gap caused by the inconsistency of the 15 minimum value. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 18, 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Setting minimum window size . . . . . . . . . . . . . . . . . 3 54 3.1. Setting new parameter . . . . . . . . . . . . . . . . . . 3 55 3.2. new parameter setup process . . . . . . . . . . . . . . . 3 56 4. Setting minimum window update size . . . . . . . . . . . . . 4 57 4.1. Setting new parameter . . . . . . . . . . . . . . . . . . 5 58 4.2. new parameter setup process . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Informative References . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 The following content is from RFC 7540[RFC7540] 69 Both endpoints can adjust the initial window size for new streams by 70 including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS 71 frame that forms part of the connection preface. The connection 72 flow-control window can only be changed using WINDOW_UPDATE frames. 74 SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial 75 window size (in octets) for stream-level flow control. The initial 76 value is 2^16-1 (65,535) octets. Only DATA frames are subject to 77 flow control. 79 HTTP/2 defines only the format and semantics of WINDOW_UPDATE frames, 80 and does not specify how the receiver decides when to send frames, 81 what values to send, or how the sender chooses to send packets. And 82 RFC 7540 just Specifies the maximum value of Window and the Window 83 Size Increment, But there is no obvious rule about minimum values. 84 The implementation can choose any algorithm that meets the 85 requirements, this makes the difference. 87 In the current network, there is no standard minimum setting, which 88 leads to the inconsistency of message processing between 89 communication parties, which may led to the situation that the 90 message will be disdetermined as an attack by the recipient, actually 91 frequent window_UPDATE frames can result in a denial of service. In 92 draft draft-ietf-httpbis-02 section 10.5 also give some Denial-of- 93 Service considerantions. 95 2. Terminology 97 The readers should be familiar with the terms defined in. 99 In addition, this document makes use of the following terms: 101 Window_update: The WINDOW_UPDATE frame (type=0x8) is used to 102 implement flow control; 104 SETTING The SETTING frame (type=0x4) is used to transmitting 105 configuration informations which will affect the communication 106 process of the data stream. 108 3. Setting minimum window size 110 The parameter of Setting frame in RFC 7540 does not have the function 111 of Setting the minimum window size. This chapter proposes to add 112 this new parameter for Setting. The SETTINGS frame (type=0x4) 113 conveys configuration parameters that affect how endpoints 114 communicate, such as preferences and constraints on peer behavior. 115 The SETTINGS frame is also used to acknowledge the receipt of those 116 parameters. 118 3.1. Setting new parameter 120 The following new parameter is defined. 122 SETTINGS_MINIMUM_WINDOW_SIZE(0x7): Indicates the minimum window size 123 set by the sender. Allows the sender to inform the remote endpoint 124 of the minimum window size. For example, when set to 128 Bytes, the 125 minimum window size is 128 Bytes. 127 If the sender sends the last Data frame and the Window decreases to 128 less than the minimum Window, it will stop sending Data frame until 129 it receives window_UPDATE frame to increase the Window, and the 130 modified Window value is greater than the minimum set Window, then it 131 can start sending Data frame again. Note that this is more detail 132 than RFC7540 discribed, where Data frames can be sent as long as the 133 Window value is greater than zero. 135 3.2. new parameter setup process 136 +------+ +--------+ 137 |sender| |receiver| 138 +--+---+ +----+---+ 139 | SETTING | 140 +--------------------->+ 141 | identifier:0x04 | Set the initial 142 | | window size 143 | SETTING | 144 <----------------------+ 145 | Flags:ACK | 146 | | 147 | SETTING | 148 +--------------------->+ 149 | identifier:0x07 | Set the Minimum 150 | | window size 151 | SETTING | 152 +<---------------------+ 153 | Flags:ACK | 154 | | 156 Figure 1: the process of setting window size 158 First, set the initial window size with the identifier 159 SETTINGS_INITIAL_WINDOW_SIZE (0x4), values above the maximum flow- 160 control window size of 2^31-1 MUST be treated as a connection error 161 of type FLOW_CONTROL_ERROR. An ACK is received to indicate that the 162 setup is complete. 164 Then, set the minimum window size with the identifier 165 SETTINGS_MINIMUM_WINDOW_SIZE(0x7), ACK is received to indicate that 166 the minimum window size setup is complete. A FLOW_CONTROL_ERROR 167 error is thrown when the following SETTINGS_MINIMUM_WINDOW_SIZE set 168 in the Setting frame is below the negociative initial minimum value. 170 4. Setting minimum window update size 172 The WINDOW_UPDATE frame (type=0x8) is used to implement flow control. 173 The payload of a WINDOW_UPDATE frame is one reserved bit plus an 174 unsigned 31-bit integer indicating the number of octets that the 175 sender can transmit in addition to the existing flow-control window. 176 the unsigned 31-bit integer is knew as Window Size Increment and the 177 Size range is (1, 2^31-1), that means the default minimum is 1. So 178 this could lead to a problem, frequent sending of Window_UPDATE 179 frames with small value of Window Size Increment(such as 1 byte) will 180 result in the consumption of computing and network resources, and in 181 some cases can even trigger a denial of service attack. 183 We propose to add new parameter of SETTING frame for Implementation 184 that set a minimum update window value, It's actually the Window Size 185 Increment. 187 4.1. Setting new parameter 189 The following new parameter is defined. 191 SETTINGS_MINIMUM_WINDOW_UPDATE(0x8):Indicates that the sender has set 192 the minimum window_UPDATE update size. For example, when set to 128 193 Bytes, the minimum window update size is 128 Bytes. 195 If the buffering data processed by receriver at one time is less than 196 the minimum window update value, it needs to accumulate to the 197 minimum value before sending Window_update once to update the traffic 198 window. 200 4.2. new parameter setup process 202 +------+ +--------+ 203 |Sender| |Receiver| 204 +--+---+ +----+---+ 205 | | 206 | | 207 | Setting | 208 +--------------------------> 209 | Identifier:0x08 | 210 | | 211 | | 212 | Setting | 213 <--------------------------+ 214 | Flags:ACK | 215 | | 216 | | 217 | | 218 | Window_update | 219 +--------------------------> 220 | Window size increment | 221 | | 222 | | 224 Figure 2: the process of setting window_update size 226 First, set the minimum window_update size with the identifier 227 SETTINGS_MINIMUM_WINDOW_UPDATE(0x8), An ACK is received to indicate 228 that the setup is complete. Minimum window_update policy can only be 229 enabled if SETTINGS_MINIMUM_WINDOW_UPDATE is set. 231 Then, only when the cumulative amount of processing is greater than 232 the value of SETTINGS_MINIMUM_WINDOW_UPDATE, can an window_update 233 frame be sent which will inform the peer to increase the window 234 value. When the following Window Size Increment value in a 235 Window_update frame is less than the set negociative initial minimum, 236 a FRAME_SIZE_ERROR error is thrown. 238 5. Security Considerations 240 It solves the attack problem caused by the failure to set the minimum 241 value of window and window update frame, such as CVE-2019-9511, and 242 avoids the link congestion caused by small incremental update. 244 6. IANA Considerations 246 This document does not require any action from IANA. 248 7. Acknowledgement 250 TBD 252 8. Informative References 254 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 255 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 256 DOI 10.17487/RFC7540, May 2015, 257 . 259 Authors' Addresses 261 Meiling Chen 262 China Mobile 263 32, Xuanwumen West 264 BeiJing, BeiJing 100053 265 China 267 Email: chenmeiling@chinamobile.com 269 Li Su 270 China Mobile 271 32, Xuanwumen West 272 BeiJing 100053 273 China 275 Email: suli@chinamobile.com