[quicwg/base-drafts] Receiving same New Connection ID twice (#1738)

Christian Huitema <notifications@github.com> Mon, 10 September 2018 23: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 DAA67130FF0 for <quic-issues@ietfa.amsl.com>; Mon, 10 Sep 2018 16:15:12 -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 wT0vJwkSZFzs for <quic-issues@ietfa.amsl.com>; Mon, 10 Sep 2018 16:15:11 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CDB130F8A for <quic-issues@ietf.org>; Mon, 10 Sep 2018 16:15:11 -0700 (PDT)
Date: Mon, 10 Sep 2018 16:15:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536621309; bh=5sTZfjt8ZVchLTL0P8gk/Iygn8K42rM38tqGjkme590=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=vjQyzuXQ+eDrp0cU3RzhEnzUyfEVXdu71gcON3UIB9okdWb8rnUgZvfBwjq6aEdxg KFlFGhec2cKwJbLqSRaKmxjkbDLCSFdtWsAGO4nR22c2W5hfOAHH5CY1KBwQq+Wnt4 Ub2D0LypAkKvOu7gVjDOiIxKV6x2IJGARHp8bsoE=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab60a236faef0543d59286fe6a771f069de1a532a292cf0000000117aebcfd92a169ce156349d9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1738@github.com>
Subject: [quicwg/base-drafts] Receiving same New Connection ID twice (#1738)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b96fafdc1f13_34153f88b18d45b821155e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/NKNOZJCP_EFfYwB-TQrQdSAS2LQ>
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: Mon, 10 Sep 2018 23:15:13 -0000

All frames are idempotent. I read that to mean that if the same New Connection ID frame is received twice, the second transmission should be a no-op. I assume that "same frame" here means the same connection ID, the same reset secret, and the same sequence if we still care about sequences. That much is fine. But what if the two frames are almost the same, say with the same connection ID and a different reset secret? Should the node update the previously received secret, or should it signal a protocol violation?

A variation of that happens if the node sends a "New Connection ID" frame, and the connection ID is the same as the source ID used by that node. I assume it is a protocol violation. Or is it just a nice way for clients to tell servers about their reset secret?

(I realize that there may be work in progress in some secret PR -- but then, please submit it to the main repo.)

-- 
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/1738