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

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" <martin.thomson@gmail.com>
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 <Michael.Bishop@microsoft.com> 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:jasnell@gmail.com]
> > Sent: Friday, April 26, 2013 10:55 AM
> > To: ietf-http-wg@w3.org
> > 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
> >
> >
> >
>