[quicwg/base-drafts] Connection migration failure mode (#1278)

Martin Thomson <notifications@github.com> Mon, 09 April 2018 10: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 22017126D05 for <quic-issues@ietfa.amsl.com>; Mon, 9 Apr 2018 03:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oqdf5mYc3aGw for <quic-issues@ietfa.amsl.com>; Mon, 9 Apr 2018 03:16:38 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.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 4EEA2124207 for <quic-issues@ietf.org>; Mon, 9 Apr 2018 03:16:38 -0700 (PDT)
Date: Mon, 09 Apr 2018 03:16:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1523268997; bh=QHnMYgmcIjgweTXeICwaVD8tfUGxKreZSEBgoS6h+Gk=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=D+yzgyEjepkovURI3/DBXVwHJ3VknDdgQ37BTRug+lngT3N9twK+U1TiFC2gj9Z5A AJVjMtLD2QofRGaBMbT9m21mi1eWd3aOupzbX3jI7SV9g54jQQ5ijBWsF+E9vaS8im PsVxF9geUChQ6yiXG6UAi8hs4pO4BTFovPpc3m5w=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab930d9afbc231360466dcbcdda2b99befe0cbc05392cf0000000116e2ff8592a169ce129ff705@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1278@github.com>
Subject: [quicwg/base-drafts] Connection migration failure mode (#1278)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5acb3d85b0eb1_47823f9d71610f2824048d"; 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/vPJN8l1ezvefUIEaG4Q6tiyi7EA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 09 Apr 2018 10:16:40 -0000

>From @ekr,

> To add to my previous comment about attacks, in cases where one side has totally migrated (i.e., only one path is valid), then an attacker can also mess things up pretty severely by just spoofing a response to a PATH_CHALLENGE. I.e.,
> 1. I am receiving packets from A
> 2. A migrates and so sends me a packet from A'
> 3. I send a PATH_CHALLENGE to A'
> 4. If the attacker forwards the next packet from A' (likely a PATH_RESPONSE) but rewrites the source address to B, then I will consider the validation failed.

What is especially pernicious here is that the migration might not be voluntary, and so there is no option to repair the condition.  Multiple challenges make this harder to effect the attack, but that's all.  Currently the draft seems to imply that a single PATH_RESPONSE like this is enough to cause the path to be marked as invalid, see #1277.

We could decide that this is akin to messing with a handshake and decide to limit our reaction to this to documentating it.  But we could also try to make the process more robust, with the caution that pulling on this thread potentially leads to a reiteration of RFC 5245.

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