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

James M Snell <jasnell@gmail.com> Fri, 26 April 2013 18:35 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 1E24D21F9742 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 11:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.245
X-Spam-Level:
X-Spam-Status: No, score=-10.245 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vgqFaQadxHfK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 11:35:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E83E121F9732 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Apr 2013 11:35:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVnTf-0005Zq-53 for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 18:34:35 +0000
Resent-Date: Fri, 26 Apr 2013 18:34:35 +0000
Resent-Message-Id: <E1UVnTf-0005Zq-53@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UVnTa-0005Ya-0S for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 18:34:30 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UVnTY-0003si-Oh for ietf-http-wg@w3.org; Fri, 26 Apr 2013 18:34:29 +0000
Received: by mail-ob0-f178.google.com with SMTP id 16so3753113obc.23 for <ietf-http-wg@w3.org>; Fri, 26 Apr 2013 11:34:02 -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=wKjSwXnhhR7iq5V3pw+O2b2tT31Ya3FBognD6cdLWlY=; b=U6fE1HffYGQjuOUBj7hb40T2k3lfL6ATMLik6A05xBKRrg5K+FqGoSe6Tv7reWfxQK GjtC8ad20l1UtMNQXBj4f0GgvueOZvNi4UXR+n7jSOyB1aWiL/QcnuT8rAVEUajcKB/1 nNNMBDeBHQ1alK8648+ffBt/mDZheB8VkMX2cIXd+QfVxpl9DiNm7TtznERFBFh72YXj dVkKNHLiXtbbDfXLwNRF4SjiWL5n6Nt37ZA4Y662Zx5NK3NPL46EnZWbPDrpkth0YLij tdx8t4J8p94eguFrAchDVH5h7RBXNPCORfKV8OZ904jLq8T3jyVybRBKBX+5SfAZ98JQ UMKw==
MIME-Version: 1.0
X-Received: by 10.182.246.198 with SMTP id xy6mr18295848obc.1.1367001242853; Fri, 26 Apr 2013 11:34:02 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Fri, 26 Apr 2013 11:34:02 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Fri, 26 Apr 2013 11:34:02 -0700 (PDT)
In-Reply-To: <CABkgnnXSc_7Gg6Ug8nuJEYRWYzoy7CFC1m8dxxToZ28B5M2SbA@mail.gmail.com>
References: <CABP7RbdscuxpBBQp1ydSQUri0Bg_aGSbm-ftF9Jnc-p_1DqnFg@mail.gmail.com> <792356c04b9e498c886252bc44904651@BY2PR03MB025.namprd03.prod.outlook.com> <CABkgnnXSc_7Gg6Ug8nuJEYRWYzoy7CFC1m8dxxToZ28B5M2SbA@mail.gmail.com>
Date: Fri, 26 Apr 2013 11:34:02 -0700
Message-ID: <CABP7RbdUDuyxTuQ=LguMoKqXNT=Qr=R03iJpypMtXRs1nK-Vzg@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary=001a11c1bc047cfec804db47c7a1
Received-SPF: pass client-ip=209.85.214.178; envelope-from=jasnell@gmail.com; helo=mail-ob0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.670, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UVnTY-0003si-Oh 8c35a0a3793ead20d1678e712e73781f
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/CABP7RbdUDuyxTuQ=LguMoKqXNT=Qr=R03iJpypMtXRs1nK-Vzg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17614
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>

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