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

marcelo bagnulo braun <marcelo@it.uc3m.es> Tue, 03 November 2009 09:48 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 DA8943A6979 for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 01:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.479
X-Spam-Level:
X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 gtew58vKG-EK for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 01:48:14 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id EB2713A687D for <multipathtcp@ietf.org>; Tue, 3 Nov 2009 01:48:13 -0800 (PST)
Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.227]) by smtp02.uc3m.es (Postfix) with ESMTP id 4F5A56C0DF2; Tue, 3 Nov 2009 10:48:32 +0100 (CET)
Message-ID: <4AEFFC63.10202@it.uc3m.es>
Date: Tue, 03 Nov 2009 10:48:19 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu>
In-Reply-To: <4AEF781E.4070009@isi.edu>
Content-Type: text/plain; charset="UTF-8"; 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: 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: Tue, 03 Nov 2009 09:48:15 -0000

Joe Touch escribió:
>
>> Security
>>
>> ======
>>
>>     * exchange a token in the initial SYN for the MPTCP connection, and
>>       include the token when subflows /paths are added to the connection
>>           o [Question: Is the same token used whether the sender or
>>             receiver (of the MPTCP connection) adds the subflow? Is the
>>             same technique used for removing subflows? And closing
>>             connections, ie DATA FIN?]
>>     
>
> Let's please not call this "security". Call it a flow identifier, but
> it's trivial for on-path attackers to see, and anything small enough to
> be appropriate for a SYN is likely to be too small to prevent exhaustion
> attacks.
>
>   
>>     * security mechanisms will not interfere with end-to-end
>>       authentication etc 
>>     
>
> Yes. Specifically IMO there ought to be a TCP-AO mode supported - e.g.,
> using socketpair of the original connection for the pseudoheader used
> for MAC calculation.
>
>   
It would make sense to contrast the protection provided by TCP-AO witht 
he threats identified in the threat analysis and see how many of these 
it solves.

Regards, marcelo