Subject: #311: Denial of Service and Ranges

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Nov 2011 15:24:56 +1100

Roy raised the following about p5:

Servers that support Range requests as defined by 2616 are vulnerable to denial of service attacks due to the potential presence of many small or overlapping ranges. We can fix this by adding the following requirements:

1) Clients MUST NOT send Range requests containing multiple byterange specifiers that overlap. Servers MAY coalesce such overlapping ranges into a single range, regardless of the order those ranges are specified in the Range header field, or MAY respond with a 416 or 200 status instead.

2) Clients MUST NOT send Range requests containing multiple byterange specifiers that have a gap between ranges of less than 80 bytes, since the transmission overhead of multipart/byteranges parts is generally more than 80 bytes per range and is a far more significant burden on the server than simply transmitting the gap. Servers MAY coalesce multiple ranges with gaps smaller than the size of the corresponding multipart overhead, regardless of the order that those ranges are specified in the Range header field, or MAY respond with a 416 or 200 status instead.

3) Clients that send Range requests containing multiple byterange specifiers MUST list those ranges in ascending order within the Range header field value. Servers MAY reorder multiple ranges if they are not requested in ascending order, or respond with a 416 or 200 status instead.

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311>

Any comments? If not, we'll incorporate into the next drafts for review.

--
Mark Nottingham   http://www.mnot.net/

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Wed, 23 Nov 2011 22:52:40 -0600

> 2) Clients MUST NOT send Range requests containing multiple byterange specifiers that have a gap between ranges of less than 80 bytes, since the transmission overhead of multipart/byteranges parts…

That should be SHOULD NOT, I suspect.  It's stupid, but not nearly as stupid
as asking for the same bytes 2x over.

It's easier to say servers are always permitted to coalesce responses in a
manner that makes delivery more efficient.  I believe this needs to include
sequencing them in serial order as mentioned in...

---

From: Robert Collins <[email-masked]>
Date: Thu, 24 Nov 2011 17:56:22 +1300

> 3) Clients that send Range requests containing multiple byterange specifiers MUST list those ranges in ascending order within the Range header field value. Servers MAY reorder multiple ranges if th…

Out of order requests are very useful for readv style VFS calls, when
backed onto HTTP. Surely permitting out of order ranges is better than
having the clients pipeline them instead (with all the additional
overhead of separate requests).

-Rob

---

From: Dale Anderson <[email-masked]>
Date: Wed, 23 Nov 2011 20:56:48 -0800

I think that may be arbitrary overhead to try and comply with for the
implementations and this should be left to more of a
firewall/application-delivery layer.

I think this is too arbitrary and the implementation should focus on having
limits when its algorithms attempt to parse and serve a set of ranges.

Humbly,

Dale

2011/11/23 Mark Nottingham <[email-masked]>

> Servers that support Range requests as defined by 2616 are vulnerable to
> denial of service attacks due to the potential presence of many small or
> overlapping ranges. We can fix this by adding the following requirements:
>
> 1) Clients MUST NOT send Range requests containing multiple byterange
> specifiers that overlap. Servers MAY coalesce such overlapping ranges into
> a single range, regardless of the order those ranges are specified in the
> Range header field, or MAY respond with a 416 or 200 status instead.
>
> 2) Clients MUST NOT send Range requests containing multiple byterange
> specifiers that have a gap between ranges of less than 80 bytes, since the
> transmission overhead of multipart/byteranges parts is generally more than
> 80 bytes per range and is a far more significant burden on the server than
> simply transmitting the gap. Servers MAY coalesce multiple ranges with gaps
> smaller than the size of the corresponding multipart overhead, regardless
> of the order that those ranges are specified in the Range header field, or
> MAY respond with a 416 or 200 status instead.
>
> 3) Clients that send Range requests containing multiple byterange
> specifiers MUST list those ranges in ascending order within the Range
> header field value. Servers MAY reorder multiple ranges if they are not
> requested in ascending order, or respond with a 416 or 200 status instead.
>

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 24 Nov 2011 18:00:22 +1300

I'd be keen to see something that allowed a server to deliver a single 
range that encompassed all requested ranges, regardless of whether there 
were gaps or overlaps in the requested ranges.

then the server could avoid multipart response types.

Adrien

On 24/11/2011 5:52 p.m., William A. Rowe Jr. wrote:
>> Servers that support Range requests as defined by 2616 are vulnerable 
>> to denial of service attacks due to the potential presence of many 
>> small or overlapping ranges. We can fix this by adding the following 
>> requirements:
>>
>> specifiers that overlap. Servers MAY coalesce such overlapping ranges 
>> into a single range, regardless of the order those ranges are 
>> specified in the Range header field, or MAY respond with a 416 or 200 
>> status instead.
>>
>> specifiers that have a gap between ranges of less than 80 bytes, 
>> since the transmission overhead of multipart/byteranges parts is 
>> generally more than 80 bytes per range and is a far more significant 
>> burden on the server than simply transmitting the gap. Servers MAY 
>> coalesce multiple ranges with gaps smaller than the size of the 
>> corresponding multipart overhead, regardless of the order that those 
>> ranges are specified in the Range header field, or MAY respond with a 
>> 416 or 200 status instead.
>
>> header field value. Servers MAY reorder multiple ranges if they are 
>> not requested in ascending order, or respond with a 416 or 200 status 
>> instead.
>>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/