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

[William Chan (陈智昌) <[e-mail]>]

+1


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

> 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 <[e-mail]> wrote:
> > 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" <[e-mail]>
> wrote:
> >>
> >> 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.
> >>
> >> On 26 April 2013 11:08, Mike Bishop <[e-mail]>
> 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.
> >> >
> >> > -----Original Message-----
> >> > From: James M Snell [mailto:[e-mail]]
> >> > Sent: Friday, April 26, 2013 10:55 AM
> >> > To: [e-mail]
> >> > Subject: Design Issue: Unknown Frame Type MUST IGNORE rule and Denial
> of
> >> > Service Attacks
> >> >
> >> > 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
> >> >
> >> >
> >> >
>
>