IETF Logo Mail Archive

Re: [quicwg/base-drafts] Clarify the state a client stores with a token (#3150)

ianswett <notifications@github.com> Thu, 24 October 2019 22:14 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 2FBBC120073 for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 15:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_28=1.404, 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 X7HzbjDDUQeG for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 15:14:24 -0700 (PDT)
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 788EC120026 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 15:14:24 -0700 (PDT)
Received: from github-lowworker-2e54e43.va3-iad.github.net (github-lowworker-2e54e43.va3-iad.github.net [10.48.17.27]) by smtp.github.com (Postfix) with ESMTP id 7F109C607A8 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 15:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571955263; bh=DIRf3CgkcjJQxtlaacdS8dROCC42C2Y1sgg4+UM9ubc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=J0RxNpVQMlWRsgJjVY3eH8V/1WfVuejIOFuoXODwcy/hmAgJdj3cyhdMaMAwFp28u c7IFdgWK0jZMsi7Ak+1mc6bsI1S5FW+C/qvjwmKHg8jFZTA6sV9R4THCAWginCWOSk Fp/ljwq5l9r0l1NU5syFCDKO/LBAMtzz7lA88m14=
Date: Thu, 24 Oct 2019 15:14:23 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3AYA6NNW6TJKJA5EF3X5RM7EVBNHHB5B4MBE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3150/review/306894277@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3150@github.com>
References: <quicwg/base-drafts/pull/3150@github.com>
Subject: Re: [quicwg/base-drafts] Clarify the state a client stores with a token (#3150)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db2223f70be6_63a83fcd96acd96c653d6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/fP2lejCfrRaQxB3Lxfo7ypq_eg4>
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, 24 Oct 2019 22:14:27 -0000

ianswett commented on this pull request.



> @@ -1697,7 +1697,8 @@ connections; validating the port is therefore unlikely to be successful.
 If the client has a token received in a NEW_TOKEN frame on a previous connection
 to what it believes to be the same server, it SHOULD include that value in the
 Token field of its Initial packet.  Including a token might allow the server to
-validate the client address without an additional round trip.
+validate the client address without an additional round trip.  A client MAY use
+a token from any previous connection to that server.

Do we need any caveats about how older tokens might not be able to be processed?  Or maybe tokens should have an expiry time, which would be a design change... :(

-- 
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/pull/3150#pullrequestreview-306894277

v2.23.0 | Report a Bug | By Email