idnits 2.17.1 draft-chen-httpbis-window-size-01.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 159: '...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 (June 15, 2021) is 1044 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: December 17, 2021 June 15, 2021 7 http2 window size setting 8 draft-chen-httpbis-window-size-01 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. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 17, 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Setting minimum window size . . . . . . . . . . . . . . . . . 3 53 3.1. Setting new parameter . . . . . . . . . . . . . . . . . . 3 54 3.2. new parameter setup process . . . . . . . . . . . . . . . 3 55 4. Setting minimum window update size . . . . . . . . . . . . . 4 56 4.1. Setting new parameter . . . . . . . . . . . . . . . . . . 5 57 4.2. new parameter setup process . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 61 8. Informative References . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The following content is from RFC 7540[RFC7540] 68 Both endpoints can adjust the initial window size for new streams by 69 including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS 70 frame that forms part of the connection preface. The connection 71 flow-control window can only be changed using WINDOW_UPDATE frames. 73 SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial 74 window size (in octets) for stream-level flow control. The initial 75 value is 2^16-1 (65,535) octets. Only DATA frames are subject to 76 flow control. 78 HTTP/2 defines only the format and semantics of WINDOW_UPDATE frames, 79 and does not specify how the receiver decides when to send frames, 80 what values to send, or how the sender chooses to send packets. And 81 RFC 7540 just Specifies the maximum value of Window and the Window 82 Size Increment, But there is no obvious rule about minimum values. 83 The implementation can choose any algorithm that meets the 84 requirements, this makes the difference. 86 In the current network, there is no standard minimum setting, which 87 leads to the inconsistency of message processing between 88 communication parties, which may led to the situation that the 89 message will be determined as an attack by the recipient, actually 90 frequent window_UPDATE frames can result in a denial of service. In 91 draft draft-ietf-httpbis-02 section 10.5 also give some Denial-of- 92 Service considerantions. 94 2. Terminology 96 The readers should be familiar with the terms defined in. 98 In addition, this document makes use of the following terms: 100 Window_update: The WINDOW_UPDATE frame (type=0x8) is used to 101 implement flow control; 103 SETTING The SETTING frame (type=0x4) is used to transmitting 104 configuration informations which will affect the communication 105 process of the data stream. 107 3. Setting minimum window size 109 The parameter of Setting frame in RFC 7540 does not have the function 110 of Setting the minimum window size. This chapter proposes to add 111 this new parameter for Setting. The SETTINGS frame (type=0x4) 112 conveys configuration parameters that affect how endpoints 113 communicate, such as preferences and constraints on peer behavior. 114 The SETTINGS frame is also used to acknowledge the receipt of those 115 parameters. 117 3.1. Setting new parameter 119 The following new parameter is defined. 121 SETTINGS_MINIMUM_WINDOW_SIZE(0x7): Indicates the minimum window size 122 set by the sender. Allows the sender to inform the remote endpoint 123 of the minimum window size. For example, when set to 128 Bytes, the 124 minimum window size is 128 Bytes. 126 If the sender sends the last Data frame and the Window decreases to 127 less than the minimum Window, it will stop sending Data frame until 128 it receives window_UPDATE frame to increase the Window, and the 129 modified Window value is greater than the minimum set Window, then it 130 can start sending Data frame again. Note that this is more detail 131 than RFC7540 discribed, where Data frames can be sent as long as the 132 Window value is greater than zero. 134 3.2. new parameter setup process 135 +------+ +--------+ 136 |sender| |receiver| 137 +--+---+ +----+---+ 138 | SETTING | 139 +--------------------->+ 140 | identifier:0x04 | Set the initial 141 | | window size 142 | SETTING | 143 <----------------------+ 144 | Flags:ACK | 145 | | 146 | SETTING | 147 +--------------------->+ 148 | identifier:0x07 | Set the Minimum 149 | | window size 150 | SETTING | 151 +<---------------------+ 152 | Flags:ACK | 153 | | 155 Figure 1: the process of setting window size 157 First, set the initial window size with the identifier 158 SETTINGS_INITIAL_WINDOW_SIZE (0x4), values above the maximum flow- 159 control window size of 2^31-1 MUST be treated as a connection error 160 of type FLOW_CONTROL_ERROR. An ACK is received to indicate that the 161 setup is complete. 163 Then, set the minimum window size with the identifier 164 SETTINGS_MINIMUM_WINDOW_SIZE(0x7), ACK is received to indicate that 165 the minimum window size setup is complete. A FLOW_CONTROL_ERROR 166 error is thrown when the following SETTINGS_MINIMUM_WINDOW_SIZE set 167 in the Setting frame is below the negociative initial minimum value. 169 4. Setting minimum window update size 171 The WINDOW_UPDATE frame (type=0x8) is used to implement flow control. 172 The payload of a WINDOW_UPDATE frame is one reserved bit plus an 173 unsigned 31-bit integer indicating the number of octets that the 174 sender can transmit in addition to the existing flow-control window. 175 the unsigned 31-bit integer is knew as Window Size Increment and the 176 Size range is (1, 2^31-1), that means the default minimum is 1. So 177 this could lead to a problem, frequent sending of Window_UPDATE 178 frames with small value of Window Size Increment(such as 1 byte) will 179 result in the consumption of computing and network resources, and in 180 some cases can even trigger a denial of service attack. 182 We propose to add new parameter of SETTING frame for Implementation 183 that set a minimum update window value, It's actually the Window Size 184 Increment. 186 4.1. Setting new parameter 188 The following new parameter is defined. 190 SETTINGS_MINIMUM_WINDOW_UPDATE(0x8):Indicates that the sender has set 191 the minimum window_UPDATE update size. For example, when set to 128 192 Bytes, the minimum window update size is 128 Bytes. 194 If the buffering data processed by receriver at one time is less than 195 the minimum window update value, it needs to accumulate to the 196 minimum value before sending Window_update once to update the traffic 197 window. 199 4.2. new parameter setup process 201 +------+ +--------+ 202 |Sender| |Receiver| 203 +--+---+ +----+---+ 204 | | 205 | | 206 | Setting | 207 +--------------------------> 208 | Identifier:0x08 | 209 | | 210 | | 211 | Setting | 212 <--------------------------+ 213 | Flags:ACK | 214 | | 215 | | 216 | | 217 | Window_update | 218 +--------------------------> 219 | Window size increment | 220 | | 221 | | 223 Figure 2: the process of setting window_update size 225 First, set the minimum window_update size with the identifier 226 SETTINGS_MINIMUM_WINDOW_UPDATE(0x8), An ACK is received to indicate 227 that the setup is complete. Minimum window_update policy can only be 228 enabled if SETTINGS_MINIMUM_WINDOW_UPDATE is set. 230 Then, only when the cumulative amount of processing is greater than 231 the value of SETTINGS_MINIMUM_WINDOW_UPDATE, can an window_update 232 frame be sent which will inform the peer to increase the window 233 value. When the following Window Size Increment value in a 234 Window_update frame is less than the set negociative initial minimum, 235 a FRAME_SIZE_ERROR error is thrown. 237 5. Security Considerations 239 It solves the attack problem caused by the failure to set the minimum 240 value of window and window update frame, such as CVE-2019-9511, and 241 avoids the link congestion caused by small incremental update. 243 6. IANA Considerations 245 This document does not require any action from IANA. 247 7. Acknowledgement 249 TBD 251 8. Informative References 253 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 254 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 255 DOI 10.17487/RFC7540, May 2015, 256 . 258 Authors' Addresses 260 Meiling Chen 261 China Mobile 262 32, Xuanwumen West 263 BeiJing, BeiJing 100053 264 China 266 Email: 267 chenmeiling@chinamobile.com 269 Li Su 270 China Mobile 272 32, Xuanwumen West 274 BeiJing 276 100053 278 China 280 Email: 281 suli@chinamobile.com