Return-Path: 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 ; 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 ; 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 ; 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 Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.27 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 02:28:54 -0000 ----==_mimepart_5b553d62670b4_26703ff3770d45bc1970f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > 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 ----==_mimepart_5b553d62670b4_26703ff3770d45bc1970f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm not trying to ensure a reset is sent in response to an ACK-only pa= cket.

A misunderstanding then...

I'm suggesting the reset packet attempt to look like an ACK-only packe= t

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 fo= r 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 pack= et is 4 octets of ACK, 2 octets of short header, and 16 octets of authent= ication 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 y= ou want to ensure that the packet you send is plausible, you have to assu= me that they used the maximum size. That's 18 octets. Then add the shor= t header, a PING frame (which is smaller than the ACK), and authenticatio= n 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.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub,= or mute the thread.3D""

= ----==_mimepart_5b553d62670b4_26703ff3770d45bc1970f8--