[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
>
>