Re: [quicwg/base-drafts] Stateless Reset Eternal Ping Pong (#1443)

Martin Thomson <notifications@github.com> Mon, 23 July 2018 02:28 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 EF400130DD2 for <quic-issues@ietfa.amsl.com>; Sun, 22 Jul 2018 19:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 LCtpIMfqMvkS for <quic-issues@ietfa.amsl.com>; Sun, 22 Jul 2018 19:28:51 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86676130DC9 for <quic-issues@ietf.org>; Sun, 22 Jul 2018 19:28:51 -0700 (PDT)
Date: Sun, 22 Jul 2018 19:28:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1532312930; bh=YPHroUR+V1PCJARbZjIsZwhEIRaF2osG6V278b6dFBs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=usd7lyQDYnsnzPfdgiulrc2q7ziGn520jSL6tPir4gsNRMG7lN457w9FljcCStd3J 1q6yB3rutxcRJUqrsCz+FDmHG2n6JEXzbfq2/vBFFqlC8q+qspegt7eIcS9PGp50BA mf64GyVrk+oT2mNKbh+F+m+2Wt+OPZZIqGIlgoZ0=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7fd7f281c78735fb237ff255479382a3a316055392cf00000001176cff6292a169ce13c7a591@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1443/406921495@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1443@github.com>
References: <quicwg/base-drafts/issues/1443@github.com>
Subject: Re: [quicwg/base-drafts] Stateless Reset Eternal Ping Pong (#1443)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b553d62670b4_26703ff3770d45bc1970f8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/rb-C2rVoqNMK0tOmVpXGN3cOPho>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 23 Jul 2018 02:28:54 -0000

> I'm not trying to ensure a reset is sent in response to an ACK-only packet.

A misunderstanding then...

> I'm suggesting the reset packet attempt to look like an ACK-only packet 

Yes, but I think that you're missing the point that an ACK-only packet for ANY connection is potentially much bigger than an ACK-only packet for THIS connection.

Let's say that your peer chose no connection ID (this would be common for a server that sends a stateless reset).  Then a minimal ACK-only packet is 4 octets of ACK, 2 octets of short header, and 16 octets of authentication tag.  That's 22 octets.  4 octets of ACK is unlikely, but it is a size you might expect to see early in a connection.

Now if you don't know how long the connection ID of your peer is and you want to ensure that the packet you send is plausible, you have to assume that they used the maximum size.  That's 18 octets.  Then add the short header, a PING frame (which is smaller than the ACK), and authentication tag.  That leads to 37 octets - the number in the draft.

While it might be valid to send less than 37 octets, you can't be sure that it always will be.

-- 
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/1443#issuecomment-406921495