Re: [quicwg/base-drafts] Path validation should be done even for what looks like NAT rebinding (#2579)

erickinnear <notifications@github.com> Tue, 02 April 2019 01:36 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 781E112006E for <quic-issues@ietfa.amsl.com>; Mon, 1 Apr 2019 18:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45aX3X0qUeGV for <quic-issues@ietfa.amsl.com>; Mon, 1 Apr 2019 18:36:32 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCA4120021 for <quic-issues@ietf.org>; Mon, 1 Apr 2019 18:36:32 -0700 (PDT)
Date: Mon, 01 Apr 2019 18:36:31 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554168991; bh=ZbaWEtE9XfbDmM7zPI47i3IVEm51YVD5n1c/I6gunXc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xLZ+ZNInoGHLPMyem3tVAWCoNSz6thA95OmCuvikr5QMBuFN+kEem/DSyQFBtUWXv 0S7TcTwX851zoRqIlUf5l22jXvvSbHShwGCL/uePwe0LUpqd1Aw7sN9FuKxt1dRWwi iNUjNlntj2EAGicykzAGe7PfqzxbYGv13YjoTTEs=
From: erickinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab8abbd33d7b9acee938123b03f61b7f97f5904ed792cf0000000118ba7e9f92a169ce197da202@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2579/478809319@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2579@github.com>
References: <quicwg/base-drafts/issues/2579@github.com>
Subject: Re: [quicwg/base-drafts] Path validation should be done even for what looks like NAT rebinding (#2579)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ca2bc9f2f4d9_6dcd3f8ac20d45bc180ca"; 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/jCOFP2f9_SS0bdWNOUtgigiFOxE>
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, 02 Apr 2019 01:36:35 -0000

I have a branch out (PR coming soon) that removes this -- this part of the attack is something I think @martinduke was looking at a bit. 

To @DavidSchinazi's point, the change of CID is a really strong signal that the client intends to migrate, but we may want to move that into a note along with the section we have for "server should use heuristics/be smart about what to choose", since the definition in the text above doesn't really change the requirements on the server's behavior and that may confuse people. 

Whether or not we define it as migration really doesn't change a whole lot, since we say (or should say) that the server has to validate the new path anyways. In other words, always validate everything, unless it's something that's previously passed path validation and not the one you're migrating away from. 

@igorlord, note that the attack also relies on the attacker being able to race and beat the original client's packet to the server, but there's a whole section for that sort of attack (although I think we need to add to it a bit, or make a variant for the attacker overloading the NAT).

-- 
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/issues/2579#issuecomment-478809319