[quicwg/base-drafts] Backoff of CONNECTION_CLOSE needs to be a MUST (#3095)

Kazuho Oku <notifications@github.com> Wed, 16 October 2019 00:15 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E971C12083A for <quic-issues@ietfa.amsl.com>; Tue, 15 Oct 2019 17:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AbRom_pVjHbo for <quic-issues@ietfa.amsl.com>; Tue, 15 Oct 2019 17:15:23 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDAA12082D for <quic-issues@ietf.org>; Tue, 15 Oct 2019 17:15:23 -0700 (PDT)
Date: Tue, 15 Oct 2019 17:15:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571184922; bh=igiooreqM7a1PzT3H0otoqDaZFujh2ZdgR3EbKDDq3U=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=yzcY1n1D4pOKYWCT30CRmxzONkstOTMlxDS50gQxz8QiJ4yJCaSV1+RnogarKQIdH DdG+XQsW1bngmUNzJkybL2pXaOmULSbk1YHWlORVIJw7iSW60In8cvP8HJVYa1hiiy EEs1smrhjQ+IVrky/9Yu14L6IZDT0NuXdf+bZ2mc=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYCO4AYTMOYLEGG77N3WOQ2VEVBNHHB4QEEV4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3095@github.com>
Subject: [quicwg/base-drafts] Backoff of CONNECTION_CLOSE needs to be a MUST (#3095)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5da6611a34765_4cc83fde386cd968162929"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/HeT5gkIZflJIZccpvzBtjR831SU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2019 00:15:25 -0000

At the moment, the backoff is merely a recommendation. Quoting from [section 10.3](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.3): _endpoints SHOULD limit the number of packets they generate containing a CONNECTION_CLOSE frame._

However, there is a DoS attack vector unless we make this a MUST, as an attacker can create bounce of packets carrying CONNECTION_CLOSE frames between two servers.

Consider the case where you have two servers (A, B) that use the original DCIDs supplied by the client as the server CIDs.

The attacker sends the following two Initial packets:
* srcaddr=A, destaddr=B, srcCID=X, destCID=Y
* srcaddr=B, destaddr=A, srcCID=Y, destCID=X

Both of the two packets would contain an invalid payload.

Then, both server A and server B would enter the CLOSING state sending CONNECTION_CLOSE frame to the peer. While in the CLOSING state, the specification allows endpoints to respond to packets from peer without decrypting them. Therefore, this creates a ping-pong.

To prevent this type of attack, I think we need to change "SHOULD limit" of the quoted text to "MUST limit". The alternative might be to forbid servers adopting the DCID given by the clients as their server CIDs.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: