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

Martin Thomson <notifications@github.com> Fri, 14 February 2020 05:21 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 6740B12006F for <quic-issues@ietfa.amsl.com>; Thu, 13 Feb 2020 21:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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: 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 MsL1307qZo4S for <quic-issues@ietfa.amsl.com>; Thu, 13 Feb 2020 21:21:19 -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 4442812006D for <quic-issues@ietf.org>; Thu, 13 Feb 2020 21:21:19 -0800 (PST)
Received: from github-lowworker-5825cd4.ac4-iad.github.net (github-lowworker-5825cd4.ac4-iad.github.net [10.52.22.68]) by smtp.github.com (Postfix) with ESMTP id 265C3A0A0E for <quic-issues@ietf.org>; Thu, 13 Feb 2020 21:21:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581657678; bh=ruHE6Qjpx/TH06cofq/OOQz+tsVDW8+HsQq5O1pBAL8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fwR1jGD05t4X2X95NvHl4448ya6VhFVn4Ze4XAMZtB2IAIBXTFa5TE953vKBmpOFP YeMhgM9/cJmVquadFvwjmRWjpdsTJbcAPy+abQ7cmNRE0/dCO3RnlrESDXXiUl0Elh j3UyT7gFykhspSvEKIob/5nB/8qDtX/ff7JsWehE=
Date: Thu, 13 Feb 2020 21:21:18 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4Y546N2IHJTROA2VV4KNQM5EVBNHHCBFKYSE@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/358717573@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_5e462e4e16e5e_17d43fe909ccd9685899a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/57NTC1Wa6vEgxHh4TIX8ndrg4mo>
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: Fri, 14 Feb 2020 05:21:21 -0000

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

(Oops, missed this comment.)

I didn't want to recommend that the IP address remain constant as NAT does not always limit itself to port changes over time.  However, I suspect that the right answer in that case is to not assume that the address is valid.  NATs that use multiple addresses often serve many clients, so the risk of amplification is heightened.

That said, I do like the brevity of what you have.  I'll use that, but I do want to keep the Retry sentence (that's important).

-- 
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_r379254861