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

[Martin Thomson <[e-mail]>]

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
>> >
>> >
>> >