Re: [quicwg/base-drafts] What needs to be checked for address validation (#3327)

Kazuho Oku <> Wed, 12 February 2020 01:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E889012085D for <>; Tue, 11 Feb 2020 17:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nl-nogMaiHR2 for <>; Tue, 11 Feb 2020 17:20:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4093120086 for <>; Tue, 11 Feb 2020 17:20:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 93C5A660C24 for <>; Tue, 11 Feb 2020 17:20:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581470412; bh=j+FearRvkBuyR2rbfS/QsH+5zBK6e2J+7PiqhVTjRPw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bIVgn6VvtIiPn54lDsY+ybhxwRbSm8NLiD7Ascs9VtChG0O48NCrqKPrlzmOyp7QE PJi3qtHSEjFVFcWfZLddy7fAfo9gGlnIpYFaeHPyWxebTgX0UNaFPfs0l1MLBFeEue ZEARB81LxnqyqiVKlbmQWjqNrgQKsPZ4JCLhfvUg=
Date: Tue, 11 Feb 2020 17:20:12 -0800
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3327/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] What needs to be checked for address validation (#3327)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4352cc83e6f_67cd3ffab58cd968103663"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
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: Wed, 12 Feb 2020 01:20:16 -0000

kazuho commented on this pull request.

@martinthomson Thank you for the ping. LGTM modulo the point below.

> @@ -1829,10 +1829,21 @@ tokens that would be accepted by the server.  Only the server requires access to
 the integrity protection key for tokens.
 There is no need for a single well-defined format for the token because the
-server that generates the token also consumes it.  A token could include
-information about the claimed client address (IP and port), a timestamp, and any
-other supplementary information the server will need to validate the token in
-the future.
+server that generates the token also consumes it.  Tokens sent in Retry packets
+SHOULD include information that allows the server to verify that the source IP
+address and port in client packets remains constant.
+Servers might use tokens from NEW_TOKEN in deciding not to send a Retry packet,
+even if the client address has changed.  A token that was provided in
+NEW_TOKEN cannot be used for address validation if the client address is not the
+same, though servers MAY allow for the possibility of changes arising from new
+mappings at a NAT.

Would it make sense to change "though..." to something like: "unless the server can assume that the address change happened within the same network (e.g., NAT rebinding)."?

The reason I suggest this change is because client address might change due to reasons other than NAT, for example, DHCP or SLAAC.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: