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

Kazuho Oku <notifications@github.com> Tue, 14 January 2020 13:08 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 26B9B120077 for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 05:08:32 -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 X1kl88qhzCIu for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 05:08:27 -0800 (PST)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D084C120025 for <quic-issues@ietf.org>; Tue, 14 Jan 2020 05:08:26 -0800 (PST)
Date: Tue, 14 Jan 2020 05:08:25 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579007305; bh=rd4ULbC5t8iYd/H24IDp+O2KJYO6dg8tJnK0FhH3Ovw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iAPy2n/hGjYM8pZoAIkytDpa9w4XTJCqUri5xxo1RQOczzSKO7VyxDssjozZqZxov 8wtqBVGRghtj8xOxqISonp44FTfEWOorEnJraW2AMfZEJnlTmEBhBY73GN345xWg04 nu58F4xJPV035o/ZJewh6196/xhtPvMe70ZjF4v8=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4XAYUV3DVWCMIMFGV4FLX4TEVBNHHCBFKYSE@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/342509782@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_5e1dbd49ca6cd_35873f98dd0cd964220748"; 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/MkRvLYsLHAwxLWas6k2HqWpqLmg>
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: Tue, 14 Jan 2020 13:08:32 -0000

kazuho commented on this pull request.

As pointed out in the inline comments, I am concerned that the proposed changes might be confusing.

As this section is about integrity protection, I think it might be better to delegate the discussion regarding how the server should use each type of tokens to the dedicated sections, namely [section 8.1.2 (Address Validation using Retry Packets)](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1.2), and [section 8.1.3 (Address Validation for Future Connections)](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1.3).

FWIW, we already state in section 8.1.3 that "validating the port is therefore unlikely to be successful", and that it "SHOULD have an expiration time." Therefore, the first sentence of this PR discussing NEW_TOKENS is redundant.

> @@ -1814,10 +1814,13 @@ 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

I am unsure if this SHOULD is necessary. As we suggest in the preceding paragraph, offloading state to client is just one way of implementing retries, the proposed text changes that to a recommendation.

If there is a need to better clarify the requirements on a server performing address validation, I think we should make changes to 8.1.2.

> @@ -1814,10 +1814,13 @@ 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 MUST ensure that
+replay of tokens is prevented or limited.  For instance, servers might limit the
+time over which a token is accepted.  Tokens sent in NEW_TOKEN frames MAY omit
+the client port and allow for use over a longer period.  Tokens MAY include
+additional information about clients to further narrow applicability or reuse.

The last two sentences are bit confusing to me, as it can be read as if a server must check that client IP address matches the original IP address stored in the NEW_TOKEN token.

-- 
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#pullrequestreview-342509782