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

Martin Thomson <martin.thomson@gmail.com> Fri, 26 April 2013 18:37 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3A821F97D3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 11:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.274
X-Spam-Level:
X-Spam-Status: No, score=-8.274 tagged_above=-999 required=5 tests=[AWL=2.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNdkjNDRqewr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 11:37:51 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 202DC21F97B7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Apr 2013 11:37:51 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVnWd-0007FX-Ns for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 18:37:39 +0000
Resent-Date: Fri, 26 Apr 2013 18:37:39 +0000
Resent-Message-Id: <E1UVnWd-0007FX-Ns@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UVnWZ-0007En-11 for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 18:37:35 +0000
Received: from mail-we0-f169.google.com ([74.125.82.169]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UVnWY-0003xz-3j for ietf-http-wg@w3.org; Fri, 26 Apr 2013 18:37:34 +0000
Received: by mail-we0-f169.google.com with SMTP id p43so3881130wea.14 for <ietf-http-wg@w3.org>; Fri, 26 Apr 2013 11:37:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4Yql/Mv+Jaxq8VBLDO5jLpJAlYLvZs3cVohuwkrpSbM=; b=Ll1d2Vk0ggG3s4tMpEd6sEIifNIrdlDNauTHWB3AsDp9ymHE5D/3xOdxRAma2NmUSN sVDAg0kuAjLOw5GWCuBQ7NDiF2QnWVMydtx+eKJXNNoU4CgbDgsU6zP8o5DDRsej37qS 1c3pPpHKEl1bZNIyhs08gE81mkw5BhtVxgySK5b6fwcpzzKWYLvHjE9m89zlfMAjo3vk RVnl5OjO8PWbPaQn2siP7y+Zj7i1YjzAR74zU5tZ8xTHtqTiEKbuvAo4P+tFX76uMdQR jeUvhQ26aWuJBOqVQEdOv3keQFI1pt5wIxYyIq7dade0u9rzAHPWftcaKT9QOzfGFego Wl2g==
MIME-Version: 1.0
X-Received: by 10.180.37.101 with SMTP id x5mr6151305wij.0.1367001427738; Fri, 26 Apr 2013 11:37:07 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Fri, 26 Apr 2013 11:37:07 -0700 (PDT)
In-Reply-To: <CABP7RbdUDuyxTuQ=LguMoKqXNT=Qr=R03iJpypMtXRs1nK-Vzg@mail.gmail.com>
References: <CABP7RbdscuxpBBQp1ydSQUri0Bg_aGSbm-ftF9Jnc-p_1DqnFg@mail.gmail.com> <792356c04b9e498c886252bc44904651@BY2PR03MB025.namprd03.prod.outlook.com> <CABkgnnXSc_7Gg6Ug8nuJEYRWYzoy7CFC1m8dxxToZ28B5M2SbA@mail.gmail.com> <CABP7RbdUDuyxTuQ=LguMoKqXNT=Qr=R03iJpypMtXRs1nK-Vzg@mail.gmail.com>
Date: Fri, 26 Apr 2013 11:37:07 -0700
Message-ID: <CABkgnnVp9FO8pSAD3DDtVzU0bCCDhPdx_+L5nY4SpvNFzYxO_w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=74.125.82.169; envelope-from=martin.thomson@gmail.com; helo=mail-we0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.682, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UVnWY-0003xz-3j 98572fffc608e028df5338ed5fad3e63
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Unknown Frame Type MUST IGNORE rule and Denial of Service Attacks
Archived-At: <http://www.w3.org/mid/CABkgnnVp9FO8pSAD3DDtVzU0bCCDhPdx_+L5nY4SpvNFzYxO_w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17616
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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 <jasnell@gmail.com>; 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" <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
>> >
>> >
>> >