- From: Roberto Peon <grmocg@gmail.com>
- Date: Fri, 11 Jul 2014 09:21:16 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNdB_u10O+R9qYut+q0jx06M2a+MvnYA=TjvHiQRBLx56A@mail.gmail.com>
I've seen folks stating that HPACK/or its reference set are related to DoS or HoL blocking, but wanted to point out that these are orthogonal. There are three modes of DoS attack using headers: 1) Stalling a connection by never finishing the sending of a full set of headers. 2) Resource exhaustion of CPU. 3) Resource exhaustion of memory. I don't find #1 interesting, since the attacker is mostly just attacking themselves I don't find #2 very interesting, since there are other (and far more effective) ways of attacking including sending a SETTINGS frame between every other DATA frame, sending 1-byte DATA frames, or by creating and tearing down the connection repeatedly, etc. I think #3 is the interesting attack vector. The current design handles this fairly well, at most one set of headers can be incomplete at any point in time (sending a large number of incomplete headers and keeping most of them incomplete most of the time is an excellent attack vector, which the design currently precludes). Sending headers via a large buffer or via fragments changes nothing about this particular attack vector-- the important part is to keep the max number of incomplete headers down to as small as possible (e.g. 1). In terms of memory exhaustion, knowing the size of the set of headers which is being received is marginally helpful and can be detrimental in terms of DoS. On the helpful side, if one realizes that the headers are going to be larger than one wishes to handle, knowing the length means knowing that the data should be processed and thrown out. On the less-than-helpful side, knowing the size encourages allocating that much buffer, which an attacker can then exploit by not finishing the connection, and thus increasing the amount of memory which must sit idle. In other words, it is likely that the most robust solution is to allocate memory on demand. There is another interesting memory resource attack, which is the memory-expansion of compressed headers into uncompresed (i.e. zip-bomb) attack. This is orthogonal to other considerations and can be done so long as any compression at all is used, and so probably shouldn't factor into any decisions about framing. I will point out, however, that the reference set actually reduces the risk there by a factor of 2 (not enough to really care about either way, imho). That brings us to HPACK. Its only interesting DoS impact is that it enables expansion attacks, as would *any* compressor, stateful or stateless. Eliminating the reference set changes nothing about the DoS impact. Switching to stateless changes nothing but effectiveness of the compressor (and thus the expansion/compaction ratio),. -=R
Received on Friday, 11 July 2014 16:21:43 UTC