From philip.eardley@bt.com Sat Jul 13 14:41:17 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC82021F8653 for ; Sat, 13 Jul 2013 14:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7cqiFdL0qso for ; Sat, 13 Jul 2013 14:41:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6906621F84B1 for ; Sat, 13 Jul 2013 14:41:13 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 13 Jul 2013 22:41:11 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.228]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Sat, 13 Jul 2013 22:41:11 +0100 From: To: Date: Sat, 13 Jul 2013 22:41:10 +0100 Thread-Topic: New Version Notification for draft-eardley-mptcp-implementations-survey-02.txt Thread-Index: Ac5/TiQKZ1pjDGgMT7ePyXQu4lzrFwAwfgLr Message-ID: <9510D26531EF184D9017DF24659BB87F34CABC36C2@EMV65-UKRD.domain1.systemhost.net> References: <20130712222118.7822.71049.idtracker@ietfa.amsl.com> In-Reply-To: <20130712222118.7822.71049.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multipathtcp] FW: New Version Notification for draft-eardley-mptcp-implementations-survey-02.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 21:41:18 -0000 I=92m delighted to say that we had four replies to our MPTCP implementation= survey. Thank-you very much indeed to the people who replied, and of cours= e the teams who did all the hard work implementing and testing. The fact th= at there are (at least!) four independent implementations is a real tribute= to everyone - that mptcp isl on the path to widespread deployment and impr= oving the internet. Thank-you to those who had the original ideas, develope= d the standard, coded the prototypes, provided critical feedback.... In the I-D I tried to summarise all the replies, whilst also including the = full replies. During the mptcp meeting in Berlin we=92ll discuss how we use all this info= rmation to help progress the protocol on the standards track.=20 We also have an mptcp slot during the tsvarea meeting, so that will be a go= od opportunity to spread the good news.=20 Enjoy! Phil ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: 12 July 2013 23:21 To: Eardley,PL,Philip,TUB8 R; Philip Eardley; Philip Eardley Subject: New Version Notification for draft-eardley-mptcp-implementations= -survey-02.txt A new version of I-D, draft-eardley-mptcp-implementations-survey-02.txt has been successfully submitted by Philip Eardley and posted to the IETF repository. Filename: draft-eardley-mptcp-implementations-survey Revision: 02 Title: Survey of MPTCP Implementations Creation date: 2013-07-12 Group: Individual Submission Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-eardley-mptcp-im= plementations-survey-02.txt Status: http://datatracker.ietf.org/doc/draft-eardley-mptcp-implem= entations-survey Htmlized: http://tools.ietf.org/html/draft-eardley-mptcp-implementat= ions-survey-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-eardley-mptcp-imp= lementations-survey-02 Abstract: This document presents results from the survey to gather information from people who have implemented MPTCP, in particular to help progress the protocol from Experimental to Standards track. The document currently includes answers from four teams: a Linux implementation from UCLouvain, a FreeBSD implementation from Swinburne, an anonymous implementation in a commercial OS, and a NetScalar Firmware implementation from Citrix Systems, Inc. Thank- you! In summary, we have four independent implementations of all the MPTCP signalling messages, with the exception of address management, and some interoperabiity testing has been done by the other three implementations with the 'reference' Linux implementation. So it appears that the RFC is (at least largely) clear and correct. On address management, we have only one implementation of ADD_ADDR with two teams choosing not to implement it. We have one implementation of the working group's coupled congestion control (RFC6356) and none of the MPTCP-aware API (RFC6897). The main suggested improvements are around o how MPTCP falls back (if the signalling is interrupted by a middlebox): (1) corner cases that are not handled properly, (2) at the IETF, the MPTCP community should work with middlebox vendors, either to reduce or eliminate the need for fallback or to understand the middlebox interactions better. o security: both better MPTCP security (perhaps building on SSL) and a lighter weight mechanism, preferably both in one mechanism. It is hoped that the next version can include information from any other implementations. If you are an implementer and want to contribute your answers, please see the -01 version of this document for a blank survey ready to be filled in. The IETF Secretariat From marcelo@it.uc3m.es Mon Jul 15 23:30:29 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D6221F9BA2 for ; Mon, 15 Jul 2013 23:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.141 X-Spam-Level: X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGXErbKiA1vy for ; Mon, 15 Jul 2013 23:30:25 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0511421F9BAB for ; Mon, 15 Jul 2013 23:30:23 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B7084CB5941 for ; Tue, 16 Jul 2013 08:30:22 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost24.it.uc3m.es (dummyhost24.it.uc3m.es [163.117.139.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id A99F7C34BEC for ; Tue, 16 Jul 2013 08:30:22 +0200 (CEST) Message-ID: <51E4E881.1080206@it.uc3m.es> Date: Tue, 16 Jul 2013 08:30:25 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Multipath TCP Mailing List References: <20130714200737.6455.95956.idtracker@ietfa.amsl.com> In-Reply-To: <20130714200737.6455.95956.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130714200737.6455.95956.idtracker@ietfa.amsl.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Tue, 16 Jul 2013 08:30:22 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20018.005 Subject: [multipathtcp] Fwd: I-D Action: draft-bagnulo-mptcp-attacks-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 06:30:29 -0000 Hi,

We have submitted a new draft discussing some residual attacks we identified in MPTCP spec.
Comments are welcome.

Regards, marcelo


-------- Mensaje original --------
Asunto: I-D Action: draft-bagnulo-mptcp-attacks-00.txt
Fecha: Sun, 14 Jul 2013 13:07:37 -0700
De: internet-drafts@ietf.org
Responder a: internet-drafts@ietf.org
Para: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : Analysis of MPTCP residual threats and possible fixes
	Author(s)       : Marcelo Bagnulo
                          Christoph Paasch
                          Fernando Gont
                          Olivier Bonaventure
                          Costin Raiciu
	Filename        : draft-bagnulo-mptcp-attacks-00.txt
	Pages           : 16
	Date            : 2013-07-14

Abstract:
   This documents performs an analysis of the residual threats for MPTCP
   and explores possible solutions to them.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attacks

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nishida@sfc.wide.ad.jp Wed Jul 17 16:28:23 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BA921F995B for ; Wed, 17 Jul 2013 16:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLrLELiFUHxz for ; Wed, 17 Jul 2013 16:28:22 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id B551921F994B for ; Wed, 17 Jul 2013 16:28:22 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1A95C2780C0 for ; Thu, 18 Jul 2013 08:28:12 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id v20so2038078lbc.17 for ; Wed, 17 Jul 2013 16:28:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=p3qeSBjEIiLxgLnHO5kyXAO5VLSkrmHq5WisRqWLX4s=; b=RDSRaFCI0Ag/ppUp1PQev7A6xbwpfPbf5NIF6FpirO3fX089FL0CdVW2j4mJejJsra MMnvOv48IOptfX9ID2mu/BMV2ZyBdVAk8h0E5Yolx0q3bxiQDP7btxHZrT5RgZuv1agB I69CEZ5PchnuvZvtV3yxrxTq5BZGGjytd2T0BOyPy/h3nbNdntCYtciCJG1yYrvZLnEV tIellNotBQic9MvmKbo3pJP4+o3Ry2RJFUf9Xyul/lKRmaUaIxYn6Oq8Jmsw7ogdzLyy rfgJrLHkJl0dOpI+OnVS1ZmefhtVmvX5EmSbfRknagpXbfrXc132pnVZNXGsj6VIS83B lUVQ== MIME-Version: 1.0 X-Received: by 10.152.1.102 with SMTP id 6mr3991879lal.49.1374103690330; Wed, 17 Jul 2013 16:28:10 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Wed, 17 Jul 2013 16:28:10 -0700 (PDT) Date: Wed, 17 Jul 2013 16:28:10 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] draft agenda for Berlin meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 23:28:23 -0000 Hello, . We've uploaded draft agenda for Berlin meeting on the following URL. http://tools.ietf.org/wg/mptcp/agenda -- Yoshifumi & Phil From krishna.khanal2@citrix.com Wed Jul 24 01:05:51 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67C511E839D for ; Wed, 24 Jul 2013 01:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY8o5J3-ssCE for ; Wed, 24 Jul 2013 01:05:46 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8948911E839B for ; Wed, 24 Jul 2013 01:05:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,734,1367971200"; d="scan'208";a="3889030" Received: from sinpex01cl03.citrite.net ([10.151.46.34]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 24 Jul 2013 08:05:42 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.235]) by SINPEX01CL03.citrite.net ([169.254.3.145]) with mapi id 14.02.0342.004; Wed, 24 Jul 2013 16:05:41 +0800 From: Krishna Khanal To: multipathtcp Thread-Topic: MP_CAP Final ack drop and fallback behavior Thread-Index: AQHOiESWGIUqyZLNGkanGr0qg2ELzw== Date: Wed, 24 Jul 2013 08:05:40 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.240.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:05:52 -0000 Hi, For stateless implementation of MP_CAPABLE flow, there is no way to contin= ue with MPTCP if the final ack of 3-way MP_CAP handshake is dropped or the = data packet is received before the MP_CAP ack due to out of ordering of the= packet in the network. Only way to continue with the transaction is to fal= lback to regular TCP and there is a pretty much chance of happening this in= the real network. So, there is always a requirement of fallback even if th= e middle devices supports and understands MPTCP. Is there any thought on making MP_CAP final ack reliable like MP_JOIN final= ack or including MP_CAP final ack options with the data packet along with = DSS packet until the ack is received? Second, option may not be suitable be= cause it consumes all the option space and first option also tend to increa= se the handshake duration and block the request by atleast an RTT. Any thought? Regards, Krishna From christoph.paasch@uclouvain.be Wed Jul 24 02:12:05 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F87A11E83E6 for ; Wed, 24 Jul 2013 02:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUIwuNTj9jgo for ; Wed, 24 Jul 2013 02:12:00 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 46BDC11E83EA for ; Wed, 24 Jul 2013 02:12:00 -0700 (PDT) Received: from localhost (wifi-secure1-829.sri.ucl.ac.be [130.104.123.61]) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTP id 34F5D11FEAE; Wed, 24 Jul 2013 11:11:38 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 34F5D11FEAE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1374657098; bh=GL5vPM3ZE9A/XoT5hVePGbczS4B0ad9X17veD3YiEi8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=ykWbpfmOt9zL0ONuwYhcnKlc2HP1YcXcJgeRF6Ci+m+Kh5c/GvKRppVEtd01UXAl8 YyoIOb+/l5OcKTmwm+y3CR+ZThhnuyY5u+wW0z27iUyAZsFowuSHAwO1QUr7eVgCId JGsEUWAcKhpyIxSrpXgxhPHvRTkMSHnZ21+iL/zQ= Date: Wed, 24 Jul 2013 11:08:55 +0200 From: Christoph Paasch To: Krishna Khanal Message-ID: <20130724090855.GA11135@cpaasch-mac> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-SGSI-MailScanner-ID: 34F5D11FEAE.AC74C X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-0.87, requis 5, ALL_TRUSTED -2.00, BAYES_00 -1.60, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VERIFIED -1.00, FSL_HELO_NON_FQDN_1 0.00, HELO_LOCALHOST 3.83) X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:12:05 -0000 Hello Krishna, On 24/07/13 - 08:05:40, Krishna Khanal wrote: > Hi, For stateless implementation of MP_CAPABLE flow, there is no way to > continue with MPTCP if the final ack of 3-way MP_CAP handshake is dropped > or the data packet is received before the MP_CAP ack due to out of > ordering of the packet in the network. Only way to continue with the > transaction is to fallback to regular TCP and there is a pretty much > chance of happening this in the real network. So, there is always a > requirement of fallback even if the middle devices supports and > understands MPTCP. > > Is there any thought on making MP_CAP final ack reliable like MP_JOIN > final ack or including MP_CAP final ack options with the data packet along > with DSS packet until the ack is received? Second, option may not be > suitable because it consumes all the option space and first option also > tend to increase the handshake duration and block the request by atleast > an RTT. > > Any thought? In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in a reliable way, as it is done today for the third ACK with the MP_JOIN. But this got removed due to the additional RTT: http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html Then, the status of the draft was for some time that MPTCP was doing reliable transmission of the third ACK+MP_CAPABLE, but allowed sending data before the arrival of this third ACK. However, this did not help, as early arrival of data (prior to the third ACK) will still trigger a fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack as it is for today: http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html It would not be possible to combine MP_CAPABLE with the DSS-option and still use stateless connection establishment: MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 bytes (Subflow-seq) + 4 bytes (Data-length + csum) = 16 bytes So, there are 4 more bytes left. This would mean that we cannot put the Timestamp-option, which is required for stateless connection establishment. Cheers, Christoph From krishna.khanal2@citrix.com Wed Jul 24 21:51:24 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC2621F9A1B for ; Wed, 24 Jul 2013 21:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYVhYGuSEJwr for ; Wed, 24 Jul 2013 21:51:20 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id B45FE21F9A2A for ; Wed, 24 Jul 2013 21:51:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,740,1367971200"; d="scan'208";a="3912285" Received: from sinpex01cl03.citrite.net ([10.151.46.34]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 25 Jul 2013 04:51:15 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.235]) by SINPEX01CL03.citrite.net ([169.254.3.145]) with mapi id 14.02.0342.004; Thu, 25 Jul 2013 12:51:14 +0800 From: Krishna Khanal To: Christoph Paasch Thread-Topic: [multipathtcp] MP_CAP Final ack drop and fallback behavior Thread-Index: AQHOiESWGIUqyZLNGkanGr0qg2ELz5lzBDOAgAHMAsA= Date: Thu, 25 Jul 2013 04:51:13 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> In-Reply-To: <20130724090855.GA11135@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.240.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 04:51:24 -0000 Thanks Christoph for the information. What about setting a flag in the SYNACK packet to tell the peer about the r= eliability of the final ack? If the administrator thinks it is ok to put a = client on hold for an RTT, then they can set the flag in the synack packet = and force client to do reliable transmission of final ack. Regards, Krishna -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Wednesday, July 24, 2013 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior Hello Krishna, On 24/07/13 - 08:05:40, Krishna Khanal wrote: > Hi, For stateless implementation of MP_CAPABLE flow, there is no way to > continue with MPTCP if the final ack of 3-way MP_CAP handshake is dropped > or the data packet is received before the MP_CAP ack due to out of > ordering of the packet in the network. Only way to continue with the > transaction is to fallback to regular TCP and there is a pretty much > chance of happening this in the real network. So, there is always a > requirement of fallback even if the middle devices supports and > understands MPTCP. >=20 > Is there any thought on making MP_CAP final ack reliable like MP_JOIN > final ack or including MP_CAP final ack options with the data packet alon= g > with DSS packet until the ack is received? Second, option may not be > suitable because it consumes all the option space and first option also > tend to increase the handshake duration and block the request by atleast > an RTT. >=20 > Any thought? In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in a reliable way, as it is done today for the third ACK with the MP_JOIN. But this got removed due to the additional RTT: http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html Then, the status of the draft was for some time that MPTCP was doing reliable transmission of the third ACK+MP_CAPABLE, but allowed sending data before the arrival of this third ACK. However, this did not help, as early arrival of data (prior to the third ACK) will still trigger a fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack as it is for toda= y: http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html It would not be possible to combine MP_CAPABLE with the DSS-option and stil= l use stateless connection establishment: MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 bytes (Subflow-seq) + 4 bytes (Data-length + csum) =3D 16 bytes So, there are 4 more bytes left. This would mean that we cannot put the Timestamp-option, which is required for stateless connection establishment. Cheers, Christoph From jessica.r.fox@gmail.com Wed Jul 24 22:36:57 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D54421F9966 for ; Wed, 24 Jul 2013 22:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79GFPvY8KYrZ for ; Wed, 24 Jul 2013 22:36:57 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C7FCF21F8895 for ; Wed, 24 Jul 2013 22:36:56 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1231091wgh.14 for ; Wed, 24 Jul 2013 22:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5OZRPkXsOhlxdszunbPDfbmY0Hq7D3h7X+maoUWQJCM=; b=KGAO6MXWUQHZn6y/5POzlzEHorUhkkXjCUkJJli60TxNnNUQd2gLoZ8xtflFfpUE2R xlaOwhj2nJWDiOeHxOdouOYd07RxDhtnNGFdDoV2jXBlMu1b7Coo0BgM7fXV6rzazb4+ 34+m0ls+qcUkU3sZZayP97FqO5NVild2JX/w+Rj4tc0OoV5pALanosctypoKnMl6D1Ou 2asfRAOh1Gp0yuN2kMnLxYAdQdI0jF0dSiG1k5H5r/IabcUi1tqUu7nac6JNEMefuvPh DVYi6ulNB1zbj0mlv4MO7bKsfyGY2UONEYxudOKWKZEX8mT0CZp09HBJWXX4jI6Da5Fm xPwg== MIME-Version: 1.0 X-Received: by 10.180.11.146 with SMTP id q18mr662881wib.50.1374730615572; Wed, 24 Jul 2013 22:36:55 -0700 (PDT) Received: by 10.194.21.102 with HTTP; Wed, 24 Jul 2013 22:36:55 -0700 (PDT) Date: Wed, 24 Jul 2013 23:36:55 -0600 Message-ID: From: Jessica Fox To: multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=001a11c24d1600cefa04e24f6a31 X-Mailman-Approved-At: Wed, 24 Jul 2013 23:59:20 -0700 Cc: "agarwal.sharud@gmail.com" Subject: [multipathtcp] MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 05:45:19 -0000 --001a11c24d1600cefa04e24f6a31 Content-Type: text/plain; charset=ISO-8859-1 To whom it may concern: My name is Jessica Fox, and I am currently doing a research project related to MPTCP. I noticed that on this page http://datatracker.ietf.org/wg/mptcp/charter/ you have several milestones listed. However, since the December 2012 milestone, and the April 2013 milestones haven't been updated I was wondering if the progress for the implementation of MPTCP is still on track with what is listed? Thank you, -- Jessica Fox University of Texas at Austin Cockrell School of Engineering, Electrical Vice President, Eta Kappa Nu jessica.r.fox@gmail.com --001a11c24d1600cefa04e24f6a31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To whom it may concern:

My name is Jess= ica Fox, and I am currently doing a research project related to MPTCP. I no= ticed that on this page=A0http://datatracker.ietf.org/wg/mptcp/charter/=A0you have sever= al milestones listed. However, since the December 2012 milestone, and the A= pril 2013 milestones haven't been updated I was wondering if the progre= ss for the implementation of MPTCP is still on track with what is listed?

Thank you,=A0


--
Jessica Fox
University of Texas at Austin
Cockrell School of Engineering, Elect= rical
Vice President, Eta Kappa Nu
--001a11c24d1600cefa04e24f6a31-- From philip.eardley@bt.com Thu Jul 25 00:46:20 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC0D21F99D0 for ; Thu, 25 Jul 2013 00:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.95 X-Spam-Level: X-Spam-Status: No, score=-102.95 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn07A-X7OdPe for ; Thu, 25 Jul 2013 00:46:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3D57721F9A16 for ; Thu, 25 Jul 2013 00:46:15 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 25 Jul 2013 08:46:14 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.253]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 25 Jul 2013 08:46:13 +0100 From: To: , Date: Thu, 25 Jul 2013 08:46:13 +0100 Thread-Topic: MPTCP Thread-Index: Ac6I+PnPy+Jn0FktQBegfXjhENm7TwAEUKeA Message-ID: <9510D26531EF184D9017DF24659BB87F35B803349F@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35B803349FEMV65UKRDdoma_" MIME-Version: 1.0 Cc: agarwal.sharud@gmail.com Subject: Re: [multipathtcp] MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:46:21 -0000 --_000_9510D26531EF184D9017DF24659BB87F35B803349FEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jessica Thanks for your interest in multipath TCP. There is lots of good news on mptcp implementation -summarised in http://da= tatracker.ietf.org/doc/draft-eardley-mptcp-implementations-survey/ You're right that the charter milestones need a bit of updating, but progre= ss on mptcp implementations (towards getting mptcp in real deployment and i= n everyone's OS) is very promising. Best wishes phil From: Jessica Fox [mailto:jessica.r.fox@gmail.com] Sent: 25 July 2013 06:37 To: multipathtcp@ietf.org Cc: agarwal.sharud@gmail.com; Eardley,PL,Philip,TUB8 R; nishida@sfc.wide.ad= .jp; martin.stiemerling@neclab.eu Subject: MPTCP To whom it may concern: My name is Jessica Fox, and I am currently doing a research project related= to MPTCP. I noticed that on this page http://datatracker.ietf.org/wg/mptcp= /charter/ you have several milestones listed. However, since the December 2= 012 milestone, and the April 2013 milestones haven't been updated I was won= dering if the progress for the implementation of MPTCP is still on track wi= th what is listed? Thank you, -- Jessica Fox University of Texas at Austin Cockrell School of Engineering, Electrical Vice President, Eta Kappa Nu jessica.r.fox@gmail.com --_000_9510D26531EF184D9017DF24659BB87F35B803349FEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jessica

 

Thanks for your interest in multipath= TCP.

There is lots of good news on mptcp implem= entation –summarised in http://datatracker.ietf.org/doc/= draft-eardley-mptcp-implementations-survey/

You’re right that the charter milestones need a bit of updating, but= progress on mptcp implementations (towards getting mptcp in real deploymen= t and in everyone’s OS) is very promising.

 

Best wishes

= phil

 

From: Jessica Fox [mailt= o:jessica.r.fox@gmail.com]
Sent: 25 July 2013 06:37
To: multipathtcp@ietf.org
Cc: agarwal.sharud@gmail.com; Eardley,PL,= Philip,TUB8 R; nishida@sfc.wide.ad.jp; martin.stiemerling@neclab.eu
S= ubject: MPTCP

 

To whom it may concern:

 

My name is Jessica Fox, and I am currently doing a research pr= oject related to MPTCP. I noticed that on this page http://datatracker.ietf.org/wg/mptc= p/charter/ you have several milestones listed. However, since the = December 2012 milestone, and the April 2013 milestones haven't been updated= I was wondering if the progress for the implementation of MPTCP is still o= n track with what is listed?

=  

Thank you, <= /o:p>


 

-- <= o:p>

Jessica Fox

University of Texas at Austin
Cockrell Schoo= l of Engineering, Electrical

= Vice President, Eta Kappa Nu

= --_000_9510D26531EF184D9017DF24659BB87F35B803349FEMV65UKRDdoma_-- From christoph.paasch@uclouvain.be Thu Jul 25 00:46:39 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7421F9A4C for ; Thu, 25 Jul 2013 00:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reLskYwJbQur for ; Thu, 25 Jul 2013 00:46:35 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5421F9A30 for ; Thu, 25 Jul 2013 00:46:34 -0700 (PDT) Received: from localhost (wifi-secure1-829.sri.ucl.ac.be [130.104.123.61]) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTP id 6DDDB183411; Thu, 25 Jul 2013 09:46:24 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 6DDDB183411 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1374738384; bh=Jtc4TZHGQju5f0l64QDwJGoYJZpwYCuwvizvpz5J2K8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=Rf0ke5xFsUsscvdX9lD0CsoiFSjP+CfSlNgtZdIMNuZu7/7gZbgmyHtFYHWQtsMiX SCWJHvB2Ihqgd6fkIu3WcUNvHj9uxPtfRhKGFIhYx2OuPHdFyDzZcTiUfmKdalsfgx udInm3iqX5P3QJL3asQun8RNdaohPcNOhLzmxXg0= Date: Thu, 25 Jul 2013 09:46:24 +0200 From: Christoph Paasch To: Krishna Khanal Message-ID: <20130725074624.GA3897@cpaasch-mac> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-SGSI-MailScanner-ID: 6DDDB183411.AA02E X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.729, requis 5, ALL_TRUSTED -2.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VERIFIED -1.00, FSL_HELO_NON_FQDN_1 0.00, HELO_LOCALHOST 3.83) X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:46:40 -0000 Hello Krishna, On 25/07/13 - 04:51:13, Krishna Khanal wrote: > What about setting a flag in the SYNACK packet to tell the peer about the > reliability of the final ack? If the administrator thinks it is ok to put > a client on hold for an RTT, then they can set the flag in the synack > packet and force client to do reliable transmission of final ack. I'm not against this flag. But, it should just be a signal of the server for the client, saying "I'm doing stateless connection establishment". In the end, it's the client who will decide if he wants to trade this additional RTT for assured MPTCP-connectivity or not. Cheers, Christoph > -----Original Message----- From: Christoph Paasch > [mailto:christoph.paasch@uclouvain.be] Sent: Wednesday, July 24, 2013 2:39 > PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP > Final ack drop and fallback behavior > > Hello Krishna, > > On 24/07/13 - 08:05:40, Krishna Khanal wrote: > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way to > > continue with MPTCP if the final ack of 3-way MP_CAP handshake is > > dropped or the data packet is received before the MP_CAP ack due to out > > of ordering of the packet in the network. Only way to continue with the > > transaction is to fallback to regular TCP and there is a pretty much > > chance of happening this in the real network. So, there is always a > > requirement of fallback even if the middle devices supports and > > understands MPTCP. > > > > Is there any thought on making MP_CAP final ack reliable like MP_JOIN > > final ack or including MP_CAP final ack options with the data packet > > along with DSS packet until the ack is received? Second, option may not > > be suitable because it consumes all the option space and first option > > also tend to increase the handshake duration and block the request by > > atleast an RTT. > > > > Any thought? > > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in a > reliable way, as it is done today for the third ACK with the MP_JOIN. But > this got removed due to the additional RTT: > > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html > > > Then, the status of the draft was for some time that MPTCP was doing > reliable transmission of the third ACK+MP_CAPABLE, but allowed sending > data before the arrival of this third ACK. However, this did not help, as > early arrival of data (prior to the third ACK) will still trigger a > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack as > it is for today: > > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html > > > It would not be possible to combine MP_CAPABLE with the DSS-option and > still use stateless connection establishment: > > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 > bytes (Subflow-seq) + 4 bytes (Data-length + csum) = 16 bytes > > So, there are 4 more bytes left. This would mean that we cannot put the > Timestamp-option, which is required for stateless connection > establishment. > > > > Cheers, Christoph From krishna.khanal2@citrix.com Thu Jul 25 01:26:39 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A6C21F99FA for ; Thu, 25 Jul 2013 01:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HTuflMDxwxO for ; Thu, 25 Jul 2013 01:26:34 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6202221F9A0C for ; Thu, 25 Jul 2013 01:26:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,742,1367971200"; d="scan'208";a="3916472" Received: from sinpex01cl03.citrite.net ([10.151.46.34]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 25 Jul 2013 08:26:26 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.235]) by SINPEX01CL03.citrite.net ([169.254.3.145]) with mapi id 14.02.0342.004; Thu, 25 Jul 2013 16:26:25 +0800 From: Krishna Khanal To: Christoph Paasch Thread-Topic: [multipathtcp] MP_CAP Final ack drop and fallback behavior Thread-Index: AQHOiESWGIUqyZLNGkanGr0qg2ELz5lzBDOAgAHMAsD//69EAIAAj13A Date: Thu, 25 Jul 2013 08:26:24 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> <20130725074624.GA3897@cpaasch-mac> In-Reply-To: <20130725074624.GA3897@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.240.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 08:26:39 -0000 Hi Christoph, Yes server sending its willingness but letting client decide on the reliab= ility of final ack looks better.=20 In my experience, there is significant fallback due to receiving data packe= t before final ack, though I don't have exact data to share here. Anyone ha= ving any experience with this? Regards, Krishna -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Thursday, July 25, 2013 1:18 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior Hello Krishna, On 25/07/13 - 04:51:13, Krishna Khanal wrote: > What about setting a flag in the SYNACK packet to tell the peer about the > reliability of the final ack? If the administrator thinks it is ok to put > a client on hold for an RTT, then they can set the flag in the synack > packet and force client to do reliable transmission of final ack. I'm not against this flag. But, it should just be a signal of the server for the client, saying "I'm doing stateless connection establishment". In the end, it's the client who will decide if he wants to trade this additional RTT for assured MPTCP-connectivity or not. Cheers, Christoph > -----Original Message----- From: Christoph Paasch > [mailto:christoph.paasch@uclouvain.be] Sent: Wednesday, July 24, 2013 2:3= 9 > PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP > Final ack drop and fallback behavior >=20 > Hello Krishna, >=20 > On 24/07/13 - 08:05:40, Krishna Khanal wrote: > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way to > > continue with MPTCP if the final ack of 3-way MP_CAP handshake is > > dropped or the data packet is received before the MP_CAP ack due to out > > of ordering of the packet in the network. Only way to continue with the > > transaction is to fallback to regular TCP and there is a pretty much > > chance of happening this in the real network. So, there is always a > > requirement of fallback even if the middle devices supports and > > understands MPTCP. > >=20 > > Is there any thought on making MP_CAP final ack reliable like MP_JOIN > > final ack or including MP_CAP final ack options with the data packet > > along with DSS packet until the ack is received? Second, option may not > > be suitable because it consumes all the option space and first option > > also tend to increase the handshake duration and block the request by > > atleast an RTT. > >=20 > > Any thought? >=20 > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in = a > reliable way, as it is done today for the third ACK with the MP_JOIN. But > this got removed due to the additional RTT: >=20 > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html >=20 >=20 > Then, the status of the draft was for some time that MPTCP was doing > reliable transmission of the third ACK+MP_CAPABLE, but allowed sending > data before the arrival of this third ACK. However, this did not help, as > early arrival of data (prior to the third ACK) will still trigger a > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack a= s > it is for today: >=20 > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html >=20 >=20 > It would not be possible to combine MP_CAPABLE with the DSS-option and > still use stateless connection establishment: >=20 > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 > bytes (Subflow-seq) + 4 bytes (Data-length + csum) =3D 16 bytes >=20 > So, there are 4 more bytes left. This would mean that we cannot put the > Timestamp-option, which is required for stateless connection > establishment. >=20 >=20 >=20 > Cheers, Christoph From christoph.paasch@uclouvain.be Thu Jul 25 01:30:37 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D34A21F9CE7 for ; Thu, 25 Jul 2013 01:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j6CLQfoTQyc for ; Thu, 25 Jul 2013 01:30:19 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 68D4221F9B4C for ; Thu, 25 Jul 2013 01:30:10 -0700 (PDT) Received: from localhost (haproxy2.sipr.ucl.ac.be [130.104.5.120]) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTP id 68DD618348B; Thu, 25 Jul 2013 10:29:57 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 68DD618348B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1374740997; bh=RTFmtPnCKPgdgnHI3R+xgRgFkGRf4m7ilNcO8KjKWD8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=vGXDiq1xPUxqsBnujmf75/N7mrEg3RqlqeBaqIefjbXvTpjZYKtyFTJj4cDAI/Peb CSzBbaG2cEl7PcPcK8Dt2tUwgp2T1khxQDUCDQTuvDTrR6g/yjDmzP8LrkUL4n90Yk a8Ymn3LYCGywJC+QG/uY5eHGLYqt9KSG/vJcEiNA= Date: Thu, 25 Jul 2013 10:29:57 +0200 From: Christoph Paasch To: Krishna Khanal Message-ID: <20130725082957.GD3897@cpaasch-mac> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> <20130725074624.GA3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-SGSI-MailScanner-ID: 68DD618348B.AC8BC X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.729, requis 5, ALL_TRUSTED -2.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VERIFIED -1.00, FSL_HELO_NON_FQDN_1 0.00, HELO_LOCALHOST 3.83) X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 08:30:38 -0000 Hello, On 25/07/13 - 08:26:24, Krishna Khanal wrote: > Hi Christoph, Yes server sending its willingness but letting client decide > on the reliability of final ack looks better. > > In my experience, there is significant fallback due to receiving data > packet before final ack, though I don't have exact data to share here. > Anyone having any experience with this? are you using the Linux implementation as a client? I would be surprised if you have so many fallbacks, because you would need a drop of the third ACK. Thus you maybe have a high loss-rate on the path (?). Cheers, Christoph > > Regards, Krishna > > > -----Original Message----- From: Christoph Paasch > [mailto:christoph.paasch@uclouvain.be] Sent: Thursday, July 25, 2013 1:18 > PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP > Final ack drop and fallback behavior > > Hello Krishna, > > On 25/07/13 - 04:51:13, Krishna Khanal wrote: > > What about setting a flag in the SYNACK packet to tell the peer about > > the reliability of the final ack? If the administrator thinks it is ok > > to put a client on hold for an RTT, then they can set the flag in the > > synack packet and force client to do reliable transmission of final ack. > > I'm not against this flag. But, it should just be a signal of the server > for the client, saying "I'm doing stateless connection establishment". In > the end, it's the client who will decide if he wants to trade this > additional RTT for assured MPTCP-connectivity or not. > > > Cheers, Christoph > > > > -----Original Message----- From: Christoph Paasch > > [mailto:christoph.paasch@uclouvain.be] Sent: Wednesday, July 24, 2013 > > 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] > > MP_CAP Final ack drop and fallback behavior > > > > Hello Krishna, > > > > On 24/07/13 - 08:05:40, Krishna Khanal wrote: > > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way > > > to continue with MPTCP if the final ack of 3-way MP_CAP handshake is > > > dropped or the data packet is received before the MP_CAP ack due to > > > out of ordering of the packet in the network. Only way to continue > > > with the transaction is to fallback to regular TCP and there is a > > > pretty much chance of happening this in the real network. So, there is > > > always a requirement of fallback even if the middle devices supports > > > and understands MPTCP. > > > > > > Is there any thought on making MP_CAP final ack reliable like MP_JOIN > > > final ack or including MP_CAP final ack options with the data packet > > > along with DSS packet until the ack is received? Second, option may > > > not be suitable because it consumes all the option space and first > > > option also tend to increase the handshake duration and block the > > > request by atleast an RTT. > > > > > > Any thought? > > > > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in > > a reliable way, as it is done today for the third ACK with the MP_JOIN. > > But this got removed due to the additional RTT: > > > > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html > > > > > > Then, the status of the draft was for some time that MPTCP was doing > > reliable transmission of the third ACK+MP_CAPABLE, but allowed sending > > data before the arrival of this third ACK. However, this did not help, > > as early arrival of data (prior to the third ACK) will still trigger a > > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack > > as it is for today: > > > > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html > > > > > > It would not be possible to combine MP_CAPABLE with the DSS-option and > > still use stateless connection establishment: > > > > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 > > bytes (Subflow-seq) + 4 bytes (Data-length + csum) = 16 bytes > > > > So, there are 4 more bytes left. This would mean that we cannot put the > > Timestamp-option, which is required for stateless connection > > establishment. > > > > > > > > Cheers, Christoph From krishna.khanal2@citrix.com Thu Jul 25 01:35:47 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B296A21F9CC3 for ; Thu, 25 Jul 2013 01:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzmrZuN2ESK7 for ; Thu, 25 Jul 2013 01:35:43 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id E00EA21F9CE7 for ; Thu, 25 Jul 2013 01:35:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,742,1367971200"; d="scan'208";a="3916762" Received: from sinpex01cl01.citrite.net ([10.151.46.32]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 25 Jul 2013 08:35:42 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.235]) by SINPEX01CL01.citrite.net ([169.254.1.212]) with mapi id 14.02.0342.004; Thu, 25 Jul 2013 16:35:40 +0800 From: Krishna Khanal To: Christoph Paasch Thread-Topic: [multipathtcp] MP_CAP Final ack drop and fallback behavior Thread-Index: AQHOiESWGIUqyZLNGkanGr0qg2ELz5lzBDOAgAHMAsD//69EAIAAj13A//98zoCAAIbb0A== Date: Thu, 25 Jul 2013 08:35:39 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063CA58B@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> <20130725074624.GA3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> <20130725082957.GD3897@cpaasch-mac> In-Reply-To: <20130725082957.GD3897@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.240.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 08:35:47 -0000 Yes, I was using Linux Client. Both drop and out of order are causing fallback.=20 Regards, Krishna -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Thursday, July 25, 2013 2:00 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior Hello, On 25/07/13 - 08:26:24, Krishna Khanal wrote: > Hi Christoph, Yes server sending its willingness but letting client decid= e > on the reliability of final ack looks better.=20 >=20 > In my experience, there is significant fallback due to receiving data > packet before final ack, though I don't have exact data to share here. > Anyone having any experience with this? are you using the Linux implementation as a client? I would be surprised if you have so many fallbacks, because you would need a drop of the third ACK. Thus you maybe have a high loss-rate on the path (?). Cheers, Christoph >=20 > Regards, Krishna >=20 >=20 > -----Original Message----- From: Christoph Paasch > [mailto:christoph.paasch@uclouvain.be] Sent: Thursday, July 25, 2013 1:18 > PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP > Final ack drop and fallback behavior >=20 > Hello Krishna, >=20 > On 25/07/13 - 04:51:13, Krishna Khanal wrote: > > What about setting a flag in the SYNACK packet to tell the peer about > > the reliability of the final ack? If the administrator thinks it is ok > > to put a client on hold for an RTT, then they can set the flag in the > > synack packet and force client to do reliable transmission of final ack= . >=20 > I'm not against this flag. But, it should just be a signal of the server > for the client, saying "I'm doing stateless connection establishment". In > the end, it's the client who will decide if he wants to trade this > additional RTT for assured MPTCP-connectivity or not. >=20 >=20 > Cheers, Christoph >=20 >=20 > > -----Original Message----- From: Christoph Paasch > > [mailto:christoph.paasch@uclouvain.be] Sent: Wednesday, July 24, 2013 > > 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] > > MP_CAP Final ack drop and fallback behavior > >=20 > > Hello Krishna, > >=20 > > On 24/07/13 - 08:05:40, Krishna Khanal wrote: > > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way > > > to continue with MPTCP if the final ack of 3-way MP_CAP handshake is > > > dropped or the data packet is received before the MP_CAP ack due to > > > out of ordering of the packet in the network. Only way to continue > > > with the transaction is to fallback to regular TCP and there is a > > > pretty much chance of happening this in the real network. So, there i= s > > > always a requirement of fallback even if the middle devices supports > > > and understands MPTCP. > > >=20 > > > Is there any thought on making MP_CAP final ack reliable like MP_JOIN > > > final ack or including MP_CAP final ack options with the data packet > > > along with DSS packet until the ack is received? Second, option may > > > not be suitable because it consumes all the option space and first > > > option also tend to increase the handshake duration and block the > > > request by atleast an RTT. > > >=20 > > > Any thought? > >=20 > > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent i= n > > a reliable way, as it is done today for the third ACK with the MP_JOIN. > > But this got removed due to the additional RTT: > >=20 > > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html > >=20 > >=20 > > Then, the status of the draft was for some time that MPTCP was doing > > reliable transmission of the third ACK+MP_CAPABLE, but allowed sending > > data before the arrival of this third ACK. However, this did not help, > > as early arrival of data (prior to the third ACK) will still trigger a > > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack > > as it is for today: > >=20 > > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html > >=20 > >=20 > > It would not be possible to combine MP_CAPABLE with the DSS-option and > > still use stateless connection establishment: > >=20 > > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 > > bytes (Subflow-seq) + 4 bytes (Data-length + csum) =3D 16 bytes > >=20 > > So, there are 4 more bytes left. This would mean that we cannot put the > > Timestamp-option, which is required for stateless connection > > establishment. > >=20 > >=20 > >=20 > > Cheers, Christoph From philip.eardley@bt.com Thu Jul 25 04:41:03 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1EE21F9ABB for ; Thu, 25 Jul 2013 04:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.262 X-Spam-Level: X-Spam-Status: No, score=-103.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGN6b-fUnpTl for ; Thu, 25 Jul 2013 04:40:58 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id A461B21F9AA2 for ; Thu, 25 Jul 2013 04:40:56 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 25 Jul 2013 12:40:48 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.253]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 25 Jul 2013 12:40:48 +0100 From: To: Date: Thu, 25 Jul 2013 12:40:47 +0100 Thread-Topic: MPTCP interop in Berlin: Wed 3pm Thread-Index: Ac6JKebfNqwlR5m9QMewQTWD1Og6Xw== Message-ID: <9510D26531EF184D9017DF24659BB87F35B80336D3@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35B80336D3EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] MPTCP interop in Berlin: Wed 3pm X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 11:41:03 -0000 --_000_9510D26531EF184D9017DF24659BB87F35B80336D3EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We will have an mptcp interop session in Berlin. It will be in the room Dahlem, from 3pm Wed 31st. Finish by 5.40pm in time = for the plenary. I know that Christoph and Nigel will be there with their UCLouvain and Swin= burne implementations. Of course others are very welcome - it's probably wo= rth letting them know. Best wishes phil --_000_9510D26531EF184D9017DF24659BB87F35B80336D3EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We will have an mptcp int= erop session in Berlin.

 <= /span>

It will be in the room Dahlem, from 3pm Wed 31= st. Finish by 5.40pm in time for the plenary.

 

I know that Christoph and = Nigel will be there with their UCLouvain and Swinburne implementations. Of = course others are very welcome – it’s probably worth letting th= em know.

 

Best wishes

phil=

 

&nb= sp;

 

&nb= sp;

= --_000_9510D26531EF184D9017DF24659BB87F35B80336D3EMV65UKRDdoma_-- From nishida@sfc.wide.ad.jp Thu Jul 25 22:30:29 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D959611E80D3 for ; Thu, 25 Jul 2013 22:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB1LnT8YOPXh for ; Thu, 25 Jul 2013 22:30:29 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 1D78011E80D2 for ; Thu, 25 Jul 2013 22:30:27 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 735BC27809D for ; Fri, 26 Jul 2013 14:30:24 +0900 (JST) Received: by mail-la0-f48.google.com with SMTP id hi8so1972218lab.7 for ; Thu, 25 Jul 2013 22:30:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=84XDd82l+qWOnNq+bW3ol2+4bNS64G2uQPQzqrCFCUQ=; b=i+xVe5SYbP1zuIHnUaizzJrLgu60eS6E3XpvvhEtdkz5CVSOx2k+MZ5S9PMnKf0Lx+ 5AMZWk1VGshhWs8oSIFlKoxNI6adlpF1gyHdwqxOlrOiqcX1EvrR/PRc3GL3RZOif4JZ AabakjtEfnGedEsoPv2iPYcUz28gAlByoVfhQV9ZmjnpGh2pQ0YH/oVwhE2d1pJaeFJp CPGmwuqcr1V8O7Zgr4WhAcL/oJkDeILysI933WW3A8UVqkyo1E/eyJMlOTq9s9XvuBzE b9kFysCkRTXekqG7AvSvGOopbyxG4CKy1sh+jJ2fmG5qUGyVmaTP+Hr0j3qORb+0qXtW FOVw== MIME-Version: 1.0 X-Received: by 10.152.18.202 with SMTP id y10mr20027158lad.80.1374816621821; Thu, 25 Jul 2013 22:30:21 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Thu, 25 Jul 2013 22:30:21 -0700 (PDT) Date: Thu, 25 Jul 2013 22:30:21 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] slides for Berlin meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 05:30:30 -0000 Hello, We would like to ask presenters to send the presentation materials to Phil and me by Monday evening. Thanks, -- Yoshifumi & Phil From christoph.paasch@uclouvain.be Fri Jul 26 00:31:10 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EAC21F8756 for ; Fri, 26 Jul 2013 00:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fq5rWfq2-uC for ; Fri, 26 Jul 2013 00:31:05 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9010921F89EB for ; Fri, 26 Jul 2013 00:31:01 -0700 (PDT) Received: from localhost (haproxy2.sipr.ucl.ac.be [130.104.5.120]) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTP id 1C4B41C7197 for ; Fri, 26 Jul 2013 09:30:53 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 1C4B41C7197 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1374823853; bh=cTXdu3D0mfErabWnMadna3hlp9bXfSORN1gIDJC6zDY=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=eQM0CHwZss3iKn9P2e8PVJAntB89x0x0jAbmWHkKlbwyEyLU4oXkGfpNxl0gYbAk4 EG/kBlI58jw8cu5+WW6BTx1T6OpLPnofrIu4Ic5hzYFQCS6gb2TWzmto11kvxoWwvA MaJ3weAKClERnAuFhFKF4V9LWrnBKlvpS7qwblMQ= Date: Fri, 26 Jul 2013 09:30:53 +0200 From: Christoph Paasch To: MultiPath TCP - IETF WG Message-ID: <20130726073053.GA3650@cpaasch-mac> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-SGSI-MailScanner-ID: 1C4B41C7197.A94B4 X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-0.87, requis 5, ALL_TRUSTED -2.00, BAYES_00 -1.60, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VERIFIED -1.00, FSL_HELO_NON_FQDN_1 0.00, HELO_LOCALHOST 3.83) X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Linux Kernel MPTCP stable release - v0.87 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 07:31:10 -0000 Hello all, we are happy to announce a new stable release of the Linux Kernel implementation of MultiPath TCP. To download the source, or install pre-compiled Debian/Ubuntu-packages, please visit: http://multipath-tcp.org/pmwiki.php?n=Main.Release87 What is new in this release? ============================ The MPTCP v0.87 release is based on Linux Kernel v3.10. Its new features compared to the v0.86 release are: * Hardware-offloading support (TSO/LRO) - Done by Gregory Detal (UCLouvain) * TCP zero-copy support (sendfile and splice) * Support for NET_DMA * Several performance improvements * NFS is working properly * Middlebox support has been improved * TCP-urgent pointer is now bug-free - Done by Cristina Ciocan (Intel) We would also like to thank all the bug-reports we received that helped stabilize the code: * Krishna Khanal, Varun Taneja (Citrix) * Benjamin Hesmans, Gregory Detal (UCLouvain) * Per Hurtig (Karlstad University) * Shinkai Takumi (Okayama University) * Ronald Velt (TNO) * Ramin Khalili (T-Labs/TU-Berlin) * ... Contributors ============ We would like to thank all contributors who provided code to this project since its beginning around 2008 (ordered by number of commits): Sébastien Barré (UCLouvain, now at Thelis) Christoph Paasch (UCLouvain) Gregory Detal (UCLouvain) Jakko Korkeaniemi (Aalto University) Mihai P. Andrei (Intel) Fabien Duchêne (UCLouvain) Andreas Seelinger (RWTH Aachen) Stefan Sicleru (Intel) Lavkesh Lahngir Catalin Nicutar (PUB Bucharest) Andrei Maruseac (Intel) Andreas Ripke (NEC) Vlad Dogaru (Intel) Octavian Purdila (Intel) Niels Laukens (VRT Belgium) John Ronan (TSSG) Brandon Heller (Stanford University) Cristina Ciocan (Intel) From philip.eardley@bt.com Mon Jul 29 02:44:16 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE121F9971 for ; Mon, 29 Jul 2013 02:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.443 X-Spam-Level: X-Spam-Status: No, score=-103.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiwI5iGnsvIH for ; Mon, 29 Jul 2013 02:44:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id A6F4F21F9A2A for ; Mon, 29 Jul 2013 02:43:48 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 29 Jul 2013 10:43:46 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.32]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 29 Jul 2013 10:43:45 +0100 From: To: Date: Mon, 29 Jul 2013 10:43:45 +0100 Thread-Topic: Next steps for WG Thread-Index: AQHOjEAephs8DK1fJEWhmYPkl4rFrA== Message-ID: <9510D26531EF184D9017DF24659BB87F35CB3F1EB3@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multipathtcp] Next steps for WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:44:16 -0000 It would be nice to have some discussion during the WG meeting about how we= progress on our charter. >From the Implementations survey, http://datatracker.ietf.org/doc/draft-eard= ley-mptcp-implementations-survey/ I think these are the things for us to co= nsider in order to progress the protocol RFC6824 on the standards track (wh= ich is the main topic on our charter) 1.ADD_ADDR needs more discussion this was the one mptcp message that wasn't implemented by everyone. there w= ere some worries about security, see also http://datatracker.ietf.org/doc/d= raft-bagnulo-mptcp-attacks/ . personally i think it would be a mistake for us to end up with two variants= of mptcp, one which does add-addr and one that doesn't. 2.Fall-back needs a bit more clarification i think this is "just" a matter of working through the extra corner cases t= hat people have been found and adding /revising the current text. 3.=91Better=92 security may be needed RFC6824 exchanges keys in the clear during the initial handshake, then uses= keyed HMAC. there were some comments that something more secure may be needed and somet= hing with lower cost may be needed, preferably both in one. we have the idea of building on top of ssl security, see http://datatracker= .ietf.org/doc/draft-bagnulo-mptcp-attacks/ and also (expired) http://tools.= ietf.org/html/draft-paasch-mptcp-ssl-00 Is this a good way forward? what would be good is if we can come to consensus on: - what are the new threats (ie that weren't in RFC6181) - which ones will we try and solve as we move the protocol onto the standar= ds track - what general approach will we pursue to solve them We have an offer from Stephen F (Security AD) for help finding a sec area e= xpert who'd work intensively with us.=20 If we're ready after the wg meeting, we could go to the secarea meeting wit= h our request.=20 Other items on our charter - More operational experience of different use cases, scenarios=85 (=93part= icularly looking for cases where MPTCP could be detrimental in some way=94) - Implementation advice (heuristics) - MPTCP-aware middlebox (where at least one end host is MPTCP-enabled) I'll adjust the agenda to allow some discussion time about these Next Steps= issues thanks phil= From philip.eardley@bt.com Mon Jul 29 08:49:59 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFF421F9A05 for ; Mon, 29 Jul 2013 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwrB7O2MCrkI for ; Mon, 29 Jul 2013 08:49:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 41E3621F995B for ; Mon, 29 Jul 2013 08:49:45 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 29 Jul 2013 16:49:44 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.32]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 29 Jul 2013 16:49:44 +0100 From: To: Date: Mon, 29 Jul 2013 16:49:44 +0100 Thread-Topic: slides required Thread-Index: AQHOjHM+3VsuxVoXAUuIOI+d+BZlsA== Message-ID: <9510D26531EF184D9017DF24659BB87F35CB3F1EC2@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35CB3F1EC2EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] slides required X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:49:59 -0000 --_000_9510D26531EF184D9017DF24659BB87F35CB3F1EC2EMV65UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please send me & Yoshifumi your slides as soon as possible (thanks for Mich= io and Christoph, yours are uploaded) I will likely be tied up in meetings after 6.45pm this evening until the WG= meeting, so if you can send them before then, that would be great. thanks phil --_000_9510D26531EF184D9017DF24659BB87F35CB3F1EC2EMV65UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
please = send me & Yoshifumi your slides as soon as possible (thanks for Michio = and Christoph, yours are uploaded)
 
I will likely be tied up in meetings= after 6.45pm this evening until the WG meeting, so if you can send them be= fore then, that would be great.
 
thanks
phil
--_000_9510D26531EF184D9017DF24659BB87F35CB3F1EC2EMV65UKRDdoma_-- From elopez@fortinet.com Mon Jul 29 09:37:23 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072DC21F9935 for ; Mon, 29 Jul 2013 09:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2yrwL71yNMN for ; Mon, 29 Jul 2013 09:37:17 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F64E21F9829 for ; Mon, 29 Jul 2013 09:37:11 -0700 (PDT) From: Edward Lopez To: "multipathtcp@ietf.org" Thread-Topic: MPTCP and Middleboxes Thread-Index: AQHOjHnfaiSl757TxkqHYZ8HU8yboA== Date: Mon, 29 Jul 2013 16:37:10 +0000 Message-ID: <7C36DBC9-809A-488A-9B5F-073EA5ACFDA3@fortinet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.22.151] Content-Type: multipart/alternative; boundary="_000_7C36DBC9809A488A9B5F073EA5ACFDA3fortinetcom_" MIME-Version: 1.0 Subject: [multipathtcp] MPTCP and Middleboxes X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 16:37:23 -0000 --_000_7C36DBC9809A488A9B5F073EA5ACFDA3fortinetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I apologize as I am new to the mailing list, and it may be that some of t= his has already been answered. Upon listening to Olivier's excellent pre= sentation, I developed a simple VM-based environment to consider the impl= ications of MPTCP on a middlebox: |------------ MBOX_A ------------| | | | | MPTCP_1 |---| | MPTCP_2 | | | | |----------[- MBOX_B ------------| | | | | Internet Subnet MPTCP_1<>MBOX_A =3D 192.168.6.0/24 Subnet MPTCP_2<>MBOX_A =3D 192.168.7.0/24 Subnet MPTCP_1<>MBOX_B =3D 192.168.9.0/24 Subnet MPTCP_2<>MBOX_B =3D 192.168.10.0/24 Subnet MBOX_A<>MBOX_B =3D 192.168.100.0/24 In all cases the MPTCP host is .2 and and MBOX is .1, except on the MBOX_= A<>MBOX_B subnet, where MBOX_B is .2. All routing has been statically de= fined on the MBOX devices, so that full reachability is established. Whe= n MPTCP is configured, the routing as configured as defined by the 'multi= path-tcp.org' website. When MPTCP is disabled,= or for non-TCP traffic, the default gateways on the MPTCP devices point = to MBOX_A Each MBOX has been configured to support data leakage protection (DLP), w= here it is detecting the transfer of files which have been specifically f= ingerprinted. I have provide the fingerprint pattern of large PDF files = on an Apache server on MPTCP_2. With MPTCP disabled, all traffic flows across MBOX_A, and MBOX_A correctl= y detects and alerts on the transfers of fingerprinted files. However, w= hen MPTCP is configured, neither MBOX detects the transfer of fingerprint= ed files, since the transfer is taking place across two separate TCP sub-= flows, and the MBOX units are operating independantly. I suspect that an= y content inspection or heuristic/statistical detection technologies (AV,= IPS, DoS, etc.) would be similarly affected. This is a double-edged sword. Basically MPTCP is effectively allowing as= ymmetric data flows relative to the MBOX units, while effectively defeati= ng any asymmetric traffic defenses. It is not clear to me that a middleb= ox, upon detective an MPTCP sub-flow, can meaningfully single to the MPTC= P unit initiating the session that an MPTCP session is unacceptable, and = must be defaulted down to a simple TCP session. I am of the mindset that middlebox providers should look towards providin= g MPTCP proxy services, which may actually be useful in providing MPTCP s= upport for hosts that do not natively provide it. But it seems that we n= eed to provide a explicit means for intermediate devices to request an MP= TCP session be restarted as a standard TCP session. Again, I apologize if this topic has been covered. I appreciate any inpu= t on this topic. Thanks! Ed Ed Lopez - Fortinet VP, Carrier Solutions 1090 Kifer Road Sunnyvale, CA 94086 Cell: +1 703 220 0988 elopez@fortinet.com *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_7C36DBC9809A488A9B5F073EA5ACFDA3fortinetcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable I apologize as I am new to the mailing list, a= nd it may be that some of this has already been answered.  Upon list= ening to Olivier's excellent presentation, I developed a simple VM-based = environment to consider the implications of MPTCP on a middlebox:



  |------------ MBOX_A ------------|=
  |         &nbs= p;    |  |              = ;|
MPTCP_1      |---|  |=            MPTCP_2
  |         &nbs= p;|      |              = ;|
  |----------[- MBOX_B ------------|=
           =  |   |
           =  |   |
           = Internet


Subnet MPTCP_1<>MBOX_A =3D 192.168.= 6.0/24
Subnet MPTCP_2<>MBOX_A =3D 192.168.= 7.0/24
Subnet MPTCP_1<>MBOX_B =3D 192.168.= 9.0/24
Subnet MPTCP_2<>MBOX_B =3D 192.168.= 10.0/24
Subnet MBOX_A<>MBOX_B =3D 192.168.1= 00.0/24

In all cases the MPTCP host is .2 and and= MBOX is .1, except on the MBOX_A<>MBOX_B subnet, where MBOX_B is .= 2.  All routing has been statically defined on the MBOX devices, so = that full reachability is established.  When MPTCP is configured, the routing as configured as defined by the 'multipath-tcp.org' website.  When MPTCP= is disabled, or for non-TCP traffic, the default gateways on the MPTCP d= evices point to MBOX_A 

Each MBOX has been configured to support = data leakage protection (DLP), where it is detecting the transfer of file= s which have been specifically fingerprinted.  I have provide the fi= ngerprint pattern of large PDF files on an Apache server on MPTCP_2.

With MPTCP disabled, all traffic flows ac= ross MBOX_A, and MBOX_A correctly detects and alerts on the transfers of = fingerprinted files.  However, when MPTCP is configured, neither MBO= X detects the transfer of fingerprinted files, since the transfer is taking place across two separate&nb= sp;TCP sub-flows, and the MBOX units are operating independantl= y.  I suspect that any content inspection or heuristic/statistical d= etection technologies (AV, IPS, DoS, etc.) would be similarly affected.

This is a double-edged sword.  Basic= ally MPTCP is effectively allowing asymmetric data flows relative to the = MBOX units, while effectively defeating any asymmetric traffic defenses. =  It is not clear to me that a middlebox, upon detective an MPTCP sub-flow, can meaningfully single to the MPTCP unit i= nitiating the session that an MPTCP session is unacceptable, and must be = defaulted down to a simple TCP session.

I am of the mindset that middlebox p= roviders should look towards providing MPTCP proxy services, which&n= bsp;may actually be useful in providing MPTCP support for hosts that do n= ot natively provide it.  But it seems that we need to provide a explicit means for intermediate devices to request an MPTCP session be= restarted as a standard TCP session.

Again, I apologize if this topic has been= covered.  I appreciate any input on this topic.

Thanks!
Ed 
Ed Lopez - Fortinet
VP, Carrier Solutions
1090 Kifer Road
Sunnyvale, CA 94086
Cell: +1 703 220 0988
elopez@fortinet.com
=


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_7C36DBC9809A488A9B5F073EA5ACFDA3fortinetcom_-- From catalin.nicutar@gmail.com Mon Jul 29 10:41:26 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAF321F9A4A for ; Mon, 29 Jul 2013 10:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTV9f5w2mM8y for ; Mon, 29 Jul 2013 10:41:23 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA3821E8087 for ; Mon, 29 Jul 2013 10:40:05 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so4044490wes.39 for ; Mon, 29 Jul 2013 10:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KeZ1RmZGzH9MStFaUiahzQUkXUFdH9IwrcrgWVnqsl8=; b=eC5l3RpPipY50QhAcuuc2SjVJ/Bl1RDBbE0M/R9c/DvHbLifGb3pJCBjfKSOxCxpLF 1Lw61hh3L2U3OLMcRG4oWGkYhEn7RDygw2tDnrn1H4y3JVW5LEXPg4ryl6uAiTjuXA01 G09BYh36ZVQ8k5JxJTJx2q/3+wYJy//ukhpJfaM+/iwtiDwF4NQGiyp7qg2VivBRDvxS PvPPYL5q2xJ7FaHYshq+20iRyofjTaq/sNkgOjJDsZRWvbX4bobrjlySta72lYRikz3Z XcnawzzdSA8yBFqPi79kY78D0MRTG9utbVC8cL3Kx/TJwVJyVphTuyoNorNS1VIeFMNr f7Kw== X-Received: by 10.194.82.193 with SMTP id k1mr42741622wjy.21.1375119605285; Mon, 29 Jul 2013 10:40:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.160.131 with HTTP; Mon, 29 Jul 2013 10:39:45 -0700 (PDT) In-Reply-To: <7C36DBC9-809A-488A-9B5F-073EA5ACFDA3@fortinet.com> References: <7C36DBC9-809A-488A-9B5F-073EA5ACFDA3@fortinet.com> From: Catalin Nicutar Date: Mon, 29 Jul 2013 20:39:45 +0300 Message-ID: To: Edward Lopez Content-Type: text/plain; charset=ISO-8859-1 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] MPTCP and Middleboxes X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:41:26 -0000 Hello, On Mon, Jul 29, 2013 at 7:37 PM, Edward Lopez wrote: > It is not clear to me that a middlebox, upon detective an MPTCP sub-flow, > can meaningfully single to the MPTCP unit initiating the session that an > MPTCP session is unacceptable, and must be defaulted down to a simple TCP > session. > [....] > But it seems that we > need to provide a explicit means for intermediate devices to request an > MPTCP session be restarted as a standard TCP session. If I understand your question correctly, the middlebox would simply have to strip the MPTCP option during the handshake and the connection would automatically fall back to regular TCP. There also provisions for falling back to TCP after the handshake, when data has already been ACKed at the connection level. Best regards, Catalin Nicutar From nishida@sfc.wide.ad.jp Mon Jul 29 11:15:48 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2B411E811B for ; Mon, 29 Jul 2013 11:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6SUYEnToKZ7 for ; Mon, 29 Jul 2013 11:15:47 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 5771A11E80F2 for ; Mon, 29 Jul 2013 11:15:39 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 19C7827807F for ; Tue, 30 Jul 2013 03:15:35 +0900 (JST) Received: by mail-la0-f45.google.com with SMTP id fj20so1353639lab.32 for ; Mon, 29 Jul 2013 11:15:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gIVZtLbJg/+xeeWFQJhtR5nlHAnS98eABAvjXUa1kwo=; b=ma9zj7p+wkt/AZKIVdkxgfLRHRSEsBUJNr88iDRThwLMJiCb1tsEBK6qNwVfvvFhXH WfZi6+c4DOr/02EUTKiK9d8l4KenRIyk5eBtB0WQeigqcclJTY2o18VB/c0bnboNEWz/ pFNfHBKNwOCGPQUVMHRClij4vOaSVVZ6fC+KxU4ANLDS3V8Idxcyg26i91LW/5z7OmuY 8P+CTPbTfxbOoaBkPqGmeG2ShTQjJVf6Pw/Sau5ZvFeBFNrZ7fn28yIonlcIbIzikark u9FS7ihvSgqJu/buOzgaQgJCLheR7bR9vz8m8aSOstIEX258lntz/YlHeZ3Qqf5fCehK FZlQ== MIME-Version: 1.0 X-Received: by 10.112.185.36 with SMTP id ez4mr3694441lbc.81.1375121733568; Mon, 29 Jul 2013 11:15:33 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Mon, 29 Jul 2013 11:15:33 -0700 (PDT) Date: Mon, 29 Jul 2013 11:15:33 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] volunteers for note taking and jabber X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:15:48 -0000 Hello, Since the agenda is really full this time, we're keen to look for volunteers for note taking and jabber scribbling. If you're interested, please let us know. If you would like to know about the tasks we would like to ask, please feel free to contact us. We really appreciate your cooperation! -- Yoshifumi & Phil From nishida@sfc.wide.ad.jp Mon Jul 29 20:04:42 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D4F11E81A9 for ; Mon, 29 Jul 2013 20:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJO5kTgvmjIx for ; Mon, 29 Jul 2013 20:04:41 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 2404611E81A4 for ; Mon, 29 Jul 2013 20:04:40 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 87DD4278091 for ; Tue, 30 Jul 2013 12:04:38 +0900 (JST) Received: by mail-la0-f45.google.com with SMTP id fj20so1663156lab.18 for ; Mon, 29 Jul 2013 20:04:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dlNu5ImDtiB8APwGJOOz+AUSQEK+fdSL4Zrg5Lyij/A=; b=pBurIF3fwock/hzEMcMkj3gqk6Fz8+ntqN6F0Ty4UDO/Endvxq5aMqSYI2qiDINq50 rXSY1j3von0nZxfw5izOI/vaMlAyUrgYXfBsTb/wvCocyoVz6cYOvGmY+YHmaprP3i/J tsQvr6DLr6nhRu4yKKvZTROQFFrwfvSN4BRgf4pgrPs9G+CHTaytQoRU7WDMIFTdYEQu +fxeBZO+JMvYyRjmpjsE7gc/oBsYF4BqSm+gnU/YykZZWkP3vr4CSCbcFOkd7LM6m2hs zJPDfW+a0aafgeLVVrZjv9KdSNC99tfvvQ5hXaWvVt8v0SCBiaAa6t3fRFBfx3NLP305 oByg== MIME-Version: 1.0 X-Received: by 10.152.37.232 with SMTP id b8mr3233378lak.80.1375153475929; Mon, 29 Jul 2013 20:04:35 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Mon, 29 Jul 2013 20:04:35 -0700 (PDT) In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063CA58B@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> <20130725074624.GA3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> <20130725082957.GD3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA58B@SINPEX01CL02.citrite.net> Date: Mon, 29 Jul 2013 20:04:35 -0700 Message-ID: From: Yoshifumi Nishida To: Krishna Khanal Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:04:42 -0000 Hi, Hmm.. I'm still thinking we need to solve this in the spec as reliable solutions might require major changes.. I know this is tricky and not a very good idea, but it might improve a situation a bit. Let's say initiator's IW=4. if it wants to send something after handshake, it may transmit data packets like this. packet 1 with MPCAP packet 2 with MPCAP packet 3 with MPCAP packet 4 with DSS (covers 1-4) On the lost of these packets, it should retransmit them with DSS. I know this doesn't keep the following rule in RFC6824 exactly, though. A sender MUST include a DSS option with data sequence mapping in every segment until one of the sent segments has been acknowledged with a DSS option containing a Data ACK. Upon reception of the acknowledgment, the sender has the confirmation that the DSS option passes in both directions and may choose to send fewer DSS options than once per segment. -- Yoshifumi On Thu, Jul 25, 2013 at 1:35 AM, Krishna Khanal wrote: > Yes, I was using Linux Client. > > Both drop and out of order are causing fallback. > > Regards, > Krishna > > > -----Original Message----- > From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be] > Sent: Thursday, July 25, 2013 2:00 PM > To: Krishna Khanal > Cc: multipathtcp > Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior > > Hello, > > On 25/07/13 - 08:26:24, Krishna Khanal wrote: >> Hi Christoph, Yes server sending its willingness but letting client decide >> on the reliability of final ack looks better. >> >> In my experience, there is significant fallback due to receiving data >> packet before final ack, though I don't have exact data to share here. >> Anyone having any experience with this? > > are you using the Linux implementation as a client? > > I would be surprised if you have so many fallbacks, because you would need > a drop of the third ACK. > Thus you maybe have a high loss-rate on the path (?). > > > Cheers, > Christoph > >> >> Regards, Krishna >> >> >> -----Original Message----- From: Christoph Paasch >> [mailto:christoph.paasch@uclouvain.be] Sent: Thursday, July 25, 2013 1:18 >> PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP >> Final ack drop and fallback behavior >> >> Hello Krishna, >> >> On 25/07/13 - 04:51:13, Krishna Khanal wrote: >> > What about setting a flag in the SYNACK packet to tell the peer about >> > the reliability of the final ack? If the administrator thinks it is ok >> > to put a client on hold for an RTT, then they can set the flag in the >> > synack packet and force client to do reliable transmission of final ack. >> >> I'm not against this flag. But, it should just be a signal of the server >> for the client, saying "I'm doing stateless connection establishment". In >> the end, it's the client who will decide if he wants to trade this >> additional RTT for assured MPTCP-connectivity or not. >> >> >> Cheers, Christoph >> >> >> > -----Original Message----- From: Christoph Paasch >> > [mailto:christoph.paasch@uclouvain.be] Sent: Wednesday, July 24, 2013 >> > 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] >> > MP_CAP Final ack drop and fallback behavior >> > >> > Hello Krishna, >> > >> > On 24/07/13 - 08:05:40, Krishna Khanal wrote: >> > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way >> > > to continue with MPTCP if the final ack of 3-way MP_CAP handshake is >> > > dropped or the data packet is received before the MP_CAP ack due to >> > > out of ordering of the packet in the network. Only way to continue >> > > with the transaction is to fallback to regular TCP and there is a >> > > pretty much chance of happening this in the real network. So, there is >> > > always a requirement of fallback even if the middle devices supports >> > > and understands MPTCP. >> > > >> > > Is there any thought on making MP_CAP final ack reliable like MP_JOIN >> > > final ack or including MP_CAP final ack options with the data packet >> > > along with DSS packet until the ack is received? Second, option may >> > > not be suitable because it consumes all the option space and first >> > > option also tend to increase the handshake duration and block the >> > > request by atleast an RTT. >> > > >> > > Any thought? >> > >> > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in >> > a reliable way, as it is done today for the third ACK with the MP_JOIN. >> > But this got removed due to the additional RTT: >> > >> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html >> > >> > >> > Then, the status of the draft was for some time that MPTCP was doing >> > reliable transmission of the third ACK+MP_CAPABLE, but allowed sending >> > data before the arrival of this third ACK. However, this did not help, >> > as early arrival of data (prior to the third ACK) will still trigger a >> > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack >> > as it is for today: >> > >> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html >> > >> > >> > It would not be possible to combine MP_CAPABLE with the DSS-option and >> > still use stateless connection establishment: >> > >> > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 >> > bytes (Subflow-seq) + 4 bytes (Data-length + csum) = 16 bytes >> > >> > So, there are 4 more bytes left. This would mean that we cannot put the >> > Timestamp-option, which is required for stateless connection >> > establishment. >> > >> > >> > >> > Cheers, Christoph > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From elopez@fortinet.com Mon Jul 29 22:00:24 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4171721F9EB2 for ; Mon, 29 Jul 2013 22:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYlrxPvabOR2 for ; Mon, 29 Jul 2013 22:00:18 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id 569F621F9EB0 for ; Mon, 29 Jul 2013 22:00:18 -0700 (PDT) From: Edward Lopez To: Catalin Nicutar Thread-Topic: [multipathtcp] MPTCP and Middleboxes Thread-Index: AQHOjHnfaiSl757TxkqHYZ8HU8yboJl8YZ+AgAC+IYA= Date: Tue, 30 Jul 2013 05:00:16 +0000 Message-ID: <3BC3C77B-E06A-4E94-99EC-F6B021E4EE19@fortinet.com> References: <7C36DBC9-809A-488A-9B5F-073EA5ACFDA3@fortinet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.92.22.186] Content-Type: multipart/alternative; boundary="_000_3BC3C77BE06A4E9499ECF6B021E4EE19fortinetcom_" MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] MPTCP and Middleboxes X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 05:00:24 -0000 --_000_3BC3C77BE06A4E9499ECF6B021E4EE19fortinetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I concur with the fallback capabilities, but in the bigger picture, it is= certainly not desirable to have for example enterprise next-generation f= irewalls doing this on a persistent basis. As I see it so far, there are= four models for how such middleboxes should participate. 1) Acceptance - This is in the case of middleboxes that are unaware of mc= tcp, and continue operation. Such would be the case of stateful firewall= s, load-balancers, etc. which are not performing any application-layer in= spections or transforms. However, devices that are ignorant of mptcp whi= le performing application-layer services will find mptcp as a potential v= ulnerability 2) Fallback - The middlebox detects the mptcp and forces a fallback to si= mple tcp. As noted, this can be done, but it is not desirable to have mi= ddleboxes purely treat mptcp as a vulnerability to be suppressed 3) Aggregate - It seems likely that in many cases, particularly in the ca= se of enterprise gateway implementations, that all tcp sub-flows will pas= s through a single middlebox. In this case, the middlebox provider can c= hoose to passively all sub-flows in aggregate to perform its desired func= tions 4) Proxy - I see it likely that middleboxes will actually perform simple = tcp to mptcp proxy services. This could be useful in a number of archite= ctures In my opinion, if mptcp is to achieve standardization, we need to have a = closer look at how middleboxes will participate. It is currently far too= easy for middlebox providers to force fallback to simple tcp or otherwis= e treat mptcp as a vulnerability to be detected and corrected. I see the= potential value of support of the aggregate and proxy models, which in t= urn strengthens support of the mptcp protocol itself. Thanks! Ed Lopez On Jul 29, 2013, at 1:39 PM, Catalin Nicutar > wrote: Hello, On Mon, Jul 29, 2013 at 7:37 PM, Edward Lopez > wrote: It is not clear to me that a middlebox, upon detective an MPTCP sub-flow,= can meaningfully single to the MPTCP unit initiating the session that an MPTCP session is unacceptable, and must be defaulted down to a simple TCP= session. [....] But it seems that we need to provide a explicit means for intermediate devices to request an MPTCP session be restarted as a standard TCP session. If I understand your question correctly, the middlebox would simply have = to strip the MPTCP option during the handshake and the connection would automatically fall back to regular TCP. There also provisions for falling= back to TCP after the handshake, when data has already been ACKed at the connection level. Best regards, Catalin Nicutar *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_3BC3C77BE06A4E9499ECF6B021E4EE19fortinetcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable I concur with the fallback capabilities, but i= n the bigger picture, it is certainly not desirable to have for example e= nterprise next-generation firewalls doing this on a persistent = basis.  As I see it so far, there are four models for how such middleboxes should participate.

1) Acceptance - This is in the case of middleboxes that are unaware o= f mctcp, and continue operation.  Such would be the case of stateful= firewalls, load-balancers, etc. which are not performing any application= -layer inspections or transforms.  However, devices that are ignorant of mptcp while performing application-layer se= rvices will find mptcp as a potential vulnerability
2) Fallback - The middlebox detects the mptcp and forces a fallb= ack to simple tcp.  As noted, this can be done, but it is not desira= ble to have middleboxes purely treat mptcp as a vulnerability to be = suppressed
3) Aggregate - It seems likely that in many cases, particularly in th= e case of enterprise gateway implementations, that all tcp sub-flows will= pass through a single middlebox.  In this case, the middl= ebox provider can choose to passively all sub-flows in aggregate to perform its desired functions
4) Proxy - I see it likely that middleboxes will actually perform&nbs= p;simple tcp to mptcp proxy services.  This could be useful in = a number of architectures

In my opinion, if mptcp is to achiev= e standardization, we need to have a closer look at how middleboxes = will participate.  It is currently far too easy for middlebox p= roviders to force fallback to simple tcp or otherwise treat mptcp as a vulnerability to be detected and corrected.  I see the p= otential value of support of the aggregate and proxy models, which in tur= n strengthens support of the mptcp protocol itself.

Thanks!
Ed Lopez


On Jul 29, 2013, at 1:39 PM, Catalin Nicutar <catalin.nicutar@gmail.com> wrote:

Hello,


On Mon, Jul 29, 2013 at 7:37 PM, Edward Lopez <elopez@fortinet.com> wrote:
It is not clear to me that a middlebox, upon de= tective an MPTCP sub-flow,
can meaningfully single to the MPTCP unit initiating the session that an<= br> MPTCP session is unacceptable, and must be defaulted down to a simple TCP=
session.
[....]
But it seems that we
need to provide a explicit means for intermediate devices to request an MPTCP session be restarted as a standard TCP session.


If I understand your question correctly, the middlebox would simply have = to
strip the MPTCP option during the handshake and the connection would
automatically fall back to regular TCP. There also provisions for falling=
back to TCP after the handshake, when data has already been ACKed
at the connection level.


Best regards,
Catalin Nicutar


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_3BC3C77BE06A4E9499ECF6B021E4EE19fortinetcom_-- From krishna.khanal2@citrix.com Mon Jul 29 22:08:40 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675FC21F9F70 for ; Mon, 29 Jul 2013 22:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upQMSVUyUHRl for ; Mon, 29 Jul 2013 22:08:36 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id DFCC021F9F80 for ; Mon, 29 Jul 2013 22:08:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,775,1367971200"; d="scan'208";a="4012296" Received: from sinpex01cl01.citrite.net ([10.151.46.32]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 30 Jul 2013 05:08:28 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.235]) by SINPEX01CL01.citrite.net ([169.254.1.212]) with mapi id 14.02.0342.004; Tue, 30 Jul 2013 13:08:26 +0800 From: Krishna Khanal To: Yoshifumi Nishida Thread-Topic: [multipathtcp] MP_CAP Final ack drop and fallback behavior Thread-Index: AQHOiESWGIUqyZLNGkanGr0qg2ELz5lzBDOAgAHMAsD//69EAIAAj13A//98zoCAAIbb0IAG+eWAgACfLrA= Date: Tue, 30 Jul 2013 05:08:26 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063CDB4A@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> <20130725074624.GA3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> <20130725082957.GD3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA58B@SINPEX01CL02.citrite.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.248.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 05:08:40 -0000 Hi, One problem with this approach is that the first packet needs to be split = most of the time (or always ?), if the sender has a single packet request/d= ata or it does not has knowledge of how much data is available to send in a= dvance. Also, combining MPCAP with a single data packet should be sufficien= t, no need to combine with subsequent data packets. Regards, Krishna -----Original Message----- From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]=20 Sent: Tuesday, July 30, 2013 8:35 AM To: Krishna Khanal Cc: Christoph Paasch; multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior Hi, Hmm.. I'm still thinking we need to solve this in the spec as reliable solutions might require major changes.. I know this is tricky and not a very good idea, but it might improve a situation a bit. Let's say initiator's IW=3D4. if it wants to send something after handshake, it may transmit data packets like this. packet 1 with MPCAP packet 2 with MPCAP packet 3 with MPCAP packet 4 with DSS (covers 1-4) On the lost of these packets, it should retransmit them with DSS. I know this doesn't keep the following rule in RFC6824 exactly, though. A sender MUST include a DSS option with data sequence mapping in every segment until one of the sent segments has been acknowledged with a DSS option containing a Data ACK. Upon reception of the acknowledgment, the sender has the confirmation that the DSS option passes in both directions and may choose to send fewer DSS options than once per segment. -- Yoshifumi On Thu, Jul 25, 2013 at 1:35 AM, Krishna Khanal wrote: > Yes, I was using Linux Client. > > Both drop and out of order are causing fallback. > > Regards, > Krishna > > > -----Original Message----- > From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be] > Sent: Thursday, July 25, 2013 2:00 PM > To: Krishna Khanal > Cc: multipathtcp > Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior > > Hello, > > On 25/07/13 - 08:26:24, Krishna Khanal wrote: >> Hi Christoph, Yes server sending its willingness but letting client deci= de >> on the reliability of final ack looks better. >> >> In my experience, there is significant fallback due to receiving data >> packet before final ack, though I don't have exact data to share here. >> Anyone having any experience with this? > > are you using the Linux implementation as a client? > > I would be surprised if you have so many fallbacks, because you would nee= d > a drop of the third ACK. > Thus you maybe have a high loss-rate on the path (?). > > > Cheers, > Christoph > >> >> Regards, Krishna >> >> >> -----Original Message----- From: Christoph Paasch >> [mailto:christoph.paasch@uclouvain.be] Sent: Thursday, July 25, 2013 1:1= 8 >> PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CA= P >> Final ack drop and fallback behavior >> >> Hello Krishna, >> >> On 25/07/13 - 04:51:13, Krishna Khanal wrote: >> > What about setting a flag in the SYNACK packet to tell the peer about >> > the reliability of the final ack? If the administrator thinks it is ok >> > to put a client on hold for an RTT, then they can set the flag in the >> > synack packet and force client to do reliable transmission of final ac= k. >> >> I'm not against this flag. But, it should just be a signal of the serve= r >> for the client, saying "I'm doing stateless connection establishment". I= n >> the end, it's the client who will decide if he wants to trade this >> additional RTT for assured MPTCP-connectivity or not. >> >> >> Cheers, Christoph >> >> >> > -----Original Message----- From: Christoph Paasch >> > [mailto:christoph.paasch@uclouvain.be] Sent: Wednesday, July 24, 2013 >> > 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp= ] >> > MP_CAP Final ack drop and fallback behavior >> > >> > Hello Krishna, >> > >> > On 24/07/13 - 08:05:40, Krishna Khanal wrote: >> > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way >> > > to continue with MPTCP if the final ack of 3-way MP_CAP handshake is >> > > dropped or the data packet is received before the MP_CAP ack due to >> > > out of ordering of the packet in the network. Only way to continue >> > > with the transaction is to fallback to regular TCP and there is a >> > > pretty much chance of happening this in the real network. So, there = is >> > > always a requirement of fallback even if the middle devices supports >> > > and understands MPTCP. >> > > >> > > Is there any thought on making MP_CAP final ack reliable like MP_JOI= N >> > > final ack or including MP_CAP final ack options with the data packet >> > > along with DSS packet until the ack is received? Second, option may >> > > not be suitable because it consumes all the option space and first >> > > option also tend to increase the handshake duration and block the >> > > request by atleast an RTT. >> > > >> > > Any thought? >> > >> > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent = in >> > a reliable way, as it is done today for the third ACK with the MP_JOIN= . >> > But this got removed due to the additional RTT: >> > >> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.htm= l >> > >> > >> > Then, the status of the draft was for some time that MPTCP was doing >> > reliable transmission of the third ACK+MP_CAPABLE, but allowed sending >> > data before the arrival of this third ACK. However, this did not help, >> > as early arrival of data (prior to the third ACK) will still trigger a >> > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ac= k >> > as it is for today: >> > >> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.htm= l >> > >> > >> > It would not be possible to combine MP_CAPABLE with the DSS-option and >> > still use stateless connection establishment: >> > >> > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 >> > bytes (Subflow-seq) + 4 bytes (Data-length + csum) =3D 16 bytes >> > >> > So, there are 4 more bytes left. This would mean that we cannot put th= e >> > Timestamp-option, which is required for stateless connection >> > establishment. >> > >> > >> > >> > Cheers, Christoph > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From swb@internet2.edu Mon Jul 29 23:20:54 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518C821F9F13 for ; Mon, 29 Jul 2013 23:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G49lwT6fxY3b for ; Mon, 29 Jul 2013 23:20:48 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 9928B21F9E34 for ; Mon, 29 Jul 2013 23:20:45 -0700 (PDT) Received: from mail184-db9-R.bigfish.com (10.174.16.249) by DB9EHSOBE027.bigfish.com (10.174.14.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 06:20:41 +0000 Received: from mail184-db9 (localhost [127.0.0.1]) by mail184-db9-R.bigfish.com (Postfix) with ESMTP id 64E00400D3; Tue, 30 Jul 2013 06:20:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0811HT004.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 10 X-BigFish: S10(zzzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1b1cn1b1bi1155h) Received: from mail184-db9 (localhost.localdomain [127.0.0.1]) by mail184-db9 (MessageSwitch) id 1375165238842033_21105; Tue, 30 Jul 2013 06:20:38 +0000 (UTC) Received: from DB9EHSMHS030.bigfish.com (unknown [10.174.16.244]) by mail184-db9.bigfish.com (Postfix) with ESMTP id BE8032004A; Tue, 30 Jul 2013 06:20:38 +0000 (UTC) Received: from BY2PRD0811HT004.namprd08.prod.outlook.com (157.56.237.5) by DB9EHSMHS030.bigfish.com (10.174.14.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 06:20:38 +0000 Received: from dhcp-1668.meeting.ietf.org (130.129.22.104) by pod51019.outlook.com (10.255.91.167) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 30 Jul 2013 06:20:35 +0000 Message-ID: <51F75B31.50309@internet2.edu> Date: Tue, 30 Jul 2013 08:20:33 +0200 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Edward Lopez References: <7C36DBC9-809A-488A-9B5F-073EA5ACFDA3@fortinet.com> <3BC3C77B-E06A-4E94-99EC-F6B021E4EE19@fortinet.com> In-Reply-To: <3BC3C77B-E06A-4E94-99EC-F6B021E4EE19@fortinet.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.129.22.104] X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] MPTCP and Middleboxes X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:20:54 -0000 IMHO you are right. A similar problem occurs in reverse, with intrusion detection systems on multiple ingresses into a site. The answer for those boxes seems to be to be conservative and simply not allow traffic that looks like partial sessions. Unfortunately IDSs and other middleboxes are becoming more useful, not less. Scott From nishida@sfc.wide.ad.jp Mon Jul 29 23:44:20 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9986021F99E1 for ; Mon, 29 Jul 2013 23:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqkwu1NXMhvw for ; Mon, 29 Jul 2013 23:44:15 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id D22B821F8D90 for ; Mon, 29 Jul 2013 23:44:14 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E82C9278095 for ; Tue, 30 Jul 2013 15:44:11 +0900 (JST) Received: by mail-la0-f49.google.com with SMTP id ev20so1494548lab.22 for ; Mon, 29 Jul 2013 23:44:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pI6+rGzgPq84L+mAPTGdiGnez2h5x8j7Olvr7DFEfc4=; b=Tr4wN+n3AW0RAcvoMm18RjJlxbxOvalLmZAkMf0gFcQLIIF/dOFXlZvg/cYU6mLhq0 Ystjl/hy8ZoylmBLj7xt/gCuUIJ5fHbZ4E67m6Nsd3ihba8fgsr14khUCQAMCq5s42fj tAUZu5dghArsJMLafYUnwFe8Zi/zoNHXZZogEAjw3w5Ldz/HPZa+X1O72mYgHom6pKZC x5J8RR4dd3WFQqtFETVTrZmyMFZ7kF6bQKZHtYGxXL87l85fmNDinLpHO0tbqVCWzVKM OfUBgGkRSyMzyIYJxKDrZtpGxDJF7blnsNEmXYfndDP7NINS10MVewY6P9N+53hAS2Hx 30Dg== MIME-Version: 1.0 X-Received: by 10.112.33.11 with SMTP id n11mr8038622lbi.76.1375166649040; Mon, 29 Jul 2013 23:44:09 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Mon, 29 Jul 2013 23:44:08 -0700 (PDT) In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063CDB4A@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> <20130725074624.GA3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> <20130725082957.GD3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA58B@SINPEX01CL02.citrite.net> <5E21A2ABD63A394988AE055C785C29C4063CDB4A@SINPEX01CL02.citrite.net> Date: Mon, 29 Jul 2013 23:44:08 -0700 Message-ID: From: Yoshifumi Nishida To: Krishna Khanal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:44:20 -0000 Hi Krishna, Yes. you're right. I don't say it's a good approach. I just say it might improve a situation with simple trick. You might be able to check which destinations have many fallbacks, then actives it.. - Yoshifumi On Mon, Jul 29, 2013 at 10:08 PM, Krishna Khanal wrote: > Hi, > One problem with this approach is that the first packet needs to = be split most of the time (or always ?), if the sender has a single packet = request/data or it does not has knowledge of how much data is available to = send in advance. Also, combining MPCAP with a single data packet should be = sufficient, no need to combine with subsequent data packets. > > Regards, > Krishna > > -----Original Message----- > From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > Sent: Tuesday, July 30, 2013 8:35 AM > To: Krishna Khanal > Cc: Christoph Paasch; multipathtcp > Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior > > Hi, > Hmm.. I'm still thinking we need to solve this in the spec as reliable > solutions might require major changes.. > > I know this is tricky and not a very good idea, but it might improve a > situation a bit. > Let's say initiator's IW=3D4. if it wants to send something after > handshake, it may transmit data packets like this. > > packet 1 with MPCAP > packet 2 with MPCAP > packet 3 with MPCAP > packet 4 with DSS (covers 1-4) > > On the lost of these packets, it should retransmit them with DSS. > I know this doesn't keep the following rule in RFC6824 exactly, though. > > A sender MUST include a DSS option with data sequence mapping in > every segment until one of the sent segments has been acknowledged > with a DSS option containing a Data ACK. Upon reception of the > acknowledgment, the sender has the confirmation that the DSS option > passes in both directions and may choose to send fewer DSS options > than once per segment. > > -- > Yoshifumi > > On Thu, Jul 25, 2013 at 1:35 AM, Krishna Khanal > wrote: >> Yes, I was using Linux Client. >> >> Both drop and out of order are causing fallback. >> >> Regards, >> Krishna >> >> >> -----Original Message----- >> From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be] >> Sent: Thursday, July 25, 2013 2:00 PM >> To: Krishna Khanal >> Cc: multipathtcp >> Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior >> >> Hello, >> >> On 25/07/13 - 08:26:24, Krishna Khanal wrote: >>> Hi Christoph, Yes server sending its willingness but letting client dec= ide >>> on the reliability of final ack looks better. >>> >>> In my experience, there is significant fallback due to receiving data >>> packet before final ack, though I don't have exact data to share here. >>> Anyone having any experience with this? >> >> are you using the Linux implementation as a client? >> >> I would be surprised if you have so many fallbacks, because you would ne= ed >> a drop of the third ACK. >> Thus you maybe have a high loss-rate on the path (?). >> >> >> Cheers, >> Christoph >> >>> >>> Regards, Krishna >>> >>> >>> -----Original Message----- From: Christoph Paasch >>> [mailto:christoph.paasch@uclouvain.be] Sent: Thursday, July 25, 2013 1:= 18 >>> PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_C= AP >>> Final ack drop and fallback behavior >>> >>> Hello Krishna, >>> >>> On 25/07/13 - 04:51:13, Krishna Khanal wrote: >>> > What about setting a flag in the SYNACK packet to tell the peer about >>> > the reliability of the final ack? If the administrator thinks it is o= k >>> > to put a client on hold for an RTT, then they can set the flag in the >>> > synack packet and force client to do reliable transmission of final a= ck. >>> >>> I'm not against this flag. But, it should just be a signal of the serv= er >>> for the client, saying "I'm doing stateless connection establishment". = In >>> the end, it's the client who will decide if he wants to trade this >>> additional RTT for assured MPTCP-connectivity or not. >>> >>> >>> Cheers, Christoph >>> >>> >>> > -----Original Message----- From: Christoph Paasch >>> > [mailto:christoph.paasch@uclouvain.be] Sent: Wednesday, July 24, 2013 >>> > 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtc= p] >>> > MP_CAP Final ack drop and fallback behavior >>> > >>> > Hello Krishna, >>> > >>> > On 24/07/13 - 08:05:40, Krishna Khanal wrote: >>> > > Hi, For stateless implementation of MP_CAPABLE flow, there is no wa= y >>> > > to continue with MPTCP if the final ack of 3-way MP_CAP handshake i= s >>> > > dropped or the data packet is received before the MP_CAP ack due to >>> > > out of ordering of the packet in the network. Only way to continue >>> > > with the transaction is to fallback to regular TCP and there is a >>> > > pretty much chance of happening this in the real network. So, there= is >>> > > always a requirement of fallback even if the middle devices support= s >>> > > and understands MPTCP. >>> > > >>> > > Is there any thought on making MP_CAP final ack reliable like MP_JO= IN >>> > > final ack or including MP_CAP final ack options with the data packe= t >>> > > along with DSS packet until the ack is received? Second, option may >>> > > not be suitable because it consumes all the option space and first >>> > > option also tend to increase the handshake duration and block the >>> > > request by atleast an RTT. >>> > > >>> > > Any thought? >>> > >>> > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent= in >>> > a reliable way, as it is done today for the third ACK with the MP_JOI= N. >>> > But this got removed due to the additional RTT: >>> > >>> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.ht= ml >>> > >>> > >>> > Then, the status of the draft was for some time that MPTCP was doing >>> > reliable transmission of the third ACK+MP_CAPABLE, but allowed sendin= g >>> > data before the arrival of this third ACK. However, this did not help= , >>> > as early arrival of data (prior to the third ACK) will still trigger = a >>> > fallback. So, the MPTCP-draft changed to a non-retransmitting third-a= ck >>> > as it is for today: >>> > >>> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.ht= ml >>> > >>> > >>> > It would not be possible to combine MP_CAPABLE with the DSS-option an= d >>> > still use stateless connection establishment: >>> > >>> > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4 >>> > bytes (Subflow-seq) + 4 bytes (Data-length + csum) =3D 16 bytes >>> > >>> > So, there are 4 more bytes left. This would mean that we cannot put t= he >>> > Timestamp-option, which is required for stateless connection >>> > establishment. >>> > >>> > >>> > >>> > Cheers, Christoph >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp From grmocg@gmail.com Tue Jul 30 06:16:10 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE96721F9E12 for ; Tue, 30 Jul 2013 06:16:10 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98ILuzomDzPq for ; Tue, 30 Jul 2013 06:16:10 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC021F9DF7 for ; Tue, 30 Jul 2013 06:16:10 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i4so3288644oah.37 for ; Tue, 30 Jul 2013 06:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ehK/uFAx6JSuYToeTmCJNZaAJlFKpeidcd3U+CJBWDI=; b=CZqfMc2ZrzoC5NttLVj/6dHSvlxdzLxblCkOOiMssIOUKgLdkAXqeX3n6shjUU0ZRk hH9McW6Z1LPLbjVInynHyj2Uziw7rjEOeDj2jiIpB5k/MtTdZOztNhw89p+Ix4zmJgQi uqze3Ea9MVK2TDavBS1Q9Zg2yILyeZKtBjWIQyJesxPy42vrFXEwuXO3ZYrislOIHtxH Fz5ounmuz8+qrOy9D4/2+rL8lQwOx/LvPPoFJOYevnqNgGoXs1WDw1BNcJayi8VhnibM 4YelUce6z9zlGbOpk20Cvud4rLnxk5elCRgtOXfaVa9NmGea33Y3g6mLv8VT5fNohaAG RoBg== MIME-Version: 1.0 X-Received: by 10.182.129.17 with SMTP id ns17mr56010669obb.13.1375190168925; Tue, 30 Jul 2013 06:16:08 -0700 (PDT) Received: by 10.76.91.229 with HTTP; Tue, 30 Jul 2013 06:16:08 -0700 (PDT) Received: by 10.76.91.229 with HTTP; Tue, 30 Jul 2013 06:16:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 15:16:08 +0200 Message-ID: From: Roberto Peon To: multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1fbb0847f8904e2ba69ee Subject: Re: [multipathtcp] Clarification on the attack type on which I spoke about on-mic at the meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:16:11 -0000 --e89a8fb1fbb0847f8904e2ba69ee Content-Type: text/plain; charset=ISO-8859-1 On Jul 30, 2013 2:55 PM, "Roberto Peon" wrote: > > The premise of this attack is that some 3rd party wishes to snoop upon communications and perform detailed analysis on the content of a conversation. > > To "attack" a TCP stream, the in-path device must either store, forward, or analyze the data itself. > These are all relatively costly options. > > With MPTCP as it exists today, this cost is vastly reduced for such an in-path attacker as an in-path attacker could instead (via ADD_ADDR or other methods) cause the connection to be re-routed to an entity running on centralized resources. > > As I'm sure we'll hear from the security folks, the only way to deal with this, assuming it is serious enough that we must (and I believe it probably is, given similar attacks against application-layers that we've seen published), is to have reasonable (cryptographic) proof that either party is actually generating the changes in the control-plane. > > -=R --e89a8fb1fbb0847f8904e2ba69ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 30, 2013 2:55 PM, "Roberto Peon" <grmocg@gmail.com> wrote:
>
> The premise of this attack is that some 3rd party wishes to snoop upon= communications and perform detailed analysis on the content of a conversat= ion.
>
> To "attack" a TCP stream, the in-path device must either sto= re, forward, or analyze the data itself.
> These are all relatively costly options.
>
> With MPTCP as it exists today, this cost is vastly reduced for such an= in-path attacker as an in-path attacker could instead (via ADD_ADDR or oth= er methods) cause the connection to be re-routed to an entity running on ce= ntralized resources.
>
> As I'm sure we'll hear from the security folks, the only way t= o deal with this, assuming it is serious enough that we must (and I believe= it probably is, given similar attacks against application-layers that we&#= 39;ve seen published), is to have reasonable (cryptographic) proof that eit= her party is actually generating the changes in the control-plane.
>
> -=3DR

--e89a8fb1fbb0847f8904e2ba69ee-- From alan.ford@gmail.com Wed Jul 31 08:01:50 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ED121F859A for ; Wed, 31 Jul 2013 08:01:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJVOVTGgZjR8 for ; Wed, 31 Jul 2013 08:01:48 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 68DDA21F8BE6 for ; Wed, 31 Jul 2013 08:00:56 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hq12so764279wib.4 for ; Wed, 31 Jul 2013 08:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZLN90m79+fr2mI+QK6+i66ToqLIHl8nrbXdr/jOhkW0=; b=kkPRcAkY2IkQxbq5VfaCuESBh0un+l8frP40liRzwMulcZB0u91uZ4pQX1WS6A2Bsp t8JLv8kD3qxVUtvTFIAq9Se/fvc7VqEWVa4MXYSHz7riSY9gSzryyoYXxTG4OsydHDC2 N2Mb56BfikTBVIQ/SY+oHLFrwDUROfK/mWiENO3FKb/lYUuvpDbLS6ex8kWDogYuMbRT j/AjQYQRFRSZqDFvm+u0+s7JpzGYMBvf9VBIjC/kJZZXfHbzS8QxNoYGmy8JabGhij0h WVPkaoNBr5iYsxHBZfYyLjW6ifh0X+JThegQcgFdT53xgI9s8AfxxVoDznMlCnSLLRkW PfMQ== MIME-Version: 1.0 X-Received: by 10.194.58.239 with SMTP id u15mr49960819wjq.87.1375282855420; Wed, 31 Jul 2013 08:00:55 -0700 (PDT) Received: by 10.216.20.196 with HTTP; Wed, 31 Jul 2013 08:00:55 -0700 (PDT) In-Reply-To: <51E4E881.1080206@it.uc3m.es> References: <20130714200737.6455.95956.idtracker@ietfa.amsl.com> <51E4E881.1080206@it.uc3m.es> Date: Wed, 31 Jul 2013 16:00:55 +0100 Message-ID: From: Alan Ford To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=047d7ba97b94102c9004e2cffe4b Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] Fwd: I-D Action: draft-bagnulo-mptcp-attacks-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:01:50 -0000 --047d7ba97b94102c9004e2cffe4b Content-Type: text/plain; charset=ISO-8859-1 All, If we as a WG feel that this is a sufficiently large risk (and the general feeling I got from the meeting yesterday is that it probably is - although the probabilities do seem small, the impact of a successful attack is large), let's look at the practicalities of the solutions. Taking the two practical options: Option 1: Include token of receiving host (let's call them B) in ADD_ADDR. Costs: * 4 bytes additional Impact: * Requires attacker to have seen an MP_JOIN or MP_CAPABLE packet, or guess a 2^32 number Option 2: Include HMAC(Key-B, New_IP_Addr) Costs: * 8 bytes additional (arbitrarily picked 64-bit truncated HMAC here, like MP_JOIN, but it could be shorter) Impact: * Requires attacker to have seen MP_CAPABLE exchange, or guess as 2^64 number We would (just!) have space for either option in the remaining TCP option space. Option 2 seems to have better security. However, the only thing that worries me about Option 2 is that it means a middlebox cannot legitimately insert an ADD_ADDR if it has not seen the original MP_CAPABLE: say it was a middlebox on a secondary subflow only, it would only know the token. But if it wanted to allow an end host to connect out to another of its addresses, it would not be able to do this. Whether that is a legitimate use case I am not sure yet; right now I can't see it being a huge loss to remove this capability while introducing better security. But for now, this is still an open issue. A minor oversight in 6824, too: we also seem not to have cited RFC5961 directly, but rather via the TCP security survey draft. Hopefully the requirement is nevertheless clear to implementers. Regards, Alan On 16 July 2013 07:30, marcelo bagnulo braun wrote: > Hi, > > We have submitted a new draft discussing some residual attacks we > identified in MPTCP spec. > Comments are welcome. > > Regards, marcelo > > > > -------- Mensaje original -------- Asunto: I-D Action: > draft-bagnulo-mptcp-attacks-00.txt Fecha: Sun, 14 Jul 2013 13:07:37 -0700 De: > internet-drafts@ietf.org Responder a: internet-drafts@ietf.org Para: > i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Analysis of MPTCP residual threats and possible fixes > Author(s) : Marcelo Bagnulo > Christoph Paasch > Fernando Gont > Olivier Bonaventure > Costin Raiciu > Filename : draft-bagnulo-mptcp-attacks-00.txt > Pages : 16 > Date : 2013-07-14 > > Abstract: > This documents performs an analysis of the residual threats for MPTCP > and explores possible solutions to them. > > > The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attacks > > There's also a htmlized version available at:http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00 > > > Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing listI-D-Announce@ietf.orghttps://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --047d7ba97b94102c9004e2cffe4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

If we as a WG feel tha= t this is a sufficiently large risk (and the general feeling I got from the= meeting yesterday is that it probably is - although the probabilities do s= eem small, the impact of a successful attack is large), let's look at t= he practicalities of the solutions. Taking the two practical options:

Option 1: Include token of receiving host (let's call th= em B) in ADD_ADDR.
Costs:
* 4 bytes additional
Impact:
* Requires attacker to have seen an MP_JOIN or MP_CAPAB= LE packet, or guess a 2^32 number

Option 2: Include HMAC(Key-B, New_IP_Addr)
Costs:
* 8 bytes additional (arbitrarily pic= ked 64-bit truncated HMAC here, like MP_JOIN, but it could be shorter)
Impact:
* Requires attacker to have seen MP_CAPA= BLE exchange, or guess as 2^64 number

We wou= ld (just!) have space for either option in the remaining TCP option space. = Option 2 seems to have better security.

However, the only thing that worries me about Opt= ion 2 is that it means a middlebox cannot legitimately insert an ADD_ADDR i= f it has not seen the original MP_CAPABLE: say it was a middlebox on a seco= ndary subflow only, it would only know the token. But if it wanted to allow= an end host to connect out to another of its addresses, it would not be ab= le to do this.

Whether that is a legitimate use case I am = not sure yet; right now I can't see it being a huge loss to remove this= capability while introducing better security. But for now, this is still a= n open issue.

A minor oversight in 6824, too: we also seem not = to have cited RFC5961 directly, but rather via the TCP security survey draf= t. Hopefully the requirement is nevertheless clear to implementers.

Regards,
Alan


On = 16 July 2013 07:30, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
=20 =20 =20
Hi,

We have submitted a new draft discussing some residual attacks we identified in MPTCP spec.
Comments are welcome.

Regards, marcelo


-------- Mensaje original --------
Asunto: I-D Action: draft-bagnulo-mptcp-attacks-00.txt
Fecha: Sun, 14 Jul 2013 13:07:37 -0700
De: internet-drafts@ietf.org
Responder a: internet-drafts@ietf.org
Para: = i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Draf=
ts directories.


	Title           : Analysis of MPTCP residual threats and possible fixes
	Author(s)       : Marcelo Bagnulo
                          Christoph Paasch
                          Fernando Gont
                          Olivier Bonaventure
                          Costin Raiciu
	Filename        : draft-bagnulo-mptcp-attacks-00.txt
	Pages           : 16
	Date            : 2013-07-14

Abstract:
   This documents performs an analysis of the residual threats for MPTCP
   and explores possible solutions to them.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attack=
s

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp=
.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet=
f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt



_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp


--047d7ba97b94102c9004e2cffe4b--