Re: [quicwg/base-drafts] Allow use of token after client address changes (#3307)
Kazuho Oku <notifications@github.com> Wed, 18 December 2019 06: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 15CA31200C7 for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 22:28:37 -0800 (PST)
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 TijE7jFE-JGV for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 22:28:34 -0800 (PST)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22381208B4 for <quic-issues@ietf.org>; Tue, 17 Dec 2019 22:28:34 -0800 (PST)
Received: from github-lowworker-cd7bc13.ac4-iad.github.net (github-lowworker-cd7bc13.ac4-iad.github.net [10.52.25.102]) by smtp.github.com (Postfix) with ESMTP id 0705D6E0A3B for <quic-issues@ietf.org>; Tue, 17 Dec 2019 22:28:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576650514; bh=VlqtPG+oHrkXaFheOjrLRA13K6i/ac986w4VzfKD+/U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=e6rPJJ4Y+KmJVg5Yd9YbUnKyMFmfjv1aqdhgr8o8jah7cIw8NftMpJ/w0RYDj7kY1 cMVAzTUPXU11y+UdAN/A8H01ix+W43WlH/+OBpiMoCZ692R+wZcODzBOwhtA/j57eD Poj2EYrrKMiYFQTHFC3+K9Lt5xC2JGunS8A2gqKA=
Date: Tue, 17 Dec 2019 22:28:33 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYF2PLCW3JUMWQDAAN4A34ZDEVBNHHCAJ5MJU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3307/566887333@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3307@github.com>
References: <quicwg/base-drafts/issues/3307@github.com>
Subject: Re: [quicwg/base-drafts] Allow use of token after client address changes (#3307)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df9c711ed829_565a3fa6482cd96c30972e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/sPChHwN4VzTUE1H0Lb-3j5NoUW8>
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: Wed, 18 Dec 2019 06:28:37 -0000
Agreed. Just to give one example, it'd make sense for a server to issue a NEW_TOKEN token containing two addresses, if the client is using one path to communicate while having another path being probed and validated. Note also that it is difficult to implement the MUST NOT that exists now. Consider the case where a client receives a NEW_TOKEN frame during or after path migration. Is the client expected to bind the token to the old IP address? Or the new address? It is hard to tell the intention of the server. -- 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/3307#issuecomment-566887333
- [quicwg/base-drafts] Allow use of token after cli… Jana Iyengar
- Re: [quicwg/base-drafts] Allow use of token after… Kazuho Oku
- Re: [quicwg/base-drafts] Allow use of token after… ianswett
- Re: [quicwg/base-drafts] Allow use of token after… ianswett
- Re: [quicwg/base-drafts] Allow use of token after… Martin Thomson