Re: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)

MikkelFJ <notifications@github.com> Wed, 19 December 2018 15: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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8438F130E1F for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 07:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 m2x-Zdtf--re for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 07:15:05 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094D7130E3A for <quic-issues@ietf.org>; Wed, 19 Dec 2018 07:15:05 -0800 (PST)
Date: Wed, 19 Dec 2018 07:15:02 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545232503; bh=TF5p5OVxT0cA4ZylD7LuaE1+2N0PM9g7pN4L7VtpQEA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=aYN3rZecT53KXzqf5nez8SyLxSVSurgq0e3KRvDoZ/hA59o/Ol2YjqpXehAuh/OSm la9Z5Y9fGRWmdhKFyaZ11rCw9Vm6qj72VhZ76bWZEtSIcZVHubAMaMAcsMwrHCH415 3eeUtYQEiEPqHIgSQRU9Ya1g7k5bZlNM6ThdlVm4=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab1b255dbac611e9cb9995165c4dfdc658e571967892cf000000011832227692a169ce1753c928@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2192/448630342@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2192@github.com>
References: <quicwg/base-drafts/issues/2192@github.com>
Subject: Re: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c1a6076f0a1c_478c3ff6d94d45bc1982ad"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/ZecY3PIJyWaqx2B5XLgzQgQOtis>
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, 19 Dec 2018 15:15:11 -0000

Your point is that if the attacker optimistically ACKs a packet that it has all reasons to believe it will receive, but then packet gets dropped by some router, then the attacker cannot get its data later. Like crying wolf once too many. But if it doesn't care about the occasional loss, it can get better bandwidth, for example to starve out other users.

But if the loss is unlikely, and when it happens, is likely to just be a lost video frame, then you might watch better netflix on the dorm than all of your friends. If the connection has a vital loss, you just reconnect.

The real question here is the bandwidth can be manipulated enough to matter, while doing handshake. For example, one might want to drop RTT history once new data is available post handshake.

-- 
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/2192#issuecomment-448630342