Re: [multipathtcp] High-level design decisions /architecture

Joe Touch <touch@ISI.EDU> Mon, 02 November 2009 23:44 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: multipathtcp@core3.amsl.com
Delivered-To: multipathtcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514993A67F4 for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 15:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHWtt2AgAE5s for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 15:44:35 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 67ABC3A67D7 for <multipathtcp@ietf.org>; Mon, 2 Nov 2009 15:44:32 -0800 (PST)
Received: from [75.212.97.118] (118.sub-75-212-97.myvzw.com [75.212.97.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA2NiWYb003739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2009 15:44:35 -0800 (PST)
Message-ID: <4AEF6EE0.1080500@isi.edu>
Date: Mon, 02 Nov 2009 15:44:32 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: William Herrin <bill@herrin.us>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com>
In-Reply-To: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] High-level design decisions /architecture
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2009 23:44:36 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



William Herrin wrote:
...
> If we identify the connection by the original IP address even after
> that address is gone, effectively lying to the application, we can
> induce it to incorrect behavior. That can have security implications
> that may be hard to get a handle on.

This is the reason I raised the issue of "as goes the original IP
address, so goes the connection" during the Stockholm meeting.

I can see how to make things work when this is true, basically by
authenticating based on this address pair rather than the address pair
in the packet. If not, as noted above, there's an opportunity for
hijacking (if malicious), or at least unintended behavior (if not).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrvbuAACgkQE5f5cImnZrvgGgCg0qhfw/7eem7uIwnDD25uYCsJ
tzQAn3A0mqarLjV3BMNtL5otuZnFdfpO
=J+kU
-----END PGP SIGNATURE-----