Opened 5 years ago

Closed 4 years ago

#311 closed design (fixed)

Add limitations to Range to reduce its use as a denial-of-service tool

Reported by: fielding@… Owned by:
Priority: normal Milestone: 22
Component: p5-range Severity: In WG Last Call
Keywords: Range Cc:

Description

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.

Change History (13)

comment:1 Changed 5 years ago by mnot@…

  • Owner draft-ietf-httpbis-p5-range@… deleted

comment:2 Changed 5 years ago by ylafon@…

See [1542]

comment:3 Changed 5 years ago by julian.reschke@…

From [1543]:

tune changes for [1542] (see #311)

comment:4 Changed 5 years ago by ylafon@…

The changes in [1542] were only editorial:

  • Clarification that server can combine ranges (was only implicit in multipart/byterange text in RFC 2616)
  • Clarification that a server can ignore a Range: header if it detects an DoS attempt (which was already possible before especially as Range is optional)

Those changes mitigate the use of Ranges in DoS attempts while not creating extra requirements or changing conformance of existing implementations.

comment:5 Changed 5 years ago by ylafon@…

  • Milestone changed from unassigned to 19
  • Resolution set to incorporated
  • Status changed from new to closed

comment:6 Changed 4 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:7 Changed 4 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:8 Changed 4 years ago by fielding@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

It is a security concern that wasn't fixed.

comment:9 Changed 4 years ago by mnot@…

  • Milestone changed from 19 to unassigned

comment:10 Changed 4 years ago by mnot@…

  • Severity changed from Active WG Document to In WG Last Call

comment:11 Changed 4 years ago by fielding@…

  • Milestone changed from unassigned to 22
  • Resolution set to incorporated
  • Status changed from reopened to closed

From [2157]:

Address range flooding security issue (#175 and #311) by direct requirements and recommendations.

Actually require Content-Range and Content-Type (when appropriate) inside multipart/byteranges body parts instead of assuming that the reader will read between the lines of the MIME registration template.

Simplify description of required headers in 206 responses.

comment:12 Changed 4 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:13 Changed 4 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.