[quicwg/base-drafts] Stop requiring remote address to match during path validation (#2637)

erickinnear <notifications@github.com> Sat, 20 April 2019 00:54 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 11E3C1201EB for <quic-issues@ietfa.amsl.com>; Fri, 19 Apr 2019 17:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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_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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MZTGVq6y2-Rw for <quic-issues@ietfa.amsl.com>; Fri, 19 Apr 2019 17:54:45 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9061204FC for <quic-issues@ietf.org>; Fri, 19 Apr 2019 17:54:42 -0700 (PDT)
Date: Fri, 19 Apr 2019 17:54:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555721681; bh=d4kao1GG8w4wM+HO6gfemBdOWsejC+WTuBnw41hgWto=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=iOBHzCdrLihhiXzguzcUT/QE/g8fMZm3lvhJPnOZxCD1njFojWxvL2HMvtqa+EAIU pnEMx78glgG3di41xMaNC3okpEpGYkqEDelVYDBB5mLiWdmcbSTFZnuTukBBfMHEvY 4o7mkd51kHzUacwvNHV2w4IHAguOsjNuGYhKDY58=
From: erickinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6RONAE5BVVTOZOD4V2Y6QFDEVBNHHBT4WDAY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2637@github.com>
Subject: [quicwg/base-drafts] Stop requiring remote address to match during path validation (#2637)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cba6dd1a53cd_3f9a3f83108cd96c1866"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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/3IIn9Z3b_L6vELYAR-XBbP5wtv8>
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: Sat, 20 Apr 2019 00:54:54 -0000

This covers a few issues and attempts to clean up the normative text, further editorial rearranging is for a future PR, since we need to agree on some changes to the requirements first.

This removes the requirement that the remote address match between PATH_CHALLENGE/PATH_RESPONSE. 

As @martinduke said in #2582: 
>With PATH_CHALLENGE going out on both paths, these duplicate packets create four outcomes depending on which packets arrive first: both paths appear to be valid, the right path only is valid, the wrong path only is valid, or neither path is valid. The current requirement that the source address of PATH_RESPONSE matches the destination of the PATH_CHALLENGE can cause validation of the correct path to fail.

In #2580, there was some thought around performing path validation as a MUST "unless the endpoint has other means validate the validate the new path". This text is a little stronger, saying that you MUST validate unless you have already done so and remembered --some of the mitigations to attacks being described rely on a guarantee that validation occurs (and on both the old and the new paths). If folks wanted to have a completely separate mechanism for validating paths and considered their server/client to "know better", I'm not saying we should prohibit that, but such a mechanism would need to be analyzed in terms of the possible attacks.

So far, I *think* this closes out the changes to actual requirements that are necessary, and can be followed with an editorial pass to group the requirements in a way that's less confusing to first time readers (and thanks to @martinduke and others who gave this a close read in Prague!).

Closes #2582, #2580, #2579.
You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * Stop requiring source address to match on path responses
  * Merge branch 'master' into validation_source_address

-- File Changes --

    M draft-ietf-quic-transport.md (19)

-- Patch Links --


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