[multipathtcp] This shim6 part of the answer (was Re: High-level design decisions /architecture
marcelo bagnulo braun <marcelo@it.uc3m.es> Tue, 03 November 2009 09:42 UTC
Return-Path: <marcelo@it.uc3m.es>
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 D34F73A698F for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 01:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.469
X-Spam-Level:
X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 eLa6V+0vivQf for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 01:42:31 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id BAEB33A680F for <multipathtcp@ietf.org>; Tue, 3 Nov 2009 01:42:30 -0800 (PST)
Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.227]) by smtp02.uc3m.es (Postfix) with ESMTP id 67E396C0F18; Tue, 3 Nov 2009 10:42:49 +0100 (CET)
Message-ID: <4AEFFB0C.8010702@it.uc3m.es>
Date: Tue, 03 Nov 2009 10:42:36 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/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>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16986.006
Cc: multipathtcp@ietf.org
Subject: [multipathtcp] This shim6 part of the answer (was Re: 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: Tue, 03 Nov 2009 09:42:33 -0000
I am splitting the answer in the shim6 part and the mptcp part, so that people not interested in shim6 (which i guess are plenty since this is the mptcp ml, can simply drop this email) William Herrin escribió: > On Mon, Nov 2, 2009 at 6:45 PM, marcelo bagnulo braun > <marcelo@it.uc3m.es> wrote: > >>> I'm concerned about this idea. One of the corner cases where shim6 >>> falls apart is: once the connection migrates away from the original >>> addresses, how do the endpoints decide whether a new connection >>> request for the original addresses means the migrated addresses or the >>> current holder of the addresses? Think: FTP. >>> >>> >> could you expand on this? >> I wasn't aware shim6 falls apart in any case neither this particular >> approach... >> > > Hi Marcelo, > > Consider the following scenario: > > Host A comes online with 1.2.3.4. > Host A requests a new TCP connection to 5.6.7.8. > Established with host B at 5.6.7.8. > Host B adds 8.7.6.5 > Host B removes 5.6.7.8 > Host C comes online with 5.6.7.8. > Host A requests a new TCP connection to 5.6.7.8. > > Which host does A connect to? > > first of all Shim6, as one may guess from the acronym :-) only works for IPv6 identifiers. So, non of them apply to shim6 Second, due to large space of IPv6 iid, the situation you describe there is very unlikely to happen by a coincidence. It may be due to an attack, where the attacker is host C, agree? assuming that above were IPv6 addresses, the host you actually connect to depends whether you are using forking or not. But in general, you will be connecting to host B, as long as the shim6 state is on host A > If the answer is C, protocols like FTP which initiate multiple TCP > connections to the same IP address fail once an endpoint gives up its > original address. That'll also impact web browsers which employ dns > pinning. > > If the answer is B, I can hijack hotmail's IPs with respect to your > mail server for the few fractions of a second it takes to establish > and move a TCP connection over to an IP address I legitimately > control. You'll then indefinitely send subsequent hotmail-addressed > email to me. If I diligently pass it on to hotmail, you may never even > know. > No, In order to do that you would have had to generate an HBA for that address, which in computationally impossible in a reasonable timer frame. So, no hijacking attacks in shim6 If you do think there is the possibility of a hijacking attack, please describe it. So, i don't see shim6 breaking in this case... Regards, marcelo > 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. > > Regards, > Bill Herrin > >
- [multipathtcp] High-level design decisions /archi… philip.eardley
- Re: [multipathtcp] High-level design decisions /a… marcelo bagnulo braun
- Re: [multipathtcp] High-level design decisions /a… William Herrin
- Re: [multipathtcp] High-level design decisions /a… marcelo bagnulo braun
- Re: [multipathtcp] High-level design decisions /a… William Herrin
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Mark Handley
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Lars Eggert
- Re: [multipathtcp] High-level design decisions /a… Yoshifumi Nishida
- [multipathtcp] This shim6 part of the answer (was… marcelo bagnulo braun
- [multipathtcp] The MPTCP part (was Re: High-level… marcelo bagnulo braun
- Re: [multipathtcp] High-level design decisions /a… marcelo bagnulo braun
- Re: [multipathtcp] High-level design decisions /a… Scott Brim
- Re: [multipathtcp] High-level design decisions /a… Scott Brim
- Re: [multipathtcp] High-level design decisions /a… Scott Brim
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Costin Raiciu
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Mark Handley
- Re: [multipathtcp] High-level design decisions /a… Costin Raiciu
- Re: [multipathtcp] High-level design decisions /a… Costin Raiciu
- Re: [multipathtcp] High-level design decisions /a… Ford, Alan
- Re: [multipathtcp] High-level design decisions /a… Ford, Alan
- Re: [multipathtcp] High-level design decisions /a… Ford, Alan
- Re: [multipathtcp] High-level design decisions /a… Scott Brim
- Re: [multipathtcp] High-level design decisions /a… marcelo bagnulo braun
- Re: [multipathtcp] High-level design decisions /a… William Herrin
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Yoshifumi Nishida
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… Mark Handley
- Re: [multipathtcp] High-level design decisions /a… Ford, Alan
- Re: [multipathtcp] High-level design decisions /a… Ford, Alan
- Re: [multipathtcp] High-level design decisions /a… Yoshifumi Nishida
- Re: [multipathtcp] High-level design decisions /a… Costin Raiciu
- Re: [multipathtcp] High-level design decisions /a… philip.eardley
- Re: [multipathtcp] High-level design decisions /a… Lars Eggert
- Re: [multipathtcp] High-level design decisions /a… William Herrin
- Re: [multipathtcp] High-level design decisions /a… Yoshifumi Nishida
- Re: [multipathtcp] High-level design decisions /a… Scott Brim
- Re: [multipathtcp] High-level design decisions /a… Costin Raiciu
- Re: [multipathtcp] High-level design decisions /a… Yoshifumi Nishida
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… William Herrin
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… William Herrin
- Re: [multipathtcp] High-level design decisions /a… Joe Touch
- Re: [multipathtcp] High-level design decisions /a… William Herrin
- Re: [multipathtcp] High-level design decisions /a… Joe Touch