Hello,

To presenters, please send your = slides to chairs ** by Thursday (11/13) Afternoon **.=C2=A0

<= /div>

To attendees, If you're interested in note taking or jabber s= cribbling, please let us know. We can give you brief introduction if you= 9;re not familiar.

We appreciate your cooperation.
Thanks,
--
Yoshi and Phil

--047d7bb04ba2df1bde050760c7da-- From nobody Mon Nov 10 01:03:48 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9CF1A0183 for ; Sat, 8 Nov 2014 13:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfvdyOJ-0R3j for ; Sat, 8 Nov 2014 13:34:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0261A0197 for ; Sat, 8 Nov 2014 13:34:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: multipathtcp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141108213419.29152.76560.idtracker@ietfa.amsl.com> Date: Sat, 08 Nov 2014 13:34:19 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/psmoacWGMX1FXNt8VU2J3O0V-Is X-Mailman-Approved-At: Mon, 10 Nov 2014 01:03:46 -0800 Subject: [multipathtcp] Milestones changed for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 21:34:21 -0000 Changed milestone "Consensus on what high-level changes are needed to the current MPTCP Experimental document in order to progress it on the standards track", resolved as "Done". Changed milestone "Use-cases and operational experiences (Informational) to IESG", set due date to January 2015 from August 2013. Changed milestone "MPTCP standards track protocol to IESG", set due date to January 2015 from December 2013. Changed milestone "Implementation advice (Informational) to IESG", set due date to April 2015 from April 2013. Changed milestone "MPTCP-enabled middleboxes (Informational) to IESG", set due date to April 2015 from December 2013. Changed milestone "Re-charter or close", set due date to April 2015 from January 2014. URL: http://datatracker.ietf.org/wg/mptcp/charter/ From nobody Thu Nov 13 12:52:47 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C9D1AD479 for ; Thu, 13 Nov 2014 12:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJHJNKUcspnC for ; Thu, 13 Nov 2014 12:52:31 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A19551AD435 for ; Thu, 13 Nov 2014 12:51:35 -0800 (PST) Received: from mbpobo-2.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 87EFE19800F for ; Thu, 13 Nov 2014 21:51:29 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 87EFE19800F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1415911889; bh=08KYnbpU2345eZ/gPb5SXLcr/cGp/JCPU/MUyaqhjGs=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=qklXil6guU1uixVlBsGZPmm0TcSh9EqSnWOyAfTLccDFJPT8XTtiOipGiMwMBZZ24 hjLffXiE6g90j9CSqH4Z7ZZLqXT5moeo7abjhZkexvXZmg9Y3XRvmTohv+hc2KyOx4 0pVcDNvRozilEe8fA9bxG7E3KtLn8sHcJSTrgVAo= Message-ID: <546519D1.3050501@uclouvain.be> Date: Thu, 13 Nov 2014 21:51:29 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 87EFE19800F.A1917 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/lxaq46u1N4_EsQ8tNT5JjI6727A Subject: [multipathtcp] Extending the MPTCP option space X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:52:39 -0000 Hello, There are currently various discussions on the TCPM mailing on how to extend the limited TCP option space to be able to place more TCP options in the SYN segment and inside regular segments. One of the motivations often mentioned for this discussion in the TCPM working group is that longer TCP options would be beneficial for Multipath TCP. This is correct, but we should also remember that MPTCP provides more flexibility than regular TCP for this. In particular, the DSS option used by Multipath TCP allows to map data. This option could be extended to support other usages. In https://tools.ietf.org/html/draft-paasch-mptcp-control-stream-00, we have shown that it was possible to modify the DSS option to support two different bytestreams on a single MPTCP connection. One of these bytestreams is the regular bytestream used by the application. The other could be devoted to the (reliable) transport of any control information, including TCP options. If we consider that having two separate bytestreams is too complex, we could use one of the spare bits in the DSS option to indicate that a DSS mapping contains TCP options and possibly normal data. A typical segment would then become : The outer tcp options are the options that cannot be transported reliably, all the others should be placed inside the dss-mapped data and the EOL option defined in RFC793 serves as a marker to separate the TCP options from the payload. This solution seems to me reasonably clean and has the advantage of supporting large options (the hard limit for each option becomes its length field and all the options must fit inside a single mapping - up to 64 kbytes). It does not solve the problem of the SYN segment, but in this case using a TFO solution to encode options instead of data inside the payload could work in many environments and https://tools.ietf.org/html/draft-barre-mptcp-tfo-00 has shown that TFO and MPTCP could be coupled together Olivier From nobody Thu Nov 13 15:45:07 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED151AE31E for ; Thu, 13 Nov 2014 15:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozOY5J1voWuN for ; Thu, 13 Nov 2014 15:45:02 -0800 (PST) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6911AE317 for ; Thu, 13 Nov 2014 15:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=fortinet.com; s=20131225; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version:x-feas-system-wl; bh=Q0QYjhQpNEdNSlGw1RQVmA43IfTh0IXmCvipQpYJdtE=; b=MkxPokZ8zU/0q2tSVBvjMIsZ/nRzgoNtk+bKEk/wIxWJ3aS01z7qfjGlogAU61VghB6xO9XkzOY1pTxmufOZqi2B0McfkekW4rx/hAr/AQvmrhnrl0mlasrZ02ylu5ySs9a8BWs5dIrVqpySqjCeVCqWdyn+O33uU0287Kvvc2A9IiJH+0lDUpqtryYpItxW9qfxX0XidIHKQYduHdWM1C6z4k+3QaryhmtF8sgCNjpS78mOAYkeKt5QoOWmOj5coVUzKu0iEH7XE31tLGfmiy7QzWzpCY90Kf+g24Q9SkOtsMhdU5IERYVAipLR7eJh9pcJ0DFRWSmITYcS6KooEg== From: Edward Lopez To: "multipathtcp@ietf.org Mailing List" Thread-Topic: MPTCP and middle box behavior Thread-Index: AQHP/5vXdE3zkmc5+EC8xeFEiieXgQ== Date: Thu, 13 Nov 2014 23:45:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.166.166] Content-Type: multipart/alternative; boundary="_000_B456561CB6CA4D8C8516818046A1AC4Bfortinetcom_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: 192.168.221.213 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/HUWXj7cZ6S5thGlvCe2-wN3NkDU Subject: [multipathtcp] MPTCP and middle box behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:45:04 -0000 --_000_B456561CB6CA4D8C8516818046A1AC4Bfortinetcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBqdXN0IHBvc3RlZCBhIGRyYWZ0LCBsYWJlbGVkICdkcmFmdC1sb3Blei1tcHRjcC1taWRkbGVi b3gtMDDigJkgb24gJ011bHRpcGF0aCBUQ1AgTWlkZGxlYm94IEJlaGF2aW9y4oCZLiAgVGhpcyBk cmFmdCBleHBsb3JlcyB0aGUgcG90ZW50aWFsIGltcGFjdCBvZiBleGlzdGluZyBtaWRkbGVib3hl cyBvbnRvIE1QVENQIHNlc3Npb25zLCBhcyB3ZWxsIGFzIHByZWRpY3RzIHBvdGVudGlhbCByZXNw b25zZXMgYnkgZGV2ZWxvcGVycyBhbmQgZGVwbG95ZXJzIG9mIG1pZGRsZWJveGVzLiAgSSBhcHBy ZWNpYXRlIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4NCg0KRWQgTG9wZXoNCkZvcnRpbmV0DQoK KioqICBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCAKYW5kIHByb3ByaWV0YXJ5IG1hdGVyaWFsIGFuZCBpbmZv cm1hdGlvbiBhbmQgYXJlIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlv dSBhcmUgaGVyZWJ5IApub3RpZmllZCB0aGF0IGFueSByZXZpZXcsIHVzZSwgZGlzY2xvc3VyZSwg ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgCm9mIHRoaXMgbWVzc2FnZSBh bmQgYW55IGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIAp0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlc3Ryb3kgdGhpcyBlLW1haWwgCmFuZCBhbnkgYXR0YWNobWVudHMgYW5k IGFsbCBjb3BpZXMsIHdoZXRoZXIgZWxlY3Ryb25pYyBvciBwcmludGVkLgpQbGVhc2UgYWxzbyBu b3RlIHRoYXQgYW55IHZpZXdzLCBvcGluaW9ucywgY29uY2x1c2lvbnMgb3IgY29tbWl0bWVudHMg ZXhwcmVzc2VkIAppbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlZmxlY3QgCnRoZSB2aWV3cyBvZiBGb3J0aW5l dCwgSW5jLiwgaXRzIGFmZmlsaWF0ZXMsIGFuZCBlbWFpbHMgYXJlIG5vdCBiaW5kaW5nIG9uIApG b3J0aW5ldCBhbmQgb25seSBhIHdyaXRpbmcgbWFudWFsbHkgc2lnbmVkIGJ5IEZvcnRpbmV0J3Mg R2VuZXJhbCBDb3Vuc2VsIGNhbiBiZSAKYSBiaW5kaW5nIGNvbW1pdG1lbnQgb2YgRm9ydGluZXQg dG8gRm9ydGluZXQncyBjdXN0b21lcnMgb3IgcGFydG5lcnMuIFRoYW5rIHlvdS4gKioq --_000_B456561CB6CA4D8C8516818046A1AC4Bfortinetcom_ Content-Type: text/html; charset="utf-8" Content-ID: <4203D1DFA5876140A4EA9B9A2859C360@fortinet-us.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBqdXN0IHBvc3RlZCBhIGRyYWZ0 LCBsYWJlbGVkICc8Zm9udCBmYWNlPSJIZWx2ZXRpY2EgTmV1ZSIgY2xhc3M9IiI+ZHJhZnQtbG9w ZXotbXB0Y3AtbWlkZGxlYm94LTAw4oCZIG9uICdNdWx0aXBhdGggVENQIE1pZGRsZWJveCBCZWhh dmlvcuKAmS4gJm5ic3A7VGhpcyBkcmFmdCBleHBsb3JlcyB0aGUgcG90ZW50aWFsIGltcGFjdCBv ZiBleGlzdGluZyZuYnNwO21pZGRsZWJveGVzIG9udG8gTVBUQ1Agc2Vzc2lvbnMsIGFzIHdlbGwg YXMgcHJlZGljdHMgcG90ZW50aWFsDQogcmVzcG9uc2VzIGJ5IGRldmVsb3BlcnMgYW5kIGRlcGxv eWVycyBvZiZuYnNwO21pZGRsZWJveGVzLiAmbmJzcDtJIGFwcHJlY2lhdGUgeW91ciByZXZpZXcg YW5kIGNvbW1lbnRzLjwvZm9udD4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iSGVsdmV0aWNh IE5ldWUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIE5ldWUiIGNsYXNzPSIiPkVkIExvcGV6PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJIZWx2ZXRpY2EgTmV1ZSIgY2xhc3M9IiI+ Rm9ydGluZXQ8L2ZvbnQ+PC9kaXY+DQoKPGZvbnQgYmdjb2xvcj0iI2ZmZmZmZiIgY29sb3I9IiMw MDAwMDAiPjxiPjxCUj48SFI+CioqKiAgUGxlYXNlIG5vdGUgdGhhdCB0aGlzIG1lc3NhZ2UgYW5k IGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgCmFuZCBwcm9wcmlldGFy eSBtYXRlcmlhbCBhbmQgaW5mb3JtYXRpb24gYW5kIGFyZSBpbnRlbmRlZCBvbmx5IGZvciB0aGUg dXNlIG9mIAp0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSAKbm90aWZpZWQgdGhhdCBhbnkgcmV2aWV3 LCB1c2UsIGRpc2Nsb3N1cmUsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5n IApvZiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCAKdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIGlt bWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZXN0cm95IHRoaXMgZS1tYWlsIAphbmQg YW55IGF0dGFjaG1lbnRzIGFuZCBhbGwgY29waWVzLCB3aGV0aGVyIGVsZWN0cm9uaWMgb3IgcHJp bnRlZC4KUGxlYXNlIGFsc28gbm90ZSB0aGF0IGFueSB2aWV3cywgb3BpbmlvbnMsIGNvbmNsdXNp b25zIG9yIGNvbW1pdG1lbnRzIGV4cHJlc3NlZCAKaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZWZsZWN0IAp0 aGUgdmlld3Mgb2YgRm9ydGluZXQsIEluYy4sIGl0cyBhZmZpbGlhdGVzLCBhbmQgZW1haWxzIGFy ZSBub3QgYmluZGluZyBvbiAKRm9ydGluZXQgYW5kIG9ubHkgYSB3cml0aW5nIG1hbnVhbGx5IHNp Z25lZCBieSBGb3J0aW5ldCdzIEdlbmVyYWwgQ291bnNlbCBjYW4gYmUgCmEgYmluZGluZyBjb21t aXRtZW50IG9mIEZvcnRpbmV0IHRvIEZvcnRpbmV0J3MgY3VzdG9tZXJzIG9yIHBhcnRuZXJzLiBU aGFuayB5b3UuICoqKgo8QlI+PEhSPjwvYj48L2ZvbnQ+CjwvYm9keT4NCjwvaHRtbD4N --_000_B456561CB6CA4D8C8516818046A1AC4Bfortinetcom_-- From nobody Fri Nov 14 00:49:34 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9933E1A6F03 for ; Fri, 14 Nov 2014 00:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkuOl5giRLKs for ; Fri, 14 Nov 2014 00:49:27 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4763F1A00CA for ; Fri, 14 Nov 2014 00:49:27 -0800 (PST) Received: from wifi-secure1-507.sri.ucl.ac.be (wifi-secure1-507.sri.ucl.ac.be [130.104.109.251]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 805761982D2; Fri, 14 Nov 2014 09:49:15 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 805761982D2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1415954955; bh=LKbKQFNMVf0a5FwDiM1yXKwbFfy7sjj0KNpov7Ves/c=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WqnMS3Zm29HXlXND2uCgf3gyyAN+hYFVyONyIIrTDxMlMCdMmLdrps7iR+BVVHDn6 YrQTGlhDP3vL/HFFf4xpO8ECRV8UAM+ACa0wltm1XTOxXCibvKVIowHH+SpiqDoVDI YH4IIzhf5Ve2DqEQTB5MwtyeucDG992jcxMy9oZE= Message-ID: <5465C20C.4070208@uclouvain.be> Date: Fri, 14 Nov 2014 09:49:16 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Edward Lopez , "multipathtcp@ietf.org Mailing List" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 805761982D2.A2968 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/KJMk83M9aYrYztaZNJLbOnAkDPE Subject: Re: [multipathtcp] MPTCP and middle box behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 08:49:31 -0000 Ed, > I just posted a draft, labeled 'draft-lopez-mptcp-middlebox-00� on > 'Multipath TCP Middlebox Behavior�. This draft explores the potential > impact of existing middleboxes onto MPTCP sessions, as well as predicts > potential responses by developers and deployers of middleboxes. I > appreciate your review and comments. Thanks for your draft. As I'm not in Hawai, here are some initial comments. Section 1 The MPTCP design was heavily influenced by the requirement to traverse various types of (TCP-aware) middleboxes. As you point in your document, there will probably be MPTCP-aware middleboxes that will appear in the future. When considering these middleboxes, we need to distinguish between implicit middleboxes that operate "transparently" on-path and explicit middleboxes. Usually, neither the client nor the server are aware of the existance of the on-path middleboxes. Such middleboxes exist, but pose a wide range of problems as explained in http://www.ietf.org/id/draft-hildebrand-middlebox-erosion-01.txt This short draft should be read by anyone working on middleboxes... The explicit middleboxes are more interesting and more useful to discuss. These middleboxes can be known by the client and/or the server. An example of an explicit middlebox is an MPTCP-aware load balancer that sits in front of a normal TCP server. Section 2 " The existence and utilization of multiple forwarding paths, and the use of different IP source and destination addresses on each subflow is inconsequential to the network, as it is the MPTCP endpoints that are responsible for the overall MPTCP session integrity." I agree with the first part of the sentence. We are now on an Internet which is different from the Internet of the early 2000s when most middleboxes that are deployed today were invented. Today, a typical device has multiple interfaces. Even the single-homed devices have multiple addresses when they are dual-stack. Unfortunately, many middleboxes still assume that we live in an early 2000s Internet. Now that endhosts have multiple addresses, they try to use them. Various techniques exist and are used at different layers of the protocol stack. At the application layer, happyeyeballs uses different interfaces/addresses to distribute http requests. Several applications use HTTP range requests to distribute data over different interfaces. Thanks to its standardisation, MPTCP should be considered as an opportunity to better organise the utilisation of the different interfaces on the endhosts. " A strong example of an erroneous middlebox result would be the resulting false-negatives due to failures in signature-matching functions, since the matching data is distributed across multiple TCP subflows. " An explicit middlebox would by design be able to see all the packets belonging to an MPTCP connection. Reassembling all the data at the MPTCP level is different than reassembling at the TCP connection level but is feasible. This will require additional code on the middelboxes that want to observe all the traffic. 2.1 The single-session bias is inded a problem for many existing middleboxes. "However, other packet transformations, such as manipulation of DiffServ values or payload substitutions, can have very unintended effects of the overall MPTCP session." I do not understand how Diffserv tagging would affect MPTCP. Could you be more precise ? Concerning payload substitution, if the length of the data changes, MPTCP would fall back to regular TCP thanks to the DSS checksum (if enabled). " The issuance of a TCP reset (RST) by a middlebox only fast closes the individual TCP subflow, and not the overall MPTCP session. " Indeed and as explained in http://tools.ietf.org/html/draft-bonaventure-mptcp-tls-00 MPTCP can react to a RST inserted by a middlebox and reestablish a subflow over the same or another path. "Ultimately, the solution to overcoming single-session bias effect will require evolution of middleboxes that are MPTCP-aware." MPTCP-aware middleboxes should be explicit and not implict. There are many interesting things that can be done with explicit middleboxes, see e.g. http://inl.info.ucl.ac.be/publications/multipath-middlebox http://inl.info.ucl.ac.be/publications/evolving-internet-connection-acrobatics 2.2 "A grave issue would be in the substitution of data within a single TCP subflow, and its impact on the overall MPTCP session. There are no functions defined in which the integrity of data contained within one TCP subflow is validated by another subflow. " I'm not sure I correctly understand these sentences. Do you discuss the substitution of data by a middlebox or something else ? What kind of function integrity would you expect ? 3 Independent Responses By Middlebox Providers "The likely outcome is that providers of middleboxes will initially view MPTCP traffic as an attack relative to their operation. " A consequence of this could be that MPTCP hosts would see middlebox interference as an attack on a given path and could decide to stop using this path. For example, consider a smartphone that uses 3G and WiFi. If there is a middlebox on the WiFi path that blocks MPTCP, then the smartphone could decide to only use 3G where there is no middlebox interference. 3.1 MPTCP Fallback to TCP " This is easily accomplished in one of two ways. First is to drop TCP traffic that contains TCP Options for MPTCP. Second is to filter out TCP Options for MPTCP, and forward the packet without the options." This is what some firewalls do today by removing the MP_CAPABLE option from the SYN or replacing it with NOOP. Note that a host can detect this behaviour and stop using this path. If middlebox vendors want to go in this direction, the clean solution is to remove the MP_CAPABLE option from the SYN segments. 3.2 " It may also occur that a middlebox, rather than detecting the start of an MPTCP session, may instead detect the creation of a new TCP subflow via a Join Connection (MP_JOIN) MPTCP option. The issuance of a TCP Reset (RST) would only affect this TCP subflow, but not the overall MPTCP session." Removing the MP_JOIN option form the SYN would result in a RST and all the traffic would be sent on the other path where there is (hopefully) no middlebox. " RFC-6824 [RFC6824] does allow for fast closure of an overall MPTCP session, via the MP_FASTCLOSE option. However, this option must be authenticated with the key of the host to which it is sent. A middlebox, with only visibility of an MP_JOIN would not have knowledge of the key credentials of either Host A or Host B to be able to masquerade an MP_FASTCLOSE option. This is of course a trade-off. While middlebox providers may desire the ability to issue third-party MP_FASTCLOSE options to both MPTCP hosts, providing the ability to do so would present a significant security challenge. Middleboxes have little recourse when only in the path of secondary TCP subflows of an MPTCP session." Again we need to distinguish between explicit and implict middleboxes. An implicit middlebox should not be able to close an MPTCP session. Otherwise an attacker could do the same. For explicit middleboxes, we could imagine solution where a host transfers some credentials (e.g. the authentication keys) to the middlebox. There are other ways that a middlebox could mess up with MPTCP, but I don't think that it would be useful to list all possible interactions in an IETF draft. 3.5 " The in-path model is in essence an MPTCP<>MPTCP proxy, in which a middlebox inserts itself as a man-in-the-middle (MITM) between two MPTCP endpoints" By design, this in-path model is broken because it is impossible to ensure that all packets will always pass through the MPTCP proxy if it operates as a MITM. It could work in some ISP networks that control both WiFi and 3G and hope that all the traffic from their users will pass through their gateways, but users expect to be able to use any WiFi together with their 3G network and thus some traffic will bypass this transparent proxy. "The out-of-path model assumes that MPTCP capable endpoints, or downstream devices, will encapsulate their traffic, or a copy of their traffic, to a third-party middlebox." I think that we need to distinguish between server-side proxies and client-side proxies. A server-side proxy is similar to a load-balancer and will probably rely on the DNS to announce itself and always appear on path. A client-side proxy is different. The client needs to be explicitly configured to always forward its MPTCP traffic via its designated proxy. This proxy could provide additional services to the client such as firewall/IDS, session survivability when the client moves and becomes unreachable, data buffering, ... Encapsulation is a possible way to force the traffic from the client to reach the proxy, but there are probably other solutions. " Note that the MPTCP endpoints do not need to explicitly negotiate such a proxy, and may not even be aware of such a proxy taking place." But one of the endpoints must be aware of the existence of the proxy. If you develop such a solution, then a chain of proxies should become possible. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Fri Nov 14 13:19:57 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0F61ACD60 for ; Fri, 14 Nov 2014 13:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7cBqk3BBpWI for ; Fri, 14 Nov 2014 13:19:52 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AC01ACD7D for ; Fri, 14 Nov 2014 13:19:51 -0800 (PST) Received: from [10.119.8.6] (108.62.56.236.rdns.as15003.net [108.62.56.236]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0MacX9-1XaCm42Jw1-00K8D4; Fri, 14 Nov 2014 22:19:45 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_90D3164E-F21A-47BB-9BAC-0E8FEF79681F" From: Alper Yegin In-Reply-To: <5465C20C.4070208@uclouvain.be> Date: Fri, 14 Nov 2014 23:19:38 +0200 Message-Id: <31A01A95-F7D6-47E2-98C9-ABACE527FFBA@yegin.org> References: <5465C20C.4070208@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:5rEibHBLgqqJm/Z+hT3Ry/U/0HIycBMCiDdbMBYFHNC OwoSVRM8Xxmz6FI1Ezq8xwkP9F5cgf3Uf+55jLqrnJgTVSxRqU Tp+2jz+2Fr4pGcVlK15ilyjbbU6D4wh1cqRkEAXXDwJLJkCf6f MAE8d1m0Y4A5E1er7WFjKIN5NbKB9LwVlHsLxsPSA8l0oTLoPF /T2Eg/KREXe02uAMxWDVCVsZ+eY3jaSrHcUbQL5gcpvB04LlYe uhNU/NvmLeQ6MxTGz0LvmpSB+auXrqGKg/6aNmIfd8lob55iLz WzH4tWU7Vgs2ioq/LaMPP5pkeEYXrziPDgfiG/SX26S1OAmDrO P4/KtAiHMz1r6vpIgcrDylAXM+/D4sN2tQMnfb87h73KeO5EJd 9QlYFIfQ/T6NQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/dosaiCm5uIprcNm1SkHwU4eEuc8 Cc: "multipathtcp@ietf.org Mailing List" Subject: Re: [multipathtcp] MPTCP and middle box behavior X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 21:19:54 -0000 --Apple-Mail=_90D3164E-F21A-47BB-9BAC-0E8FEF79681F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 14, 2014, at 10:49 AM, Olivier Bonaventure wrote: > 3 Independent Responses By Middlebox Providers >=20 > "The likely outcome is that providers of middleboxes will initially > view MPTCP traffic as an attack relative to their operation. " >=20 >=20 > A consequence of this could be that MPTCP hosts would see middlebox = interference as an attack on a given path and could decide to stop using = this path. For example, consider a smartphone that uses 3G and WiFi. If = there is a middlebox on the WiFi path that blocks MPTCP, then the = smartphone could decide to only use 3G where there is no middlebox = interference. Or, give up on MPTCP and use WiFi only. After all, only having a 3G access does not really give the terminal a = chance to utilize MPTCP. One could even imagine a terminal shopping around to find MPTCP-friendly = WiFi networks, but this may not be worth due to complexity and = inefficiency. Network discovery and selection solutions can be augmented to include a = bit for "MPTCP friendliness". Alper --Apple-Mail=_90D3164E-F21A-47BB-9BAC-0E8FEF79681F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

3 Independent = Responses By Middlebox Providers

"The likely outcome = is that providers of middleboxes will initially
view = MPTCP traffic as an attack relative to their operation. "

A = consequence of this could be that MPTCP hosts would see middlebox = interference as an attack on a given path and could decide to stop using = this path. For example, consider a smartphone that uses 3G and WiFi. If = there is a middlebox on the WiFi path that blocks MPTCP, then the = smartphone could decide to only use 3G where there is no middlebox = interference.

Hi, We've uploaded draft minutes for Honolulu meeting at: http://tools.ietf.org/wg= /mptcp/minutes Please check and let us know if you have any comments or suggestions. We appreciate Alex, Richard and Zhuo for very nice note taking and Ed and M= artin for jabber scribble.=C2=A0