idnits 2.17.1 draft-chen-httpbis-window-size-use-case-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2020) is 1200 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 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: Informational China Mobile 5 Expires: June 17, 2021 December 14, 2020 7 http2 window size use case 8 draft-chen-httpbis-window-size-use-case-00 10 Abstract 12 This document presents an use case which actually happening in our 13 network, when window_size_increment in the window update frame less 14 than 128 bytes and the increased window size also less than 128 15 bytes, then network connection will come to an error. 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 17, 2021. 34 Copyright Notice 36 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 57 7. Informative References . . . . . . . . . . . . . . . . . . . 4 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 The following content is from RFC 7540[RFC7540] 64 When an HTTP/2 connection is first established, new streams are 65 created with an initial flow-control window size of 65,535 octets. 66 The connection flow-control window is also 65,535 octets. Both 67 endpoints can adjust the initial window size for new streams by 68 including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS 69 frame that forms part of the connection preface. The connection 70 flow-control window can only be changed using WINDOW_UPDATE frames. 72 SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial 73 window size (in octets) for stream-level flow control. The initial 74 value is 2^16-1 (65,535) octets. 76 Window Size Increment defined in the Window_update is 31, the legal 77 range for the increment to the flow-control window is 1 to 2^31-1 78 (2,147,483,647) octets. 80 RFC 7540 just Specifies the maximum value of Window and the Window 81 Size Increment, But there is no obvious rule about minimum values. 83 2. Terminology 85 The readers should be familiar with the terms defined in. 87 In addition, this document makes use of the following terms: 89 Window_update: The WINDOW_UPDATE frame (type=0x8) is used to 90 implement flow control; 92 3. Use Case 94 This section describes use case which happens between two different 95 manufacturers. They both use HTTP2.0 protocol to transmit messages. 96 We found this phenomenon, one issues a regular registration request, 97 the other one receives the request, but judged to be attack 98 behaviour. 100 +---------+ +----------+ 101 | Sender | |Receiver | 102 | | | | 103 +----+----+ +-----+----+ 104 | Reqistration request | 105 +-----------------------------------> 106 | | 107 | | 108 +-----------------------------------> 109 | Http2 Window_update | 110 | (condition1:window size | 111 | increment) | 112 | |window+=window size increment 113 | |condition2: window 114 | | 115 | |condition1<128bytes 116 | connection break |& condition2<128bytes 117 | +-------------------------+ |=attack behaviour 118 | | 119 | Registration Failed | 120 +<----------------------------------+ 121 + + 122 Figure 1: A normal request is considered an attack 124 Why determine abnormal attack behavior, the analysis is as follows: 126 The default initial window size defined by the protocol is 64K. 127 After the data in the receiving window is removed, part of the window 128 occupied by the original data is released. 130 If there is a large backlog of data in the original receiving window 131 that has not been removed, resulting in a small remaining window, the 132 window added after the normal removal of data will not be too small. 133 If there is little backlog of data in the original receiving window, 134 the window that needs to be added after the data is removed will be 135 small, but the overall available window after the adjustment will be 136 larger. In neither case will the window be too small, So the 137 connection considered to be an attack. 139 So when need to solve this problem, two approaches can be discussed, 140 specifying a minimum value for window and window size increment, or 141 increasing more detailed flow control strategies. 143 4. Security Considerations 145 Failure to set a minimum will result in frequent window_update if 146 only process a small amount of data at a time, it is likely to occur 147 Denial of service attacks, it would be fatal if it happened in an 148 Internet of Things scenario. 150 5. IANA Considerations 152 This document does not require any action from IANA. 154 6. Acknowledgement 156 TBD 158 7. Informative References 160 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 161 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 162 DOI 10.17487/RFC7540, May 2015, 163 . 165 Authors' Addresses 167 Meiling Chen 168 China Mobile 169 32, Xuanwumen West 170 BeiJing, BeiJing 100053 171 China 173 Email: 174 chenmeiling@chinamobile.com 176 Li Su 177 China Mobile 179 32, Xuanwumen West 181 BeiJing 183 100053 185 China 187 Email: 188 suli@chinamobile.com