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

Martin Thomson <> Fri, 26 April 2013 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7263921F9878 for <>; Fri, 26 Apr 2013 11:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kg5RVZFwEO3e for <>; Fri, 26 Apr 2013 11:29:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7666D21F984C for <>; Fri, 26 Apr 2013 11:29:52 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVnOa-0000bI-6o for; Fri, 26 Apr 2013 18:29:20 +0000
Resent-Date: Fri, 26 Apr 2013 18:29:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVnOV-0000Zn-61 for; Fri, 26 Apr 2013 18:29:15 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVnOU-0003ml-81 for; Fri, 26 Apr 2013 18:29:15 +0000
Received: by with SMTP id l13so939414wie.12 for <>; Fri, 26 Apr 2013 11:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=IRGqyOynOsyUwgfka8DjM4aGZtcJIUTtSJ2Oew6yCZI=; b=N5/VHGx9y//aVvlYd5iX7fjHKc8M6Mj7jabWD6jSMs38nzwYgYWrmSeMU5CYyBaY0M VmUrdBDSQT+bpzk+8QHaXZvdriTXg+pBBmZQOAbbjvD6fnpK0tgeJ3FA/Zp0NPZDzCT8 bezmwgW+a+Rz20TOAVUV4j89Eew4tuX9/hADvpJeA1VL/2W8bKVfnri5hfwnDvKyrrFZ sp9fd0/kFK6ZlpilBoEHD5R3wzo+2vYrEDyQONgR/+k1GPi1CVSzYYznb0ass9HQJ6Ls 7esGPR9ATWe3ZcIQYBBC/+E0byRznkiU2D+wDwszfSjpU8f/4Ai/O5B2I5AfEK8GDdCb UwMw==
MIME-Version: 1.0
X-Received: by with SMTP id hv3mr19896281wjb.32.1367000928120; Fri, 26 Apr 2013 11:28:48 -0700 (PDT)
Received: by with HTTP; Fri, 26 Apr 2013 11:28:47 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 26 Apr 2013 11:28:47 -0700
Message-ID: <>
From: Martin Thomson <>
To: Mike Bishop <>
Cc: James M Snell <>, "" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.696, 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: 1UVnOU-0003ml-81 7f9ccd83be760d7ca8d759ddb75a749e
Subject: Re: Design Issue: Unknown Frame Type MUST IGNORE rule and Denial of Service Attacks
Archived-At: <>
X-Mailing-List: <> archive/latest/17612
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 <> 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 []
> Sent: Friday, April 26, 2013 10:55 AM
> To:
> Subject: Design Issue: Unknown Frame Type MUST IGNORE rule and Denial of Service Attacks
> 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