Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)

Kazuho Oku <notifications@github.com> Tue, 29 October 2019 05:21 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659D1120044 for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 22:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level:
X-Spam-Status: No, score=-6.597 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCwbY_F1f6_j for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 22:21:46 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C468120043 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 22:21:46 -0700 (PDT)
Received: from github-lowworker-943b171.ac4-iad.github.net (github-lowworker-943b171.ac4-iad.github.net [10.52.22.59]) by smtp.github.com (Postfix) with ESMTP id 4E467A060D for <quic-issues@ietf.org>; Mon, 28 Oct 2019 22:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572326505; bh=dmScpTf2MHW0NuU78eHfvyoolWxQqgW3ZYoz0auyJHs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dQX6JfBqtQFEOihkGuJEAjBLXGK6mlEAcSjGKk3xUW3Dw28g/lCApkmGF7+BV6MOb iP2IvJ4ERPOsbggzwvb5LavteVaSWbiFRwAnbzfoWuvHYKDRX/Z3w+E27c4JRE28ii P3FZvJNXZKjyGU8k1eMV29ejSPjIdZm2nlc1SRPk=
Date: Mon, 28 Oct 2019 22:21:45 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4H66RT43CF2NE4H7N3YT7OTEVBNHHB5GVBRY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3161/547261010@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3161@github.com>
References: <quicwg/base-drafts/issues/3161@github.com>
Subject: Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db7cc693f522_75ac3fc8962cd960756c5"; 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/f5PMOyQB5xj5DAri3CqqeA0XGkg>
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: Tue, 29 Oct 2019 05:21:47 -0000

> In a strict sense, this means that a client can use N bytes to trigger the server to send 3N + epsilon bytes

I think this might be concerning, though I could well be wrong.

Consider the case of an attacker acting as a client, using the IP address of a victim as the source address. The attacker can spoof an Initial packet that carries a Client Hello and another Initial packet that carries an ACK for the server's Initial packet that carried the Server Hello. An attacker can build the correct second packet assuming that the server uses the DCID of the client's Initial packet as it's CID (or the CID is zero length), and that the server's first packet number can be guessed.

If that ACK contains a delay that indicate to the server that the RTT is very small (e.g., 1ms), then the PTO could be as small as that value. Then, if the server's connection timeout is say 1000ms, the server might send 1000 packets to the victim before dropping the connection.

Am I missing something?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3161#issuecomment-547261010