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

Kazuho Oku <notifications@github.com> Wed, 12 February 2020 02:07 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 6C09212086A for <quic-issues@ietfa.amsl.com>; Tue, 11 Feb 2020 18:07:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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, URIBL_BLOCKED=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 s_KDUna3cB4E for <quic-issues@ietfa.amsl.com>; Tue, 11 Feb 2020 18:07:37 -0800 (PST)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD9E120863 for <quic-issues@ietf.org>; Tue, 11 Feb 2020 18:07:37 -0800 (PST)
Received: from github-lowworker-b19c547.va3-iad.github.net (github-lowworker-b19c547.va3-iad.github.net [10.48.17.66]) by smtp.github.com (Postfix) with ESMTP id 6973BA0BE9 for <quic-issues@ietf.org>; Tue, 11 Feb 2020 18:07:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581473256; bh=iOgGBUWi7tgfodFl1peYn9gWmzJJ08f4ZwRvVIQfHSs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Dzbvmn1j2bDMqIsX9XoORxXUE2njBl57TksaHGisL4mSqvIhkDxjeCJBlLTcROO00 C6WdRrvf8MuzMeWBNpnjl4vovHeeMevK6pjofKw1+DaIb/2SyJMlVOXp+eLJs8z4sE m1NHNif8apvxXAw730/WN8ddXDNZ4BWbL5VYL7v0=
Date: Tue, 11 Feb 2020 18:07:36 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZDHTEGPC5IRTBIS6F4KCIGREVBNHHCBFKYSE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3327/review/357146700@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3327@github.com>
References: <quicwg/base-drafts/pull/3327@github.com>
Subject: Re: [quicwg/base-drafts] What needs to be checked for address validation (#3327)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e435de85a03f_779c3f9571acd960591d6"; 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/PhZakG2ErPcF7DFM6nK52VY-vQk>
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, 12 Feb 2020 02:07:39 -0000

kazuho commented on this pull request.



> @@ -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.

Thank you for the response. To me it seems that what we are actually looking for is an upper-case SHOULD that limits the scope of NEW_TOKEN tokens to one IP address. IMO that is the basis that we need to state. In addition, we can talk about when the scope can be wider, but that is less important.

I am not sure where the upper-case SHOULD should go into. It could be this section or [section 8.1.3](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-address-validation-for-futu). But assuming that it is the former, maybe we can replace this paragraph with something as simple as: "Tokens sent in NEW_TOKEN frames SHOULD include information that allows the server to verify if the client address is stable."

WDYT?

-- 
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/3327#discussion_r378005184