Re: [quicwg/base-drafts] Disconnect with Initial Injection (#1951)

Marten Seemann <notifications@github.com> Fri, 30 November 2018 03:02 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 EAE37126BED for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 19:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 OnBRIpiN3tvz for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 19:02:40 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153D012008A for <quic-issues@ietf.org>; Thu, 29 Nov 2018 19:02:40 -0800 (PST)
Date: Thu, 29 Nov 2018 19:02:39 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543546959; bh=m2IdF5ClKqXilV1euYhpJKMdKflHDcog0JMk4lFF7U0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MtgitJa4SiaPPryGDv3EiLnUWpO5NwkfVctTWnbhYzeUQTuGV20wzddohQS2A8ONI 4h8hWDVEidv+GHBz0PvjSIxBDU+fm1nQhFQE7IYLY4Zs8e8s1aJftkShlFt5XOvtbI JNQ7DnOwudNX/0YimlzqG5b95bfQryhCr1sOhojY=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab9866f99f0c546b9d1c59a77a449a57d69a570d3892cf0000000118186a4f92a169ce1678fc4e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1951/443074692@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1951@github.com>
References: <quicwg/base-drafts/issues/1951@github.com>
Subject: Re: [quicwg/base-drafts] Disconnect with Initial Injection (#1951)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c00a84f5ac1a_155a3ff3144d45bc2842e9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/zNoDlXJqUfsipabpghsJzrBIn0Q>
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: Fri, 30 Nov 2018 03:02:42 -0000

> The rules are easier to implement than what we have now in #2053, because the rules can be applied in one-path, rather than in two-pass (i.e. first check that the frames are valid then apply all of them).

I don't think that's true. Consider the case where a packet contains two ACK frames, the first of which is valid, the second one acknowledges an unsent packet. When processing the frames, you'd first happily process (and clean up your history of sent packets), only to encounter the second, invalid frame. What do you do now? You *could* unwind the effects of the first ACK frame, which at least in my implementation would a huge amount of complexity, or you could ignore the second ACK frame, accepting the fact that you acted upon a packet that was probably sent by an attacker.

-- 
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/1951#issuecomment-443074692