IETF Logo Mail Archive

Re: [quicwg/base-drafts] Stateless Reset packet sizes should not depend on the maximum connection ID length (#2869)

Martin Thomson <notifications@github.com> Thu, 04 July 2019 01:34 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 08A0F1200E7 for <quic-issues@ietfa.amsl.com>; Wed, 3 Jul 2019 18:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 CmA5LcHw_-bE for <quic-issues@ietfa.amsl.com>; Wed, 3 Jul 2019 18:34:06 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C911200D7 for <quic-issues@ietf.org>; Wed, 3 Jul 2019 18:34:05 -0700 (PDT)
Date: Wed, 03 Jul 2019 18:34:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1562204044; bh=iJrySXQ/bGUn5tnqeIWyj5BUFhRxxMnAihPGuFYs82k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yLxnTu0yRXDOxf+5QXo6fQe7lO3No95FlWVikXHhpM2ljINYSrbrMELqUQF6gL4m8 UYcWdue6zZC3IC9gPhmJ+Fgd0D7TGYekcVi9U/9+xtfwJSlSptI5n3Gbr9pFu7UWm1 hy3A0BJAA1gWfJS+r+e6GJuE2EkLMQxPFiL35bBM=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK64AD2UTNGQSRL57DV3FKFAZEVBNHHBXHYKMI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2869/508306030@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2869@github.com>
References: <quicwg/base-drafts/issues/2869@github.com>
Subject: Re: [quicwg/base-drafts] Stateless Reset packet sizes should not depend on the maximum connection ID length (#2869)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d1d578ca93c4_74d3f9332ccd9682127b1"; 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/Pz1LtegqkHa6ts9k5hCweh9bqWA>
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: Thu, 04 Jul 2019 01:34:08 -0000

I believe that we wanted to avoid the observer from being able to recognize resets.  The idea being that recognition preceded some sort of action.  The worst I can imagine here is dropping state prior to the endpoints being ready for that.  For instance, forwarding the packet and then dropping NAT bindings immediately, which - if that packet is lost - might leave the recipient with the belief that it still has an active connection when it does not.

The point being that we're attempting to avoid facilitation of bad behaviour.

Perhaps you can talk about the way in which you perceive reliability being reduced.  39 isn't exactly a very large number, nor is it a hard limit.

-- 
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/2869#issuecomment-508306030

v2.23.0 | Report a Bug | By Email