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

ekr <notifications@github.com> Thu, 13 December 2018 13:41 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 B0D7C1271FF for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 05:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.46
X-Spam-Status: No, score=-4.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 BjawKTW0NIMM for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 05:41:06 -0800 (PST)
Received: from o11.sgmail.github.com (o11.sgmail.github.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E644126DBF for <quic-issues@ietf.org>; Thu, 13 Dec 2018 05:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=EMMUaqMcfaA8oRcJ5vnELeh7jnw=; b=g4BExVAflQH70oih 5W1DifmmPA77o9bgH3kAjjFEHbGwIVkg+kLes8gY+c9c7UY7ENtybvFOk3FmZVQv qs0mHxEnE11UrM/53XeFtWg5atGytVkaOwCVdoHIeS6WMR1rBQeWQF6PKBrI48kh EZpThbJqCqS3pIvITvPizT6DSVU=
Received: by filter0019p1iad2.sendgrid.net with SMTP id filter0019p1iad2-24572-5C12616F-4B 2018-12-13 13:41:03.796676886 +0000 UTC m=+224465.907790731
Received: from github-lowworker-e8fa9ff.cp1-iad.github.net (unknown []) by ismtpd0015p1iad2.sendgrid.net (SG) with ESMTP id wuYEA0FKTlKDcFBDn8wEog for <quic-issues@ietf.org>; Thu, 13 Dec 2018 13:41:03.755 +0000 (UTC)
Received: from github.com (localhost []) by github-lowworker-e8fa9ff.cp1-iad.github.net (Postfix) with ESMTP id B42B142036F for <quic-issues@ietf.org>; Thu, 13 Dec 2018 05:41:03 -0800 (PST)
Date: Thu, 13 Dec 2018 13:41:04 +0000
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb653e137b499f4c28b0117d76b930e99724e235992cf00000001182a236f92a169ce17495be9@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@github.com>
Subject: [quicwg/base-drafts] Be more conservative about migration? (#2143)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c12616fb271a_26de3fb691ed45b811962b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1RnBbXTVgmoK+355imhNM/UdoJmVm+jNc3c+ MLhtuI63Nh1dcc6N6c+zytsfELXyVVUi0wpmdyeUJvvr0kLojprFTcRo+7mC1V+3mbsU+g4hbtwsxK bdWBpr3bkz4TA5qG2JvHYaODtZpZ1h0zmmmgw6TH1TolmPGPBygjg4bfrA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/feUu3_G1EICac-0UTSSWLzvVSzg>
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: Thu, 13 Dec 2018 13:41:10 -0000

I've been reading through the migration mechanism and it seems to me
that assuming that a packet from a given IP address is evidence of
migration creates a pretty easy DoS attack from an on-path attacker.
Consider the case where we have a quiescent connection between A and B
and an on-path attacker and then B sends a packet to A.

In the diagram below, the notation [X:Y]: Z -> means a packet with a
source addr of A, a dest addr of B, and a payload of Z

A                       Attacker (Z)                  B

                                         <- [B:A]: Data
                     <- [B:A]: Data
[A:B]: ACK ->
                        [Z:B]: ACK ->

                                       X <- [B:Z]: Data
                                       X <- [B:Z]: Probe
As long as A doesn't try to send a data packet, B will continue to
think that A is at Z for the duration of the validation timer
(currently 3 RTO?) [0]. That's not the worst thing in the world, but
it's a pretty good cost/benefit for an on-path attacker who only has
to forge one packet; I'm not sure that that's a great design tradeoff
for a protocol where we're otherwise trying to stop on-path attacker
from interfering with the connection after the handshake completes.

The reason this works is the receipt of a packet from addr X is a
trigger for abandoning the previous path and trying migration. Another
time this can happen is at the tail of a client transmission,
though that will presumably recover faster.

At a high level, it seems like there are two major types of

1. Unknown migration (e.g., NAT re-binding)
2. Known migration (e.g., transferring from WiFi to 3G)

In the latter case, we can have the client give notice that it's
migrating, even if it doesn't know it's visible IP address, and have
the server refuse to change peer addresses unless it sees that
indication, so it's just the former case we have to deal with, and as
above. The present design does that but at the cost of creating the
situation above.

I wonder if we should be more conservative about initiating migration.
I don't have a fully worked out proposal, but here are some ideas:

- Send packets to both the original and new addresses during the
  validation period.
- If you receive an apparent migration that looks like a rebinding
  (e.g., same address, different port) within X seconds of a previous
  packet, then probe first (or in parallel as above).

- Have the client send some packet that indicates it thinks it's
  migrating (this seems tricky to get right)

[0] Note that if we were to allow migration on the client and the
server, even worse attacks are possible.

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