Subject: Design Issue: Unknown Frame Type MUST IGNORE rule and Denial of Service Attacks

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 10:54:33 -0700

https://github.com/http2/http2-spec/issues/80#issuecomment-17089487

In the current draft (-02), we say that Unknown and unrecognized Frame
types MUST be ignored by an endpoint. While this is ok in theory, this
can be very dangerous in practice. Specifically, an attacking sender
could choose to flood a recipient with a high number of junk frames
that use a previously unused type code. Because of the MUST IGNORE
rule, these would simply be discarded by the recipient but the damage
will already have been done. Flow control actions could help mitigate
the problem, but those are only partially effective.

Also, the order of processing here for error handling is not clear.

Let's say an attacker sends a HEADERS frame to the server initiating a
stream. The server sends an RST_STREAM REFUSED_STREAM fully closing
the stream. The attacker continues to send JUNK frames for the same
stream ID. There are two conditions happening here:

1. The sender is sending frames for a closed stream, which ought to
result in an RST_STREAM, but..

2. The frame type is unknown and unrecognized by the server so MUST be ignored.

Which condition takes precedence and how do we mitigate the possible
attack vector on this one.

- James

---

From: Mike Bishop <[email-masked]>
Date: Fri, 26 Apr 2013 18:08:04 +0000

I raised a related issue with Martin, that the FINAL flag is valid in these ignored frames, and the ordering of those rules could lead to disagreement between the peers whether a given stream has been half-closed or not.  We might simply modify the text to say that the payload and frame-specific flags must be ignored, not the entire frame per se.

-----Original Message-----
From: James M Snell [mailto:[email-masked]] 
Sent: Friday, April 26, 2013 10:55 AM
To: [email-masked]
Subject: Design Issue: Unknown Frame Type MUST IGNORE rule and Denial of Service Attacks

In the current draft (-02), we say that Unknown and unrecognized Frame types MUST be ignored by an endpoint. While this is ok in theory, this can be very dangerous in practice. Specifically, an attacking sender could choose to flood a recipient with a high number of junk frames that use a previously unused type code. Because of the MUST IGNORE rule, these would simply be discarded by the recipient but the damage will already have been done. Flow control actions could help mitigate the problem, but those are only partially effective.

Let's say an attacker sends a HEADERS frame to the server initiating a stream. The server sends an RST_STREAM REFUSED_STREAM fully closing the stream. The attacker continues to send JUNK frames for the same stream ID. There are two conditions happening here:

1. The sender is sending frames for a closed stream, which ought to result in an RST_STREAM, but..

Which condition takes precedence and how do we mitigate the possible attack vector on this one.

- James

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Apr 2013 11:28:47 -0700

Let me know if the text in the current draft leaves that unclear Mike.

For the rest of this issue, I don't see this as a problem that
specifications can address.

If your implementation is ignoring these frames in every sense of the
word, then you are in trouble.  If someone wants to willfully ignore
RST_STREAM, send more frames than your flow control window allows, or
any of these nasty sorts of things, then they are a bad person and you
should be prepared to treat them accordingly.

---

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 11:34:02 -0700

In my experience,  it's usually better to be a bit more prescriptive in how
to deal with potential security issues if you want people to do it
correctly ;-).  Simply saying, "well, that's a bad man but it's your
problem, deal with it"  isn't quite enough.
 On Apr 26, 2013 11:28 AM, "Martin Thomson" <[email-masked]>
wrote:

> > I raised a related issue with Martin, that the FINAL flag is valid in
> these ignored frames, and the ordering of those rules could lead to
> disagreement between the peers whether a given stream has been half-closed
> or not.  We might simply modify the text to say that the payload and
> frame-specific flags must be ignored, not the entire frame per se.
> >
> types MUST be ignored by an endpoint. While this is ok in theory, this can
> be very dangerous in practice. Specifically, an attacking sender could
> choose to flood a recipient with a high number of junk frames that use a
> previously unused type code. Because of the MUST IGNORE rule, these would
> simply be discarded by the recipient but the damage will already have been
> done. Flow control actions could help mitigate the problem, but those are
> only partially effective.
> >
> stream. The server sends an RST_STREAM REFUSED_STREAM fully closing the
> stream. The attacker continues to send JUNK frames for the same stream ID.
> There are two conditions happening here:
> >

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Apr 2013 11:37:07 -0700

The Security Considerations sounds like a good place to put something
like that.  Chances are, the text will say something like "that's bad
man, but it's your problem, deal with it".

On 26 April 2013 11:34, James M Snell <[email-masked]> wrote:
> to deal with potential security issues if you want people to do it correctly
> ;-).  Simply saying, "well, that's a bad man but it's your problem, deal
> with it"  isn't quite enough.
>
> On Apr 26, 2013 11:28 AM, "Martin Thomson" <[email-masked]> wrote:
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 28 Apr 2013 15:32:14 -0700

+1

On Fri, Apr 26, 2013 at 11:37 AM, Martin Thomson
<[email-masked]>wrote:

> correctly
> >> > Subject: Design Issue: Unknown Frame Type MUST IGNORE rule and Denial
> of
> >> > Service Attacks
> >> >
> the