Re: [quicwg/base-drafts] Be more conservative about migration? (#2143)

Martin Thomson <notifications@github.com> Wed, 30 January 2019 05:16 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 6721313117A for <quic-issues@ietfa.amsl.com>; Tue, 29 Jan 2019 21:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 sAv34pXuNnHb for <quic-issues@ietfa.amsl.com>; Tue, 29 Jan 2019 21:16:15 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E7013117C for <quic-issues@ietf.org>; Tue, 29 Jan 2019 21:16:15 -0800 (PST)
Date: Tue, 29 Jan 2019 21:16:14 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1548825374; bh=wSTc1lDYkrh5rzvupNLDkM/WVQ3xEDvCDxKtSA9u/R4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zV9pkEKcjyrJDApEN4FQe9B9Hhyz+lg0oJDHkofwcTy2873ZQcU2ApAIQMqyv2BEk wMXmH+rjelGU8XNLE9Ib9KSYug9zrZvGSaF/Zs879L9xbD4Di3o8in/biFlIT96WbV S/CzcKrPPR0ZJf0vcO1IKl3utO5d+fpnFOJEBcXk=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab22395afd6e862c0bfdb062209248d546eb5d3de492cf000000011868f51e92a169ce17495be9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2143/458815073@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2143@github.com>
References: <quicwg/base-drafts/issues/2143@github.com>
Subject: Re: [quicwg/base-drafts] Be more conservative about migration? (#2143)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c51331eaabdd_67613fe84ccd45b42597b"; 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/HGN_8uds3fbAiEErkPX0shGzgxE>
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, 30 Jan 2019 05:16:17 -0000

Proposal from Tokyo:

Endpoints MUST validate new paths before using them.  In reaction to a migration they MUST continue using the old path until they receive new non-probing packets on the new path AND validation of that path is complete.  

Research question: Allow an exception in the case that the rebinding appears to be a NAT rebinding.  Heuristics are necessary here: e.g., a port-only change after a period of inactivity.  If we adopt the strict requirement, but learn that we get a lot of hitches from apparent migration, then we can find a way to relax the requirement.  If we allow this exception, then we have to address the problem of what to do when there are multiple such changes in a short period.  ==> Open this as an issue to track the research question.

Otherwise, eliminate the distinction between IP and port changes and just say "address change".

Stricter rules would close off the ability for an attacker to force a connection into a non-functioning state, even if that state is temporary.  The cost is that migration can result in a delay of a round trip or more.

(We might also want to know more about the severity of the attack.)

-- 
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/2143#issuecomment-458815073