From nobody Mon Jul 3 11:20:48 2017 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBA41316F5; Mon, 3 Jul 2017 11:20:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: multipathtcp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910604728.22726.12262054079948108111@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:20:47 -0700 Archived-At: Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-08.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:20:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Addresses Authors : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Christoph Paasch Filename : draft-ietf-mptcp-rfc6824bis-08.txt Pages : 73 Date : 2017-07-03 Abstract: TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824 [RFC6824] through clarifications and modifications primarily driven by deployment experience. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-rfc6824bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 11:23:14 2017 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 1D4C412ECAD for ; Mon, 3 Jul 2017 11:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jJ-p1QxVsf5U for ; Mon, 3 Jul 2017 11:23:11 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4526A1316EA for ; Mon, 3 Jul 2017 11:23:10 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id k67so237719378wrc.2 for ; Mon, 03 Jul 2017 11:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=o/wLzakWD1Yr6vkjJymAwP8pTwU/MMNANEUVFUmcMDQ=; b=hR7ga6zyKlFaK4Z2FaYsj2t3wRfLZ60MlA8olKQ//cUo4LnaS24E6a0xsmkvPjwIdK pRSWuRy56qcx7xoTs18UruHdmo1U43z6Et7Db2ItA1g3S+0TV4tFcRar5/0Ez4fftxOm 75lxWjDTUNAp0pS2nrrF/aCaN8MdXWv99aYmCcZ70TZ04OHNugQYMRrT0qMZTqEtBk5e G99fHurKQ96xkUUCv7KrHCmlK+48kz6JZHqByy9ygqRSSV9Qy2BOvDjcJX3HyxspVZib /A1+Y0JrG6JLDIyEYIZFdFOg0yKBFZ7BAvPHSlaBYXpu3Rk9geW3H4J0V4Dwky5poudR SS4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=o/wLzakWD1Yr6vkjJymAwP8pTwU/MMNANEUVFUmcMDQ=; b=FRc1e08wOxvUo+VoWX203FfbsJ5pO9oce8IM/FD4tb11inyX9bFDlBVJ/FakXkofA2 29V13fupA0VNaAxtbmNzsaHGBN0T47A2q3JhAzpNSga5Ph7U8sjHpEV85VSVrS2fgRUP cw30bcT7VbsYln4mgGD0mI/vuV1hCJ8+XrrUX0ak2z5eo0+X5isoP7yJ6O3As5V+9bqw e9jNzXMQNazc+LKfS6vZ4091g+gLmlu+jK4iC01N7Pu5uTK/8rCtD/6bnq6AWhRsvJvK t4xipx99nzzfsU4IT/J6NrV4MSUn9S2QLcH+H5BwgQUHQjqLDBvDqopfrSMpxOam5F0f QBgQ== X-Gm-Message-State: AKS2vOxLIv6KIZLua8nKksX690+COrq0wTH0mhPTaL8FRALXkKQjKMIu Z+/GG8SIapm6dLQiQzs= X-Received: by 10.223.183.36 with SMTP id l36mr27248991wre.115.1499106188526; Mon, 03 Jul 2017 11:23:08 -0700 (PDT) Received: from alans-mbp.lan (173.177.159.143.dyn.plus.net. [143.159.177.173]) by smtp.gmail.com with ESMTPSA id 55sm23934634wrt.36.2017.07.03.11.23.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Jul 2017 11:23:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <149910604728.22726.12262054079948108111@ietfa.amsl.com> Date: Mon, 3 Jul 2017 19:23:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149910604728.22726.12262054079948108111@ietfa.amsl.com> To: multipathtcp X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-08.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:23:13 -0000 Hi all, This rev of 6824bis contains the clarifications brought forward by = Christoph=E2=80=99s and Olivier=E2=80=99s implementation experiences - = notably clarifying the interchangeabiltiy of MP_CAPABLE and DSS for = initial Data Sequence Mappings, and the sending of TCP RSTs in FASTCLOSE = situation. This revision also now refers to SHA-256 as the hash = algorithm. Regards, Alan > On 3 Jul 2017, at 19:20, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Multipath TCP of the IETF. >=20 > Title : TCP Extensions for Multipath Operation with = Multiple Addresses > Authors : Alan Ford > Costin Raiciu > Mark Handley > Olivier Bonaventure > Christoph Paasch > Filename : draft-ietf-mptcp-rfc6824bis-08.txt > Pages : 73 > Date : 2017-07-03 >=20 > Abstract: > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network and, thus, improve user > experience through higher throughput and improved resilience to > network failure. >=20 > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e., reliable > bytestream), and it provides the components necessary to establish > and use multiple TCP flows across potentially disjoint paths. >=20 > This document specifies v1 of Multipath TCP, obsoleting v0 as > specified in RFC6824 [RFC6824] through clarifications and > modifications primarily driven by deployment experience. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-08 > https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-rfc6824bis-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Jul 4 16:35:25 2017 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 D295A13161E; Tue, 4 Jul 2017 16:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 LOExWUGHkrEE; Tue, 4 Jul 2017 16:35:19 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2A13161D; Tue, 4 Jul 2017 16:35:18 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3ABie8BBJ9CNp3sXb+VtmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgXKvryrarrMEGX3/hxlliBBdydsKMbzbKO+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFKiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPde?= =?us-ascii?q?RWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbY?= =?us-ascii?q?UwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0vRz+s87lkRwPpiC?= =?us-ascii?q?cfNj427mfXitBrjKlGpB6tvgFzz5LIbI2QMvd1Y6HTcs4ARWdZXshfSjJPAo2/?= =?us-ascii?q?YYUBAeUOMuRXoJXmqlQUsRezHxOhCP/hxzJIgHL9wK000/4mEQHDxAEvENYOv2?= =?us-ascii?q?7Jo9X0MacSUPq1x7TRwzXHc/NZxy3y6I7Vchs8pvyMQ7ZwftDMxkkuEgPFj0+Q?= =?us-ascii?q?pZbiPzORyuQCrXKU7+x9Ve+0l2EnsBt9oiCyxsg3kIXJnIUVx0nC+C5kzog1It?= =?us-ascii?q?i4R1R6Yd6iCJZQtj+VN5d4Qs84RGFooik6x7sbspC4ZCgH0IkryhHCZ/CdcIWF?= =?us-ascii?q?4gjvWPiPLTp6nn5odqqziwu9/ES90OHxVcm53ExUoidLnNTArG0B2hPN5sWBV/?= =?us-ascii?q?Bz5F2u2SyV2ADW8uxEJEc0mrfFJJM52b4wk4YTsVzEHi/rhEX6lK+WeVsg+uiv?= =?us-ascii?q?8+nnfLDmqYWdN49wkA3xLr8ultanAeQlKQcCRXKb+eOk2L3i+032XqlKg+Urnq?= =?us-ascii?q?TWrZzWP8cWq66jDwNLzIou6QyzAjm+3NQdh3YHLVZFeBydj4juPlHDOO74DfOl?= =?us-ascii?q?jFuxkTdrwvHGPqf7DpXKKnjDjKnucqx7605B0wc80ctf64hMCrEcO/3/QFXxtN?= =?us-ascii?q?vAAh8jLwO02/rnCMl61o4GRG2PGbOWMKPTsV+O/O0uIuiMaZQPtzblM/gl4+Dh?= =?us-ascii?q?gWUlll8aeKmjxYEXZ2ygHvR6P0WZZmLhjNQHEWcWpwYxVvbqh0OYXjNIZna9Qb?= =?us-ascii?q?485j8hBIKhF4fDSZingKad0yejAp1WemdGB0iJEXf1c4WER/YMaDqILc99kjwE?= =?us-ascii?q?SaSuS5c62BGvqgD617RnIvDT+i0CupLpzMJ16PHLlREu6Tx0CNyQ02SKT2F0hG?= =?us-ascii?q?wIQiE5071lrUNmzVeDzLR3jOZFGtNJ5vNJSBw3NZnGz+NgDdDyVRzOcs2VR1ah?= =?us-ascii?q?R9X1SQ02G9c2w9YLbko7EdK/hRnP1iuwK7gPnrqECdo/9aeYl1T4Ocdxg03N1K?= =?us-ascii?q?gnhksnCp9DLmamh6h25Qn7DpbRl0jfnKGvI/cyxinIoVmHxGaPuUBCGCl0TajM?= =?us-ascii?q?W21XMlXSpNj440LYCbiqFbkuNBZpwtXEMrZALMfu2wYVDMz/McjTNjri01y7Ag?= =?us-ascii?q?yFk/bVNNLn?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DdAgDxJFxZ/wPjVY1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgkSBTQOBDY57kF0imBEuhW4Cg2EBAQEBAQE?= =?us-ascii?q?BAQIBaiiCMyQBgkEBAwItTBALGB0KB0YRBgEMBgIBAYovDLRSKYsTAQEBAQEBA?= =?us-ascii?q?QECAQEBAQEBAQEbBYMng0yBYSsLgm6FIIU+BZFNhVyHXYIik2+FSoNOhnqVMQJ?= =?us-ascii?q?XgQoxIYgZcwGJKQEBAQ?= X-IPAS-Result: =?us-ascii?q?A2DdAgDxJFxZ/wPjVY1cGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgkSBTQOBDY57kF0imBEuhW4Cg2EBAQEBAQEBAQIBaiiCMyQBg?= =?us-ascii?q?kEBAwItTBALGB0KB0YRBgEMBgIBAYovDLRSKYsTAQEBAQEBAQECAQEBAQEBAQE?= =?us-ascii?q?bBYMng0yBYSsLgm6FIIU+BZFNhVyHXYIik2+FSoNOhnqVMQJXgQoxIYgZcwGJK?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,309,1496091600"; d="scan'208,217";a="872857" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 05 Jul 2017 02:35:13 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id CE98C1A60008; Wed, 5 Jul 2017 02:35:12 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6lv9Vk9UkGjk; Wed, 5 Jul 2017 02:35:12 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id AEF781A6006E; Wed, 5 Jul 2017 02:35:12 +0300 (EEST) Received: from [172.19.2.57] (unknown [141.85.233.142]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id A9A7D1A60008; Wed, 5 Jul 2017 02:35:12 +0300 (EEST) From: Vladimir Olteanu To: mohamed.boucadair@orange.com, David Schinazi Cc: "Int-area@ietf.org" , multipathtcp References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Message-ID: Date: Wed, 5 Jul 2017 02:35:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------2357FF80A5B826DBCE30F16F" Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 23:35:24 -0000 This is a multi-part message in MIME format. --------------2357FF80A5B826DBCE30F16F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mohamed, No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as=20 inspiration for SOCKS 6. When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT=20 overhead. It can also be stacked as many times as desired for=20 arbitrarily long proxy chains. However: * We avoid using the SYN's payload as extra option space (which, I=20 think, goes against TCP's core philosophy). The magic number at the=20 start of the MP_CONVERT element implies that if any MPTCP stream happens=20 to start with 0xFAA8FAA8, the client should not use TFO. I think moving=20 up the protocol stack is a more desirable alternative. * We support authentication. Connections to the proxy can also be=20 initiated from networks outside of the operator's control (e.g. home WiFi= s). * SOCKS 6 is easier to extend. If the client needs to request some=20 special behavior from the proxy (e.g. what packet scheduler to use), all=20 we have to do is define (and standardize) a new SOCKS option. (I've also CCed the MPTCP WG). Cheers, Vlad On 07/04/2017 12:09 PM, mohamed.boucadair@orange.com wrote: > > Hi Vladimir, all, > > (focusing only on this part of the message). > > I do fully agree that shortening MPTCP connections setup is key.=20 > Having 0-RTT is an important requirement for this effort. Achieving it=20 > without out-of-band signaling would be even ideal. > > Can you please elaborate on the benefits of your proposal compared to=20 > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-networ= k-assisted-mptcp-03.pdf=20 > which allows to achieve 0-RTT proxying. > > Thank you. > > Cheers, > > Med > > *De :*Int-area [mailto:int-area-bounces@ietf.org] *De la part de*=20 > Vladimir Olteanu > *Envoy=E9 :* vendredi 30 juin 2017 23:37 > *=C0 :* David Schinazi > *Cc :* Int-area@ietf.org > *Objet :* Re: [Int-area] SOCKS 6 Draft > > Hi David, > > */[/*SNIP] > > - Out of curiosity, what specific use case are you using this > protocol for? > > We are looking into using MPTCP on mobile devices to "bind" 4G/LTE > and WiFi. Mobile data networks have high latency, hence the drive > to shave off as many RTTs as possible and to take advantage of > TFO, at least on the client-proxy leg. > > Cheers, > Vlad > --------------2357FF80A5B826DBCE30F16F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mohamed,

No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as inspiration for SOCKS 6.

When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT overhead. It can also be stacked as many times as desired for arbitrarily long proxy chains. However:
=A0* We avoid using the SYN's payload as extra option space (which, I think, goes against TCP's core philosophy). The magic number at the start of the MP_CONVERT element implies that if any MPTCP stream happens to start with 0xFAA8FAA8, the client should not use TFO. I think moving up the protocol stack is a more desirable alternative. =A0* We support authentication. Connections to the proxy can also be initiated from networks outside of the operator's control (e.g. home WiFis).
=A0* SOCKS 6 is easier to extend. If the client needs to request some special behavior from the proxy (e.g. what packet scheduler to use), all we have to do is define (and standardize) a new SOCKS option.

(I've also CCed the MPTCP WG).

Cheers,
Vlad

On 07/04/2017 12:09 PM, mohamed.boucadair@or= ange.com wrote:

Hi Vladimir, all, =

=A0

(focusing only on this part of the message).

=A0

I do fully agree that shortening MPTCP connections setup is key. Having 0-RTT is an important requirement for this effort. Achieving it without out-of-band signaling would be even ideal.

=A0

Can you please elaborat= e on the benefits of your proposal compared to https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-= assisted-mptcp-03.pdf which allows to achieve 0-RTT proxying.

=A0

Thank you.

=A0

Cheers,

Med <= /p>

=A0


--------------2357FF80A5B826DBCE30F16F-- From nobody Tue Jul 4 21:44:16 2017 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 0F18A1279EB; Tue, 4 Jul 2017 21:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 X9ruVwzoi47q; Tue, 4 Jul 2017 21:44:13 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57153126D45; Tue, 4 Jul 2017 21:44:13 -0700 (PDT) Received: from [192.168.1.28] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v654hfDM022585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Jul 2017 21:43:43 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-69B32FA4-5250-4E7C-96BD-BD1C32FCF8C7 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 4 Jul 2017 21:43:41 -0700 Cc: mohamed.boucadair@orange.com, David Schinazi , multipathtcp , "Int-area@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Vladimir Olteanu X-MailScanner-ID: v654hfDM022585 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 04:44:15 -0000 --Apple-Mail-69B32FA4-5250-4E7C-96BD-BD1C32FCF8C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jul 4, 2017, at 4:35 PM, Vladimir Olteanu w= rote: >=20 > * We avoid using the SYN's payload as extra option space (which, I think,= goes against TCP's core philosophy). It's not philosophy - it's a requirement for backward compatibility as requi= red for receivers not supporting new options in the SYN.=20 See https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-06 Issues are discussed in detail in sec 8 of https://tools.ietf.org/html/draft= -ietf-tcpm-tcp-edo-06 Joe= --Apple-Mail-69B32FA4-5250-4E7C-96BD-BD1C32FCF8C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

 * We avoid using the SYN's payload as extra option space (which, I think, goes against TCP's core philosophy).

It's not philosophy - it's a requirement for backward compatibility as required for receivers not supporting new options in the SYN. 


Issues are discussed in detail in sec 8 of https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-06

Joe
--Apple-Mail-69B32FA4-5250-4E7C-96BD-BD1C32FCF8C7-- From nobody Tue Jul 4 23:01:08 2017 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 98839127337; Tue, 4 Jul 2017 23:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LQZ1t5E6lwZM; Tue, 4 Jul 2017 23:00:57 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D355129AE3; Tue, 4 Jul 2017 23:00:56 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id DAD34C0624; Wed, 5 Jul 2017 08:00:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 9B0C4120087; Wed, 5 Jul 2017 08:00:54 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 08:00:54 +0200 From: To: Vladimir Olteanu , David Schinazi CC: "Int-area@ietf.org" , multipathtcp Thread-Topic: [Int-area] SOCKS 6 Draft Thread-Index: AQHS9R4yxOvkTTTpCU2LgEv+GOAL7qJEs1zg Date: Wed, 5 Jul 2017 06:00:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A000D16OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 06:01:00 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A000D16OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Valdimir, Thank you for your answer. Please see inline. Cheers, Med De : Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] Envoy=E9 : mercredi 5 juillet 2017 01:35 =C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft Hi Mohamed, No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as insp= iration for SOCKS 6. When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT ove= rhead. [Med] Glad to see that we are pursuing the same goal. That's said I'm not s= ure about the 0-RTT in the current proposal given this text that puts a dep= endency on the server side: In the fast case, when authentication is properly set up, the proxy attempts to create the socket immediately after the receipt of the request, thus achieving an operational conection in one RTT (provided TFO functionality is available at the client, proxy, and server). ^^^^^^^^ It can also be stacked as many times as desired for arbitrarily long proxy= chains. However: * We avoid using the SYN's payload as extra option space (which, I think, = goes against TCP's core philosophy). [Med] This is also true for MP_CONVERT Information Element which is not a T= CP option, but a data supplied for proxy purposes in the SYN payload. The magic number at the start of the MP_CONVERT element implies that if an= y MPTCP stream happens to start with 0xFAA8FAA8, the client should not use = TFO. [Med] This can be fixed by registering a service port for the proxy service= because, after all, the ultimate destination port is conveyed in the MP_CO= NVERT. I think moving up the protocol stack is a more desirable alternative. * We support authentication. Connections to the proxy can also be initiate= d from networks outside of the operator's control (e.g. home WiFis). [Med] Authentication/authorization can be supported by various means. This = depends on the deployment scheme. * SOCKS 6 is easier to extend. If the client needs to request some special= behavior from the proxy (e.g. what packet scheduler to use), all we have t= o do is define (and standardize) a new SOCKS option. [Med] That's also true for MP_CONVERT Information Element. You can define n= ew "Types" if needed. Can you please let me know if the proposal supports the following features: =B7 Support incoming connections (Proxy<---Remote Host): That is th= e proxy intercept a TCP connection that it transforms into an MPTCP one. =B7 If such feature is supported, how a host located behind a CPE (= Host----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so t= hat it can forward appropriately incoming connections? =B7 Use MPTCP in the leg between the proxy and server =B7 Notify the client that the server is also MPTCP-capable (so tha= t the proxy can be withdrawn from the communication) =B7 Relay untouched the set of TCP options supplied by the client/s= erver without any alteration from the proxy =B7 IPv6 source address/prefix preservation (I've also CCed the MPTCP WG). [Med] Thanks. Cheers, Vlad On 07/04/2017 12:09 PM, mohamed.boucadair@orange.com wrote: Hi Vladimir, all, (focusing only on this part of the message). I do fully agree that shortening MPTCP connections setup is key. Having 0-R= TT is an important requirement for this effort. Achieving it without out-of= -band signaling would be even ideal. Can you please elaborate on the benefits of your proposal compared to https= ://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assiste= d-mptcp-03.pdf which allows to achieve 0-RTT proxying. Thank you. Cheers, Med De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Vladimir Olt= eanu Envoy=E9 : vendredi 30 juin 2017 23:37 =C0 : David Schinazi Cc : Int-area@ietf.org Objet : Re: [Int-area] SOCKS 6 Draft Hi David, [SNIP] - Out of curiosity, what specific use case are you using this protocol for? We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi= . Mobile data networks have high latency, hence the drive to shave off as m= any RTTs as possible and to take advantage of TFO, at least on the client-p= roxy leg. Cheers, Vlad --_000_787AE7BB302AE849A7480A190F8B93300A000D16OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Valdimir,

 

Thank you for your answer.

 

Please see inline.

 

Cheers,

Med

 

De := Vladimir Olteanu [mailto:vladimir.olteanu@cs.= pub.ro]
Envoy=E9 : mercredi 5 juillet 2017 01:35
=C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

 

Hi Mohamed,

No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as insp= iration for SOCKS 6.

When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT ove= rhead.

= [Med] Glad to see that we are pursuing the same goal. That’s said I&#= 8217;m not sure about the 0-RTT in the current proposal given this text that puts a dependency on the server side:

   In the f= ast case, when authentication is properly set up, the proxy

   attempts to c= reate the socket immediately after the receipt of the

   request, thus= achieving an operational conection in one RTT (provided<= /p>

   TFO functiona= lity is available at the client, proxy, and server).

    &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    ^^^^^^^^      &n= bsp;            = ;           

=  It can also be stacked as many times as desired for arbitrarily long = proxy chains. However:
 * We avoid using the SYN's payload as extra option space (which, I th= ink, goes against TCP's core philosophy).

= [Med] This is also true for MP_CONVERT Information Element which is not a T= CP option, but a data supplied for proxy purposes in the SYN payload.  

=  The magic number at the start of the MP_CONVERT element implies that = if any MPTCP stream happens to start with 0xFAA8FAA8, the client should not= use TFO.

= [Med] This can be fixed by registering a service port for the proxy service= because, after all, the ultimate destination port is conveyed in the MP_CONVERT.

= I think moving up the protocol stack is a more desirable alternative.
 * We support authentication. Connections to the proxy can also be ini= tiated from networks outside of the operator's control (e.g. home WiFis).

= [Med] Authentication/authorization can be supported by various means. This = depends on the deployment scheme.

=
 * SOCKS 6 is easier to extend. If the client needs to request = some special behavior from the proxy (e.g. what packet scheduler to use), a= ll we have to do is define (and standardize) a new SOCKS option.

= [Med] That’s also true for MP_CONVERT Information Element. You can de= fine new “Types” if needed.

= Can you please let me know if the proposal supports the following features:=

=B7      = ;   Support incoming connec= tions (Proxy<---Remote Host): That is the proxy intercept a TCP connecti= on that it transforms into an MPTCP one.

=B7      = ;   If such feature is supp= orted, how a host located behind a CPE (Host----CPE-----Proxy----Remote Hos= t) can instruct dynamically the CPE so that it can forward appropriately incoming connections?

=B7      = ;   Use MPTCP in the leg be= tween the proxy and server

=B7      = ;   Notify the client that = the server is also MPTCP-capable (so that the proxy can be withdrawn from t= he communication)

=B7      = ;   Relay untouched the set= of TCP options supplied by the client/server without any alteration from t= he proxy

=B7      = ;   IPv6 source address/pre= fix preservation

=
(I've also CCed the MPTCP WG).

= [Med] Thanks.

=

Cheers,
Vlad

On 07/04/2017 12:09 PM, = mohamed.boucadair@orange.co= m wrote:

Hi Vladimir,= all,

 

(focusing on= ly on this part of the message).

 

I do fully a= gree that shortening MPTCP connections setup is key. Having 0-RTT is an imp= ortant requirement for this effort. Achieving it without out-of-band signaling would be even ideal.

 

Can you plea= se elaborate on the benefits of your proposal compared to https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-as= sisted-mptcp-03.pdf which allows to achieve 0-RTT proxying.

 

Thank you.

 

Cheers,

Med

 

 

Hi David,

[SNIP]


- Out of curiosity, what specif= ic use case are you using this protocol for?

 

We are looking into using MPTCP= on mobile devices to "bind" 4G/LTE and WiFi. Mobile data networks have high = latency, hence the drive to shave off as many RTTs as possible and to take = advantage of TFO, at least on the client-proxy leg.

 

Cheers,
Vlad

 

--_000_787AE7BB302AE849A7480A190F8B93300A000D16OPEXCLILMA3corp_-- From nobody Wed Jul 5 09:39:21 2017 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 6F034131D72; Wed, 5 Jul 2017 09:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5FkTXdCrTexh; Wed, 5 Jul 2017 09:39:15 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD3B13167C; Wed, 5 Jul 2017 09:39:13 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AL/KbcxRmU3SbA4g7g9bn4FHFr9psv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67ZByAt8tkgFKBZ4jH8fUM07OQ6PG/HzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdwIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAo2y?= =?us-ascii?q?cpUBD+QCM+hWoYbyqFkBogelCAa2GO/i0CVFimP40KA61ekqDAHI3BYnH9ILqH?= =?us-ascii?q?nbo9H1O70PXuC0yanIzC/DZO5P1zf59IjHbAouofeRXbltdsfR100vGBnYgVWR?= =?us-ascii?q?rIzlPimV2v4Ks2if8+pvS/igi2g6qwxqvjev3d0gipHUho0O0FzE7yJ5zZ8zKN?= =?us-ascii?q?alRkB7ZtukH4FRtyGcL4Z2Q90tQ31muCogzb0Go5G7cDAKyJQ72x7fc/uHc4uS?= =?us-ascii?q?7hLiSOacJypzinF9eL+nmhq//lWsxvf/W8S0ylpGsDRJn9vWun0DzxDe7siKRu?= =?us-ascii?q?F/80qgwzqDyh7f5+JeLUwqiabXNpgsyaMqmJUJq0TMBCr2lV3zjK+Ra0or5PCl?= =?us-ascii?q?6//iYrX6vp+cMJJ0ih3mPqQuhMO/BeM4PxAQX2ie4+u81bnj8VflT7VRlPE2ir?= =?us-ascii?q?TZv4vAKcQBoa61Gw5V0oA95BajFzqqzdsVkWQdIF9GeB+LlZblN0/MLfziA/qz?= =?us-ascii?q?m1Gsny1qx/DCML3hGJLNLn3bnbf/ebZy8VNTyAs2zdBe/ZJYELYBIPbvWkDvrt?= =?us-ascii?q?PYCAI5PheozOb8Etl9zp4eVnmVDq+DN6PeqUWI6f43I+mQeI8Vvy7wJOU+5/Hy?= =?us-ascii?q?jX85mFkdcrOo3JsWc323BOxmI12dYXXymNsODWAKvg8mRuzwlFKCSSJTZ2q1X6?= =?us-ascii?q?8k5T87Dp6mAZ7ZSYC3nrOOxjy2HpxIaWBaBFCAC3Dod5+LW/0UciKdPtdhkiAY?= =?us-ascii?q?VbimU4Ih0AyutAvmy7pmNurb4DEYtZL/1Ndp/+3ejhAy+iJoD8STyW2NSHt0nm?= =?us-ascii?q?wQTT8swK9/uVB9ykuE0aVghvxYEtxT6OlMUggkKJHQ1fd1C9fvWg3dZNiGVUyp?= =?us-ascii?q?QtS8ATwqSdIx2cUBY0ByG9q8lBzMwy2qA7pG34CMUZkz8qvZ0nS3LcFgwH/K3a?= =?us-ascii?q?g7p148S81AOCutgas7vyTaGY/F236Sl6esfLYdlHrB72yDzGyHrkBwWRZoVaiD?= =?us-ascii?q?VncaMBj4t9P8s33GRrOvDLU9eixF1cOLLLYCPsPthFlHQfb5ftPaf2+4nXqYDg?= =?us-ascii?q?3O3q6GKpDtLTZOlB7BAVQJxlhAtU2NMhIzU2L4+zrT?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ADBAABFV1Z/wPjVY1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgkSBTQOBDY58kFIimBEuhW4Cg3MBAQEBAQE?= =?us-ascii?q?BAQIBaiiCMyQBgkEBAwItTBALGBULAQYHRhEGAQwGAgEBF4oYDLAUKYsaAQEBA?= =?us-ascii?q?QEBAQMBAQEBAQEBARsFgyeDTIFhKwuCboRGDkwJhTUFkU2FXIddgiKTb4VKg06?= =?us-ascii?q?GepUxAleBCjEhhhQcgWlzAYZDgj8BAQE?= X-IPAS-Result: =?us-ascii?q?A2ADBAABFV1Z/wPjVY1dGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgkSBTQOBDY58kFIimBEuhW4Cg3MBAQEBAQEBAQIBaiiCMyQBg?= =?us-ascii?q?kEBAwItTBALGBULAQYHRhEGAQwGAgEBF4oYDLAUKYsaAQEBAQEBAQMBAQEBAQE?= =?us-ascii?q?BARsFgyeDTIFhKwuCboRGDkwJhTUFkU2FXIddgiKTb4VKg06GepUxAleBCjEhh?= =?us-ascii?q?hQcgWlzAYZDgj8BAQE?= X-IronPort-AV: E=Sophos;i="5.40,312,1496091600"; d="scan'208,217";a="874608" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 05 Jul 2017 19:39:07 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 998841A6012B; Wed, 5 Jul 2017 19:39:07 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id INasMXOC9i8j; Wed, 5 Jul 2017 19:39:07 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 7616B1A60149; Wed, 5 Jul 2017 19:39:07 +0300 (EEST) Received: from [192.168.1.70] (unknown [95.76.128.201]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id 521791A6012B; Wed, 5 Jul 2017 19:39:07 +0300 (EEST) From: Vladimir Olteanu To: mohamed.boucadair@orange.com, David Schinazi Cc: "Int-area@ietf.org" , multipathtcp References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Message-ID: Date: Wed, 5 Jul 2017 19:39:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------F3A5D12EAF8410EBA28959E6" Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:39:19 -0000 This is a multi-part message in MIME format. --------------F3A5D12EAF8410EBA28959E6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mohamed, It's great to talk this through. I've inlined my answers. Cheers, Vlad On 7/5/2017 9:00 AM, mohamed.boucadair@orange.com wrote: > > Hi Valdimir, > > Thank you for your answer. > > Please see inline. > > Cheers, > > Med > > *De :*Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] > *Envoy=E9 :* mercredi 5 juillet 2017 01:35 > *=C0 :* BOUCADAIR Mohamed IMT/OLN; David Schinazi > *Cc :* Int-area@ietf.org; multipathtcp > *Objet :* Re: [Int-area] SOCKS 6 Draft > > Hi Mohamed, > > No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as=20 > inspiration for SOCKS 6. > > When coupled with TFO on the client-proxy leg, SOCKS 6 also has a=20 > 0-RTT overhead. > > [Med] Glad to see that we are pursuing the same goal. That=92s said I=92= m=20 > not sure about the 0-RTT in the current proposal given this text that=20 > puts a dependency on the server side: > > In the fast case, when authentication is properly set up, the proxy > > attempts to create the socket immediately after the receipt of the > > request, thus achieving an operational conection in one RTT (provide= d > > TFO functionality is available at the client, proxy, and server). > > ^^^^^^^^ > Oops, we meant to say a data response in 1 RTT (e.g. HTTP GET, then HTTP=20 OK). > > It can also be stacked as many times as desired for arbitrarily long=20 > proxy chains. However: > * We avoid using the SYN's payload as extra option space (which, I=20 > think, goes against TCP's core philosophy). > > [Med] This is also true for MP_CONVERT Information Element which is=20 > not a TCP option, but a data supplied for proxy purposes in the SYN=20 > payload. > Fair enough, but this is not a purely layer 5+ protocol. It seems that=20 you are strongly tied to TFO (between the client and the proxy).=20 MP_CONVERT must be part of the SYN's payload, because the following=20 SYN+ACK depends on the contents of MP_CONVERT and signals that the=20 remote server has accepted your connection. > > The magic number at the start of the MP_CONVERT element implies that=20 > if any MPTCP stream happens to start with 0xFAA8FAA8, the client=20 > should not use TFO. > > [Med] This can be fixed by registering a service port for the proxy=20 > service because, after all, the ultimate destination port is conveyed=20 > in the MP_CONVERT. > I think this is more sensible. > > I think moving up the protocol stack is a more desirable alternative. > * We support authentication. Connections to the proxy can also be=20 > initiated from networks outside of the operator's control (e.g. home=20 > WiFis). > > [Med] Authentication/authorization can be supported by various means.=20 > This depends on the deployment scheme. > > > * SOCKS 6 is easier to extend. If the client needs to request some=20 > special behavior from the proxy (e.g. what packet scheduler to use),=20 > all we have to do is define (and standardize) a new SOCKS option. > > [Med] That=92s also true for MP_CONVERT Information Element. You can=20 > define new =93Types=94 if needed. > > Can you please let me know if the proposal supports the following=20 > features: > > =B7Support incoming connections (Proxy<---Remote Host): That is the=20 > proxy intercept a TCP connection that it transforms into an MPTCP one. > Yes. See section 7.2. The client makes a request and then has to keep=20 the connection to the proxy open. When the proxy accepts a connection=20 from a remote host, it informs the client of the remote host's address=20 and starts relaying data. SOCKS 5 has the exact same feature. You are=20 limited to one incoming connection per request, though. > > =B7If such feature is supported, how a host located behind a CPE=20 > (Host----CPE-----Proxy----Remote Host) can instruct dynamically the=20 > CPE so that it can forward appropriately incoming connections? > It does not have to. The connection on the host-proxy leg is initiated=20 by the client. > > =B7Use MPTCP in the leg between the proxy and server > Yes. > > =B7Notify the client that the server is also MPTCP-capable (so that the= =20 > proxy can be withdrawn from the communication) > It depends on the implementation. A basic implementation just listens=20 for a connection from the client and then opens a socket to the server=20 using the vanilla socket API. It can't do any fancy stuff. A smarter implementation (the one we're aiming for) can mirror the=20 keys/tokens/DSS sequence numbers (also taking the DSS delta(s) incurred=20 by the request/auth. reply/operation reply into account) and advertise=20 the server's real address(es) via ADD_ADDR. We plan to go a step further=20 in -01 and add an option in the operation reply that hints that the main=20 subflow (the one going through the proxy) should be closed once other=20 subflows are established. > > =B7Relay untouched the set of TCP options supplied by the client/server= =20 > without any alteration from the proxy > Yes-ish. In both SOCKS 6 and MPTCP Plain mode, when you strip away the=20 initial exchange between the client and the proxy, you end up with the=20 actual data that has to be relayed, so I would argue that both solutions=20 are similar and suffer from roughly the same issues. As long as there is a 1:1 mapping between client-proxy and proxy-server=20 subflows, I don't think there are many issues. In case you have TFO on=20 the client-proxy leg, but not on the server, you have to transmit the=20 SYN's payload in a subsequent packet. When you have to convert between MPTCP and regular TCP, you can no=20 longer translate everything packet-by-packet and let end-to-end=20 congestion control do the work for you (and you can't relay ECN,=20 either). Further: * In MPTCP, different subflows may send the same data using different=20 options and/or DSCP. * You can't freely mix TCP timestamps from different subflows. (The=20 only guarantee is that timestamps are numbers that increase=20 monotonically for each individual subflow.) I would go even further and say that, on principle, a proxy should not=20 relay unknown TCP options, but rather strip them. > > =B7IPv6 source address/prefix preservation > > I'm not sure what you mean by that. > > (I've also CCed the MPTCP WG). > > [Med] Thanks. > > > > Cheers, > Vlad > > On 07/04/2017 12:09 PM, mohamed.boucadair@orange.com=20 > wrote: > > Hi Vladimir, all, > > (focusing only on this part of the message). > > I do fully agree that shortening MPTCP connections setup is key. > Having 0-RTT is an important requirement for this effort. > Achieving it without out-of-band signaling would be even ideal. > > Can you please elaborate on the benefits of your proposal compared > to > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-ne= twork-assisted-mptcp-03.pdf > which allows to achieve 0-RTT proxying. > > Thank you. > > Cheers, > > Med > > *De :*Int-area [mailto:int-area-bounces@ietf.org] *De la part de* > Vladimir Olteanu > *Envoy=E9 :* vendredi 30 juin 2017 23:37 > *=C0 :* David Schinazi > *Cc :* Int-area@ietf.org > *Objet :* Re: [Int-area] SOCKS 6 Draft > > Hi David, > > */[/*SNIP] > > > - Out of curiosity, what specific use case are you using this > protocol for? > > We are looking into using MPTCP on mobile devices to "bind" > 4G/LTE and WiFi. Mobile data networks have high latency, hence > the drive to shave off as many RTTs as possible and to take > advantage of TFO, at least on the client-proxy leg. > > Cheers, > Vlad > --------------F3A5D12EAF8410EBA28959E6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Mohamed,

It's great to talk this through. I've inlined my answers.

Cheers,

Vlad


On 7/5/2017 9:00 AM, mohamed.boucadair@or= ange.com wrote:

Hi Valdimir,

=A0

Thank you for your answer. =

=A0

Please see inline.

=A0

Cheers,

Med

=A0

De=A0: Vladimir Olteanu [mailto:vla= dimir.olteanu@cs.pub.ro]
Envoy=E9=A0: mercredi 5 juillet 2017 01:35
=C0=A0: BOUCADAIR Mohamed IMT/OLN; David Schinaz= i
Cc=A0: Int-area@ietf.org; multipathtcp
Objet=A0: Re: [Int-area] SOCKS 6 Draft

=A0

Hi Mohame= d,

No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as inspiration for SOCKS 6.

When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT overhead.<= /span>

[Med] Glad to see tha= t we are pursuing the same goal. That=92s said I=92m not sure about the 0-RTT in the current proposal given this text that puts a dependency on the server side:

=A0=A0=A0In the = fast case, when authentication is properly set up, the proxy

=A0=A0 attempts = to create the socket immediately after the receipt of the=

=A0=A0 request, = thus achieving an operational conection in one RTT (provided

=A0=A0 TFO functionality is available at the client, proxy, and server).

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0^^^^^^^^=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0

Oops, we meant to say a data response in 1 RTT (e.g. HTTP GET, then HTTP OK).

=A0It can also be stacked as many times as desired for arbitrarily long proxy chains. However:
=A0* We avoid using the SYN's payload as extra option space (which, I think, goes against TCP's core philosophy).

[Med] This is also true for MP_CONVERT Information Element which is not a TCP option, but a data supplied for proxy purposes in the SYN payload.

Fair enough, but this is not a purely layer 5+ protocol. It seems that you are strongly tied to TFO (between the client and the proxy). MP_CONVERT must be part of the SYN's payload, because the following SYN+ACK depends on the contents of MP_CONVERT and signals that the remote server has accepted your connection.

=A0=

=A0The magic number at the start of the MP_CONVERT element implies that if any MPTCP stream happens to start with 0xFAA8FAA8, the client should not use TFO.<= o:p>

[Med] This can be fixed by registering a service port for the proxy service because, after all, the ultimate destination port is conveyed in the MP_CONVERT.

I think this is more sensible.

I think moving up the protocol stack is a more desirable alternative.
=A0* We support authentication. Connections to the proxy ca= n also be initiated from networks outside of the operator's control (e.g. home WiFis).

[Med] Authentication/authorization can be supported by various means. This depends on the deployment scheme.


=A0* SOCKS 6 is easier to extend. If the client needs to request some special behavior from the proxy (e.g. what packet scheduler to use), all we have to do is define (and standardize) a new SOCKS option.

[Med] That=92s also t= rue for MP_CONVERT Information Element. You can define new =93Types=94 if needed.

Can you please let me know if the proposal supports the following features:<= /o:p>

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 Support incoming connections (Proxy<---Remote Host): That is the proxy intercept a TCP connection that it transforms into an MPTCP one.

Yes. See section 7.2. The client makes a request and then has to keep the connection to the proxy open. When the proxy accepts a connection from a remote host, it informs the client of the remote host's address and starts relaying data. SOCKS 5 has the exact same feature. You are limited to one incoming connection per request, though.

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 If such feature is supported, how a host located behind a CPE (Host----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so that it can forward appropriately incoming connections?

It does not have to. The connection on the host-proxy leg is initiated by the client.

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 Use MPTCP in the leg between the proxy and server

Yes.

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 Notify the client tha= t the server is also MPTCP-capable (so that the proxy can be withdrawn from the communication)

It depends on the implementation. A basic implementation just listens for a connection from the client and then opens a socket to the server using the vanilla socket API. It can't do any fancy stuff.

A smarter implementation (the one we're aiming for) can mirror the keys/tokens/DSS sequence numbers (also taking the DSS delta(s) incurred by the request/auth. reply/operation reply into account) and advertise the server's real address(es) via ADD_ADDR. We plan to go a step further in -01 and add an option in the operation reply that hints that the main subflow (the one going through the proxy) should be closed once other subflows are established.

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 Relay untouched the set of TCP options supplied by the client/server without any alteration from the proxy

Yes-ish. In both SOCKS 6 and MPTCP Plain mode, when you strip away the initial exchange between the client and the proxy, you end up with the actual data that has to be relayed, so I would argue that both solutions are similar and suffer from roughly the same issues.
As long as there is a 1:1 mapping between client-proxy and proxy-server subflows, I don't think there are many issues. In case you have TFO on the client-proxy leg, but not on the server, you have to transmit the SYN's payload in a subsequent packet.

When you have to convert between MPTCP and regular TCP, you can no longer translate everything packet-by-packet and let end-to-end congestion control do the work for you (and you can't relay ECN, either). Further:
=A0* In MPTCP, different subflows may send the same data using different options and/or DSCP.
=A0* You can't freely mix TCP timestamps from different subflows. (Th= e only guarantee is that timestamps are numbers that increase monotonically for each individual subflow.)

I would go even further and say that, on principle, a proxy should not relay unknown TCP options, but rather strip them.

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 IPv6 source address/prefix preservation


I'm not sure what you mean by that.

(I've also CCed the MPTCP WG).

[Med] Thanks.



Cheers,
Vlad

Hi Vladimir, all,

=A0<= /span>

(foc= using only on this part of the message).

=A0<= /span>

I do fully agree that shortening MPTCP connections setup is key. Having 0-RTT is an important requirement for this effort. Achieving it without out-of-band signaling would be even ideal.

=A0<= /span>

Can you please elaborate on the benefits of your proposal compared to https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-= assisted-mptcp-03.pdf which allows to achieve 0-RTT proxying.

=A0<= /span>

Than= k you.

=A0<= /span>

Chee= rs,

Med =

=A0<= /span>

De=A0: Int-area [mailto:int-area-bounces@= ietf.org] De la part de Vladimir Olteanu
Envoy=E9=A0: vendredi 30 juin 2017 23:37
=C0=A0: David Schinazi
Cc=A0: Int-area@ietf.org Objet=A0: Re: [Int-area] SOCKS 6 Draft

=A0

Hi David,

[= SNIP]


- Out= of curiosity, what specific use case are you using this protocol for?

=A0

We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi. Mobile data networks have high latency, hence the drive to shave off as many RTTs as possible and to take advantage of TFO, at least on the client-proxy leg.

=A0

Cheers,
Vlad

=A0


--------------F3A5D12EAF8410EBA28959E6-- From nobody Wed Jul 5 10:00:02 2017 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 8905C131D72; Wed, 5 Jul 2017 09:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 tp9ADZ7SJa8w; Wed, 5 Jul 2017 09:59:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3561131CC1; Wed, 5 Jul 2017 09:59:53 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v65Gx5wA014405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Jul 2017 09:59:06 -0700 (PDT) To: Vladimir Olteanu , mohamed.boucadair@orange.com, David Schinazi Cc: multipathtcp , "Int-area@ietf.org" References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 5 Jul 2017 09:59:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BAEF158E60785C245021D546" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:59:56 -0000 This is a multi-part message in MIME format. --------------BAEF158E60785C245021D546 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 7/5/2017 9:39 AM, Vladimir Olteanu wrote: >> >> It can also be stacked as many times as desired for arbitrarily long >> proxy chains. However: >> * We avoid using the SYN's payload as extra option space (which, I >> think, goes against TCP's core philosophy). >> >> [Med] This is also true for MP_CONVERT Information Element which is >> not a TCP option, but a data supplied for proxy purposes in the SYN >> payload. >> > Fair enough, but this is not a purely layer 5+ protocol. It seems that > you are strongly tied to TFO (between the client and the proxy). > MP_CONVERT must be part of the SYN's payload, because the following > SYN+ACK depends on the contents of MP_CONVERT and signals that the > remote server has accepted your connection. The biggest impact of including non-data information in the SYN payload area is that it completely defeats graceful fallback for SYN receivers that don't support the option. As you note, it can be *more* safe when tied to out-of-band context (e.g., prior TFO support), but TCP has NO requirement that such context is absolutely maintained across different connections. You might be speaking to a different stack or demuxed off to a different virtual host behind a load balancer. Ultimately, putting any non-data info in the SYN payload violates the requirement that TCP options can be ignored by receivers that don't support them *without* impacting the ability of *that* connection attempt to succeed. Joe --------------BAEF158E60785C245021D546 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 7/5/2017 9:39 AM, Vladimir Olteanu wrote:

It can also be stacked as many times as desired for arbitrarily long proxy chains. However:
* We avoid using the SYN's payload as extra option space (which, I think, goes against TCP's core philosophy).

[Med] This is also true for MP_CONVERT Information Element which is not a TCP option, but a data supplied for proxy purposes in the SYN payload.

Fair enough, but this is not a purely layer 5+ protocol. It seems that you are strongly tied to TFO (between the client and the proxy). MP_CONVERT must be part of the SYN's payload, because the following SYN+ACK depends on the contents of MP_CONVERT and signals that the remote server has accepted your connection.

The biggest impact of including non-data information in the SYN payload area is that it completely defeats graceful fallback for SYN receivers that don't support the option. As you note, it can be *more* safe when tied to out-of-band context (e.g., prior TFO support), but TCP has NO requirement that such context is absolutely maintained across different connections. You might be speaking to a different stack or demuxed off to a different virtual host behind a load balancer.

Ultimately, putting any non-data info in the SYN payload violates the requirement that TCP options can be ignored by receivers that don't support them *without* impacting the ability of *that* connection attempt to succeed.

Joe
--------------BAEF158E60785C245021D546-- From nobody Thu Jul 6 01:41:27 2017 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 C3BE5129A9C; Thu, 6 Jul 2017 01:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hFTP8_Szhnc8; Thu, 6 Jul 2017 01:41:18 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id CEE761270A3; Thu, 6 Jul 2017 01:41:17 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3ATrT2aRTpXkKw6GY0YXVjnARNbdpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67ZBCPt8tkgFKBZ4jH8fUM07OQ6PG/HzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdwIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZDI2y?= =?us-ascii?q?b5UBAekDMuZWsofyqEcBoxS5CwmwH+7v1iZIiWPq0aAgz+gsEwfL1xEgEdIUt3?= =?us-ascii?q?TUqc34OqkIUe+vw6nIyjXBZO5O1zf89IfIbxQhru+XXb1sbMra1E4iGB7fjlqK?= =?us-ascii?q?pozlOCiV2v4Ls2ia8+VgSOavhHA8qw5tvzii3dsjipLTioIN11DL7j91wJwyJd?= =?us-ascii?q?ChTkNwfNCqEJxVty6ANot2RNsvQ25puCYmyr0GpIW0cDIWx5Qgwh7SbeGMfYuQ?= =?us-ascii?q?4h/7SeqcLip0iGhmdb+/nRq+71asx+/mWsS61ltBszBLncPWtn8X0hze8s2HSv?= =?us-ascii?q?xg8Ui/wTuPzAXT6v1cIUAziKrbN4Ytwr4umZoXtkTOBjH2mEDsg6+XckUo4PSn?= =?us-ascii?q?6//9brX+u5+TLJV4ihv5Mqg2m8y/B/o3MhQWUmSG9umwyafv8E75TblQkPE6jK?= =?us-ascii?q?vUvIrUKMgDo662GQ5V0oIt6xalCDem1cwVkmQdLF1fdxKHiJPpN0vIIPD5Efi/?= =?us-ascii?q?nlCsnylwx//aI73sGYnCLmPZnLf5YLZy8FRQyBA0zdxH/ZJbFqkBIO7vWk/2rN?= =?us-ascii?q?HXEwQ5PBC0w+bmDtVyzIIfWWOUD6CDKKPSqVuI6fw1L+aQY48VvS73K+I56P72?= =?us-ascii?q?kX85hVgdcLGq05sRdHC0B+5pI1+HbnX2mdoBEHkFvhYwTODwj12CSzFTbW6oX6?= =?us-ascii?q?0g/jE7FJ6mDYDbS4ConbyB2Du7HpxOZm9cFlCMEWvoeJmcW/oXaSKdPNNhkjIe?= =?us-ascii?q?WbimUY8h2gmktBXmxLp/MurU5ioYuIr/1Nhy+u3ciREy+Cd1D8SG0mGBVX97kX?= =?us-ascii?q?4VRzUuxqBwvVR9ykuf0ah/m/FYENtT5/NTXQc/K5HT0vZ2BMv1WgLcYtiGUkup?= =?us-ascii?q?Tc+nATErVd8xxMUObFx7G9WtkB/PxTalA7gQl+/DOJth0KXRl0T2Os19gyLa07?= =?us-ascii?q?Qqj3EnWcoJOGG70P1R7Q/WUqLTmkqede6MdK8B2CPW/3rLmWaUtU5fS0h2UK7Y?= =?us-ascii?q?WX0EbVb+ps+//l7ICaWpX+d0ejBdwNKPf/MZIubiik9LEbK6YIzT?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BIAgAP911ZjAPjVY1dDg4BAQQBAQoBA?= =?us-ascii?q?RcBAQQBAQoBAYQRgRCOfJBUIpgULoVuAoN4AQEBAQEBAQECARIBAQEmV4IzJAG?= =?us-ascii?q?CQAEBAQECASNCFAULAgEIGAICDRkCAlcCBBOKJwwMsHeCJotFAQEBBwEBAQEfB?= =?us-ascii?q?YELghyFY4JuhFQWgxOCYQWRTgGNQIdHnl2VNgJWgQtShiSBNEJzBYhtAQEB?= X-IPAS-Result: =?us-ascii?q?A2BIAgAP911ZjAPjVY1dDg4BAQQBAQoBARcBAQQBAQoBAYQ?= =?us-ascii?q?RgRCOfJBUIpgULoVuAoN4AQEBAQEBAQECARIBAQEmV4IzJAGCQAEBAQECASNCF?= =?us-ascii?q?AULAgEIGAICDRkCAlcCBBOKJwwMsHeCJotFAQEBBwEBAQEfBYELghyFY4JuhFQ?= =?us-ascii?q?WgxOCYQWRTgGNQIdHnl2VNgJWgQtShiSBNEJzBYhtAQEB?= X-IronPort-AV: E=Sophos;i="5.40,316,1496091600"; d="scan'208";a="875802" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 06 Jul 2017 11:41:16 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id EF2A71A60060; Thu, 6 Jul 2017 11:41:15 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Uzkrj54EBwVe; Thu, 6 Jul 2017 11:41:15 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id CE1BA1A60101; Thu, 6 Jul 2017 11:41:15 +0300 (EEST) Received: from vmail.cs.pub.ro (vmail.cs.pub.ro [141.85.227.3]) by vmail.cs.pub.ro (Postfix) with ESMTP id C891C1A60060; Thu, 6 Jul 2017 11:41:15 +0300 (EEST) Date: Thu, 6 Jul 2017 11:41:15 +0300 (EEST) From: =?utf-8?Q?Drago=C8=99?= Niculescu To: Joe Touch Cc: Vladimir Olteanu , mohamed boucadair , David Schinazi , multipathtcp , int-area Message-ID: <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> In-Reply-To: References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC55 (Linux)/8.6.0_GA_1194) Thread-Topic: SOCKS 6 Draft Thread-Index: eMpyD6EcluPlwF6M4Jex+y3159prqA== Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:41:22 -0000 ----- On Jul 5, 2017, at 7:59 PM, Joe Touch touch@isi.edu wrote: > On 7/5/2017 9:39 AM, Vladimir Olteanu wrote: >=20 >=20 > It can also be stacked as many times as desired for arbitrarily long prox= y > chains. However: > * We avoid using the SYN's payload as extra option space (which, I think,= goes > against TCP's core philosophy). >=20 > [Med] This is also true for MP_CONVERT Information Element which is not a= TCP > option, but a data supplied for proxy purposes in the SYN payload. > Fair enough, but this is not a purely layer 5+ protocol. It seems that yo= u are > strongly tied to TFO (between the client and the proxy). MP_CONVERT must = be > part of the SYN's payload, because the following SYN+ACK depends on the > contents of MP_CONVERT and signals that the remote server has accepted yo= ur > connection. > The biggest impact of including non-data information in the SYN payload a= rea is > that it completely defeats graceful fallback for SYN receivers that don't > support the option. As you note, it can be *more* safe when tied to out-o= f-band > context (e.g., prior TFO support), but TCP has NO requirement that such c= ontext > is absolutely maintained across different connections. You might be speak= ing to > a different stack or demuxed off to a different virtual host behind a loa= d > balancer. >=20 > Ultimately, putting any non-data info in the SYN payload violates the > requirement that TCP options can be ignored by receivers that don't suppo= rt > them *without* impacting the ability of *that* connection attempt to succ= eed. >=20 > Joe SOCKSv6 proposal makes use of extra data in the SYN (SOCKS data, and user d= ata), but=20 its correctness and backward compatibility does not depend on TFO, only its= RTT performance.=20 In fact, when TFO is not available neither between client and proxy, nor be= tween proxy and=20 server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But TFO is = likely to be the most=20 common case in the future - Linux kernel has TFO client side on by default = since 3.12=20 (November 2013)[1], and it seems to be the default in all Android phones an= d default=20 Linux installs. =20 --=20 Drago=C8=99 [1] https://github.com/torvalds/linux/commit/0d41cca490c274352211efac50e959= 8d39a9dc80 =20 From nobody Thu Jul 6 02:17:54 2017 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 E805E1201F8 for ; Thu, 6 Jul 2017 02:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 plIGGPxWsxnQ for ; Thu, 6 Jul 2017 02:17:50 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3D312EA7C for ; Thu, 6 Jul 2017 02:17:47 -0700 (PDT) Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Jul 2017 10:17:45 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 6 Jul 2017 10:17:45 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Jul 2017 10:17:44 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Thu, 6 Jul 2017 10:17:44 +0100 From: To: , Thread-Topic: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-08.txt Thread-Index: AQHS9CkaKyNtSpfVLkObLaHVJnGRX6JCWb+AgAQvFGA= Date: Thu, 6 Jul 2017 09:17:44 +0000 Message-ID: <7e19321484ac4712bcf0460d3ea6f416@rew09926dag03b.domain1.systemhost.net> References: <149910604728.22726.12262054079948108111@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-08.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 09:17:53 -0000 QWxhbiwNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCkknbGwgYWRkIHlvdSB0byB0aGUgV0cgYWdl bmRhIGZvciB0aGUgdXN1YWwgYnJpZWYgdXBkYXRlIGFuZCBvcHBvcnR1bml0eSBmb3IgcGVvcGxl IHRvIGFzayBxdWVzdGlvbnMgYW5kIHN1Z2dlc3QgYW55dGhpbmcgdGhhdCBzaG91bGQgYmUgaW5j bHVkZWQgaW4gYW5vdGhlciByZXYuDQpwaGlsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQWxhbiBGb3JkDQpTZW50OiAwMyBKdWx5IDIwMTcgMTk6MjMNClRv OiBtdWx0aXBhdGh0Y3AgPG11bHRpcGF0aHRjcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbXVs dGlwYXRodGNwXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1wdGNwLXJmYzY4MjRiaXMtMDgudHh0 DQoNCkhpIGFsbCwNCg0KVGhpcyByZXYgb2YgNjgyNGJpcyBjb250YWlucyB0aGUgY2xhcmlmaWNh dGlvbnMgYnJvdWdodCBmb3J3YXJkIGJ5IENocmlzdG9waOKAmXMgYW5kIE9saXZpZXLigJlzIGlt cGxlbWVudGF0aW9uIGV4cGVyaWVuY2VzIC0gbm90YWJseSBjbGFyaWZ5aW5nIHRoZSBpbnRlcmNo YW5nZWFiaWx0aXkgb2YgTVBfQ0FQQUJMRSBhbmQgRFNTIGZvciBpbml0aWFsIERhdGEgU2VxdWVu Y2UgTWFwcGluZ3MsIGFuZCB0aGUgc2VuZGluZyBvZiBUQ1AgUlNUcyBpbiBGQVNUQ0xPU0Ugc2l0 dWF0aW9uLiBUaGlzIHJldmlzaW9uIGFsc28gbm93IHJlZmVycyB0byBTSEEtMjU2IGFzIHRoZSBo YXNoIGFsZ29yaXRobS4NCg0KUmVnYXJkcywNCkFsYW4NCg0KPiBPbiAzIEp1bCAyMDE3LCBhdCAx OToyMCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiANCj4gDQo+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlw YXRoIFRDUCBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBUQ1Ag RXh0ZW5zaW9ucyBmb3IgTXVsdGlwYXRoIE9wZXJhdGlvbiB3aXRoIE11bHRpcGxlIEFkZHJlc3Nl cw0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQWxhbiBGb3JkDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICBDb3N0aW4gUmFpY2l1DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJr IEhhbmRsZXkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIE9saXZpZXIgQm9uYXZlbnR1cmUN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgIENocmlzdG9waCBQYWFzY2gNCj4gCUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtbXB0Y3AtcmZjNjgyNGJpcy0wOC50eHQNCj4gCVBhZ2VzICAg ICAgICAgICA6IDczDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA3LTAzDQo+IA0KPiBBYnN0 cmFjdDoNCj4gICBUQ1AvSVAgY29tbXVuaWNhdGlvbiBpcyBjdXJyZW50bHkgcmVzdHJpY3RlZCB0 byBhIHNpbmdsZSBwYXRoIHBlcg0KPiAgIGNvbm5lY3Rpb24sIHlldCBtdWx0aXBsZSBwYXRocyBv ZnRlbiBleGlzdCBiZXR3ZWVuIHBlZXJzLiAgVGhlDQo+ICAgc2ltdWx0YW5lb3VzIHVzZSBvZiB0 aGVzZSBtdWx0aXBsZSBwYXRocyBmb3IgYSBUQ1AvSVAgc2Vzc2lvbiB3b3VsZA0KPiAgIGltcHJv dmUgcmVzb3VyY2UgdXNhZ2Ugd2l0aGluIHRoZSBuZXR3b3JrIGFuZCwgdGh1cywgaW1wcm92ZSB1 c2VyDQo+ICAgZXhwZXJpZW5jZSB0aHJvdWdoIGhpZ2hlciB0aHJvdWdocHV0IGFuZCBpbXByb3Zl ZCByZXNpbGllbmNlIHRvDQo+ICAgbmV0d29yayBmYWlsdXJlLg0KPiANCj4gICBNdWx0aXBhdGgg VENQIHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIHNpbXVsdGFuZW91c2x5IHVzZSBtdWx0aXBsZQ0K PiAgIHBhdGhzIGJldHdlZW4gcGVlcnMuICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgc2V0IG9m IGV4dGVuc2lvbnMgdG8NCj4gICB0cmFkaXRpb25hbCBUQ1AgdG8gc3VwcG9ydCBtdWx0aXBhdGgg b3BlcmF0aW9uLiAgVGhlIHByb3RvY29sIG9mZmVycw0KPiAgIHRoZSBzYW1lIHR5cGUgb2Ygc2Vy dmljZSB0byBhcHBsaWNhdGlvbnMgYXMgVENQIChpLmUuLCByZWxpYWJsZQ0KPiAgIGJ5dGVzdHJl YW0pLCBhbmQgaXQgcHJvdmlkZXMgdGhlIGNvbXBvbmVudHMgbmVjZXNzYXJ5IHRvIGVzdGFibGlz aA0KPiAgIGFuZCB1c2UgbXVsdGlwbGUgVENQIGZsb3dzIGFjcm9zcyBwb3RlbnRpYWxseSBkaXNq b2ludCBwYXRocy4NCj4gDQo+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdjEgb2YgTXVsdGlw YXRoIFRDUCwgb2Jzb2xldGluZyB2MCBhcw0KPiAgIHNwZWNpZmllZCBpbiBSRkM2ODI0IFtSRkM2 ODI0XSB0aHJvdWdoIGNsYXJpZmljYXRpb25zIGFuZA0KPiAgIG1vZGlmaWNhdGlvbnMgcHJpbWFy aWx5IGRyaXZlbiBieSBkZXBsb3ltZW50IGV4cGVyaWVuY2UuDQo+IA0KPiANCj4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXB0Y3AtcmZjNjgyNGJpcy8NCj4gDQo+ IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXB0Y3AtcmZjNjgyNGJpcy0wOA0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbXB0Y3AtcmZj NjgyNGJpcy0wOA0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1tcHRjcC1yZmM2ODI0YmlzLTA4DQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG11bHRpcGF0aHRjcCBtYWlsaW5nIGxpc3QNCj4gbXVsdGlwYXRodGNwQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGlwYXRodGNwDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptdWx0aXBhdGh0Y3Ag bWFpbGluZyBsaXN0DQptdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXVsdGlwYXRodGNwDQo= From nobody Thu Jul 6 04:56:12 2017 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 1901C12EB01 for ; Thu, 6 Jul 2017 04:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ThEeqKEtCSBY for ; Thu, 6 Jul 2017 04:56:08 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F381B13155F for ; Thu, 6 Jul 2017 04:56:07 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Jul 2017 12:56:03 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Jul 2017 12:56:04 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Jul 2017 12:56:04 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Thu, 6 Jul 2017 12:56:04 +0100 From: To: Thread-Topic: Draft agenda for Prague Thread-Index: AdL2P9CsLYnyeHkHQzapNEbqyFbGaw== Date: Thu, 6 Jul 2017 11:56:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: multipart/alternative; boundary="_000_d88678f98d5c4003b9d0919c58482528rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Draft agenda for Prague X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 11:56:11 -0000 --_000_d88678f98d5c4003b9d0919c58482528rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We just uploaded a draft agenda. Please let us know if anyone else would like a time slot (or if we missed y= our request), we have plenty of time at the moment. Thanks Phil & Yoshi https://tools.ietf.org/wg/mptcp/agenda?item=3Dagenda-99-mptcp-00.html --_000_d88678f98d5c4003b9d0919c58482528rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We just uploaded a draft agenda.

Please let us know if anyone else would like a time slot (or if we= missed your request), we have plenty of time at the moment.

Thanks

Phil & Yoshi

http= s://tools.ietf.org/wg/mptcp/agenda?item=3Dagenda-99-mptcp-00.html

 

--_000_d88678f98d5c4003b9d0919c58482528rew09926dag03bdomain1sy_-- From nobody Thu Jul 6 04:59:18 2017 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 F2496131561 for ; Thu, 6 Jul 2017 04:59:16 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 mpU3GgVrUrTc for ; Thu, 6 Jul 2017 04:59:14 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9842812EB2B for ; Thu, 6 Jul 2017 04:59:14 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 96DA767D9DD; Thu, 6 Jul 2017 13:59:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 96DA767D9DD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1499342345; bh=ZggGwMtb8Gy4nQmB80sT/mZm5QYBg/h0VlOIB2rLjbo=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=GjhdnuvdcDNIyurYZRWIbAu//Tl5PJkcoABuZbI4LKZ21eIgYuCh+DaLjOUXziQPz Sk1np7DtAV3pCm/i9eZLurp9Xpu4T+xvTedfwE5cToj4yZhhFQILyIDJtQuMUpiTe5 dQP0XkxgooBR9p+8xIsNjtnXulWAsd82oSkp9jEc= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Reply-To: Olivier.Bonaventure@uclouvain.be To: philip.eardley@bt.com, multipathtcp@ietf.org References: From: Olivier Bonaventure Message-ID: <3e2c4959-d256-fee2-e2e7-a091f460885c@uclouvain.be> Date: Thu, 6 Jul 2017 13:59:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 96DA767D9DD.A59F1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Draft agenda for Prague X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 11:59:17 -0000 Phil, > We just uploaded a draft agenda. > > Please let us know if anyone else would like a time slot (or if we > missed your request), we have plenty of time at the moment. Forgot to mention and add to the wiki but several of us will participate to the hackathon on MPTCP. We are also experimenting with the iOS11 implementation and will at least have demo applications and perhaps other results to share Olivier From nobody Thu Jul 6 05:56:19 2017 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 8EE60131720; Thu, 6 Jul 2017 05:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 zpxow_XeBlFD; Thu, 6 Jul 2017 05:56:08 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8377B13162D; Thu, 6 Jul 2017 05:56:07 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 1F24EC017A; Thu, 6 Jul 2017 14:56:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id DB11F1A007D; Thu, 6 Jul 2017 14:56:05 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 14:56:05 +0200 From: To: Vladimir Olteanu , David Schinazi CC: "Int-area@ietf.org" , multipathtcp Thread-Topic: [Int-area] SOCKS 6 Draft Thread-Index: AQHS9a08Y4IlRnpvi0+MgNkwp3/CEKJGvjoQ Date: Thu, 6 Jul 2017 12:56:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A001A07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A001A07OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 12:56:19 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A001A07OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vladimir, Please see inline. Cheers, Med De : Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] Envoy=E9 : mercredi 5 juillet 2017 18:39 =C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft Hi Mohamed, It's great to talk this through. I've inlined my answers. Cheers, Vlad On 7/5/2017 9:00 AM, mohamed.boucadair@orange.com wrote: Hi Valdimir, Thank you for your answer. Please see inline. Cheers, Med De : Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] Envoy=E9 : mercredi 5 juillet 2017 01:35 =C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft Hi Mohamed, No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as insp= iration for SOCKS 6. When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT ove= rhead. [Med] Glad to see that we are pursuing the same goal. That's said I'm not s= ure about the 0-RTT in the current proposal given this text that puts a dep= endency on the server side: In the fast case, when authentication is properly set up, the proxy attempts to create the socket immediately after the receipt of the request, thus achieving an operational conection in one RTT (provided TFO functionality is available at the client, proxy, and server). ^^^^^^^^ Oops, we meant to say a data response in 1 RTT (e.g. HTTP GET, then HTTP OK= ). It can also be stacked as many times as desired for arbitrarily long proxy= chains. However: * We avoid using the SYN's payload as extra option space (which, I think, = goes against TCP's core philosophy). [Med] This is also true for MP_CONVERT Information Element which is not a T= CP option, but a data supplied for proxy purposes in the SYN payload. Fair enough, but this is not a purely layer 5+ protocol. It seems that you = are strongly tied to TFO (between the client and the proxy). [Med] TFO is not required. We are in the explicit mode where the proxy is p= rovisioned by the provider to the client/CPE. That proxy is prepared to rec= eive data in the first SYN of an MPTCP connection. In order to detect misbe= having proxies, the content of CONVERT is echoed in SYN-ACK. Absent that in= formation, the client/CPE will avoid using that proxy for subsequent networ= k-assisted MPTCP exchanged till a timer is expired or a new proxy is config= ured. MP_CONVERT must be part of the SYN's payload, because the following SYN+ACK= depends on the contents of MP_CONVERT and signals that the remote server h= as accepted your connection. [Med] Yes. The magic number at the start of the MP_CONVERT element implies that if an= y MPTCP stream happens to start with 0xFAA8FAA8, the client should not use = TFO. [Med] This can be fixed by registering a service port for the proxy service= because, after all, the ultimate destination port is conveyed in the MP_CO= NVERT. I think this is more sensible. [Med] Agree. BTW, this is one of the advices made by Joe. This is now part = of the CONVERT design. I think moving up the protocol stack is a more desirable alternative. * We support authentication. Connections to the proxy can also be initiate= d from networks outside of the operator's control (e.g. home WiFis). [Med] Authentication/authorization can be supported by various means. This = depends on the deployment scheme. * SOCKS 6 is easier to extend. If the client needs to request some special= behavior from the proxy (e.g. what packet scheduler to use), all we have t= o do is define (and standardize) a new SOCKS option. [Med] That's also true for MP_CONVERT Information Element. You can define n= ew "Types" if needed. Can you please let me know if the proposal supports the following features: =B7 Support incoming connections (Proxy<---Remote Host): That is th= e proxy intercept a TCP connection that it transforms into an MPTCP one. Yes. See section 7.2. The client makes a request and then has to keep the c= onnection to the proxy open. When the proxy accepts a connection from a rem= ote host, it informs the client of the remote host's address and starts rel= aying data. SOCKS 5 has the exact same feature. You are limited to one inco= ming connection per request, though. [Med] In the plain mode, there is no such limitation because we are leverag= ing on PCP (RFC6887). =B7 If such feature is supported, how a host located behind a CPE (= Host----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so t= hat it can forward appropriately incoming connections? It does not have to. The connection on the host-proxy leg is initiated by t= he client. [Med] I'm not sure to understand your answer here. Let's consider that your= host is using UPnP IGD to talk with the CPE to accept incoming connections= + those connections are eligible to the MPTCP service. How the solution wo= uld work? =B7 Use MPTCP in the leg between the proxy and server Yes. [Med] Good. =B7 Notify the client that the server is also MPTCP-capable (so tha= t the proxy can be withdrawn from the communication) It depends on the implementation. A basic implementation just listens for a= connection from the client and then opens a socket to the server using the= vanilla socket API. It can't do any fancy stuff. A smarter implementation (the one we're aiming for) can mirror the keys/tok= ens/DSS sequence numbers (also taking the DSS delta(s) incurred by the requ= est/auth. reply/operation reply into account) and advertise the server's re= al address(es) via ADD_ADDR. We plan to go a step further in -01 and add an= option in the operation reply that hints that the main subflow (the one go= ing through the proxy) should be closed once other subflows are established= . [Med] Agree. That's aligned with the plain mode. =B7 Relay untouched the set of TCP options supplied by the client/s= erver without any alteration from the proxy Yes-ish. In both SOCKS 6 and MPTCP Plain mode, when you strip away the init= ial exchange between the client and the proxy, you end up with the actual d= ata that has to be relayed, so I would argue that both solutions are simila= r and suffer from roughly the same issues. [Med] Agree. As long as there is a 1:1 mapping between client-proxy and proxy-server sub= flows, I don't think there are many issues. In case you have TFO on the cli= ent-proxy leg, but not on the server, you have to transmit the SYN's payloa= d in a subsequent packet. When you have to convert between MPTCP and regular TCP, you can no longer t= ranslate everything packet-by-packet and let end-to-end congestion control = do the work for you (and you can't relay ECN, either). Further: * In MPTCP, different subflows may send the same data using different opti= ons and/or DSCP. * You can't freely mix TCP timestamps from different subflows. (The only g= uarantee is that timestamps are numbers that increase monotonically for eac= h individual subflow.) I would go even further and say that, on principle, a proxy should not rela= y unknown TCP options, but rather strip them. [Med] I'm not sure I would go that way. =B7 IPv6 source address/prefix preservation I'm not sure what you mean by that. [Med] Please see slide 18 of https://www.ietf.org/proceedings/98/slides/sli= des-98-mptcp-sessa-network-assisted-mptcp-03.pdf --_000_787AE7BB302AE849A7480A190F8B93300A001A07OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Vladimir,

 

Please see inline.

 

Cheers,

Med

 

De := Vladimir Olteanu [mailto:vladimir.olteanu@cs.= pub.ro]
Envoy=E9 : mercredi 5 juillet 2017 18:39
=C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

 

Hi Mohamed,

It's great to talk this through. I've inlined my answers.

Cheers,

Vlad

 

On 7/5/2017 9:00 AM, mohamed.boucadair@orange.com wrote:

Hi Valdimir,

 

Thank you for your answer.

 

Please see inline.

 

Cheers,

Med

 

De := Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro]
Envoy=E9 : mercredi 5 juillet 2017 01:35
=C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org= ; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

 

Hi Mohamed,

No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as insp= iration for SOCKS 6.

When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT ove= rhead.

[Med] Glad to see that we are pursuing the same goal. That’s said = I’m not sure about the 0-RTT in the current proposal given this text that puts a dependency on the server side:

 &= nbsp; In the fast case, when authentication is properly set up, the pr= oxy

 &= nbsp; attempts to create the socket immediately after the receipt of the

 &= nbsp; request, thus achieving an operational conection in one RTT (provided=

 &= nbsp; TFO functionality is available at the client, proxy, and server).

 &= nbsp;           &nbs= p;             =             &nb= sp;            =         ^^^^^^^^   &= nbsp;           &nbs= p;            &= nbsp; 

Oops, we meant to say a data response in 1 RTT (e.g.= HTTP GET, then HTTP OK).

=  It can also be stacked as many times as desired for arbitrarily long = proxy chains. However:
 * We avoid using the SYN's payload as extra option space (which, I th= ink, goes against TCP's core philosophy).

[Med] This is also true for MP_CONVERT Information Element which is not = a TCP option, but a data supplied for proxy purposes in the SYN payload.

Fair enough, but this is not a purely layer 5+ p= rotocol. It seems that you are strongly tied to TFO (between the client and= the proxy).

[Med] TFO is = not required. We are in the explicit mode where the proxy is provisioned by= the provider to the client/CPE. That proxy is prepared to receive data in the first SYN of an MPTCP connection. In order to detect m= isbehaving proxies, the content of CONVERT is echoed in SYN-ACK. Absent tha= t information, the client/CPE will avoid using that proxy for subsequent ne= twork-assisted MPTCP exchanged till a timer is expired or a new proxy is configured.

 

MP_CONVERT must be part of the = SYN's payload, because the following SYN+ACK depends on the contents of= MP_CONVERT and signals that the remote server has accepted your connection= .

[Med] Yes.

 

=  The magic number at the start of the MP_CONVERT element implies that = if any MPTCP stream happens to start with 0xFAA8FAA8, the client should not= use TFO.

[Med] This can be fixed by registering a service port for the proxy serv= ice because, after all, the ultimate destination port is conveyed in the MP_CONVERT.

I think this is more sensible.

[Med] Agree. = BTW, this is one of the advices made by Joe. This is now part of the CONVER= T design.



= I think moving up the protocol stack is a more desirable alternative.
 * We support authentication. Connections to the proxy can also be ini= tiated from networks outside of the operator's control (e.g. home WiFis).

[Med] Authentication/authorization can be supported by various means. Th= is depends on the deployment scheme.

=
 * SOCKS 6 is easier to extend. If the client needs to request = some special behavior from the proxy (e.g. what packet scheduler to use), a= ll we have to do is define (and standardize) a new SOCKS option.=

[Med] That’s also true for MP_CONVERT Information Element. You can= define new “Types” if needed.

Can you please let me know if the proposal supports the following featur= es:

=B7&nbs= p;        Support incoming con= nections (Proxy<---Remote Host): That is the proxy intercept a TCP conne= ction that it transforms into an MPTCP one.

Yes. See section 7.2. The client makes a request and= then has to keep the connection to the proxy open. When the proxy accepts = a connection from a remote host, it informs the client of the remote host's= address and starts relaying data. SOCKS 5 has the exact same feature. You are limited to one incoming connec= tion per request, though.

[Med] In the = plain mode, there is no such limitation because we are leveraging on PCP (R= FC6887).



=B7&nbs= p;        If such feature is s= upported, how a host located behind a CPE (Host----CPE-----Proxy----Remote = Host) can instruct dynamically the CPE so that it can forward appropriately incoming connections?

It does not have to. The connection on the host-prox= y leg is initiated by the client.

[Med] I’= ;m not sure to understand your answer here. Let’s consider that your = host is using UPnP IGD to talk with the CPE to accept incoming connections + those connections are eligible to the MPTCP service. How the solutio= n would work?

=B7&nbs= p;        Use MPTCP in the leg= between the proxy and server

Yes.

[Med] Good.



=B7&nbs= p;        Notify the client th= at the server is also MPTCP-capable (so that the proxy can be withdrawn fro= m the communication)

It depends on the implementation. A basic implementa= tion just listens for a connection from the client and then opens a socket = to the server using the vanilla socket API. It can't do any fancy stuff.
A smarter implementation (the one we're aiming for) can mirror the keys/tok= ens/DSS sequence numbers (also taking the DSS delta(s) incurred by the requ= est/auth. reply/operation reply into account) and advertise the server's re= al address(es) via ADD_ADDR. We plan to go a step further in -01 and add an option in the operation reply = that hints that the main subflow (the one going through the proxy) should b= e closed once other subflows are established.

[Med] Agree. = That’s aligned with the plain mode.

=B7&nbs= p;        Relay untouched the = set of TCP options supplied by the client/server without any alteration fro= m the proxy

Yes-ish. In both SOCKS 6 and MPTCP Plain mode, when = you strip away the initial exchange between the client and the proxy, you e= nd up with the actual data that has to be relayed, so I would argue that bo= th solutions are similar and suffer from roughly the same issues.

 

[Med] Agree.

As long as there is a 1:1 mapping between client-proxy and proxy-server sub= flows, I don't think there are many issues. In case you have TFO on the cli= ent-proxy leg, but not on the server, you have to transmit the SYN's payloa= d in a subsequent packet.

When you have to convert between MPTCP and regular TCP, you can no longer t= ranslate everything packet-by-packet and let end-to-end congestion control = do the work for you (and you can't relay ECN, either). Further:
 * In MPTCP, different subflows may send the same data using different= options and/or DSCP.
 * You can't freely mix TCP timestamps from different subflows. (The o= nly guarantee is that timestamps are numbers that increase monotonically fo= r each individual subflow.)

I would go even further and say that, on principle, a proxy should not rela= y unknown TCP options, but rather strip them.

[Med] I’= ;m not sure I would go that way.



=B7&nbs= p;        IPv6 source address/= prefix preservation

 

I'm not sure what you mean by that.

[Med] Please = see slide 18 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-as= sisted-mptcp-03.pdf  

--_000_787AE7BB302AE849A7480A190F8B93300A001A07OPEXCLILMA3corp_-- From nobody Thu Jul 6 06:02:38 2017 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 C6B79131721; Thu, 6 Jul 2017 06:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 TZakN6PyorVt; Thu, 6 Jul 2017 06:02:35 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B5E12EC40; Thu, 6 Jul 2017 06:02:35 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 72AA41803C1; Thu, 6 Jul 2017 15:02:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 345E84005B; Thu, 6 Jul 2017 15:02:33 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 15:02:32 +0200 From: To: Joe Touch , Vladimir Olteanu , David Schinazi CC: multipathtcp , "Int-area@ietf.org" Thread-Topic: [multipathtcp] [Int-area] SOCKS 6 Draft Thread-Index: AQHS9a08Y4IlRnpvi0+MgNkwp3/CEKJFUyCAgAFwI6A= Date: Thu, 6 Jul 2017 13:02:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A001A21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A001A21OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 13:02:37 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A001A21OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, Please see inline. Cheers, Med De : Joe Touch [mailto:touch@isi.edu] Envoy=E9 : mercredi 5 juillet 2017 18:59 =C0 : Vladimir Olteanu; BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : multipathtcp; Int-area@ietf.org Objet : Re: [multipathtcp] [Int-area] SOCKS 6 Draft On 7/5/2017 9:39 AM, Vladimir Olteanu wrote: It can also be stacked as many times as desired for arbitrarily long proxy= chains. However: * We avoid using the SYN's payload as extra option space (which, I think, = goes against TCP's core philosophy). [Med] This is also true for MP_CONVERT Information Element which is not a T= CP option, but a data supplied for proxy purposes in the SYN payload. Fair enough, but this is not a purely layer 5+ protocol. It seems that you = are strongly tied to TFO (between the client and the proxy). MP_CONVERT mus= t be part of the SYN's payload, because the following SYN+ACK depends on th= e contents of MP_CONVERT and signals that the remote server has accepted yo= ur connection. The biggest impact of including non-data information in the SYN payload are= a is that it completely defeats graceful fallback for SYN receivers that do= n't support the option. As you note, it can be *more* safe when tied to out= -of-band context (e.g., prior TFO support), but TCP has NO requirement that= such context is absolutely maintained across different connections. You mi= ght be speaking to a different stack or demuxed off to a different virtual = host behind a load balancer. Ultimately, putting any non-data info in the SYN payload violates the requi= rement that TCP options can be ignored by receivers that don't support them= *without* impacting the ability of *that* connection attempt to succeed. [Med] You are right... if we are talking about TCP options that are inserte= d in the payload of the SYN to every remote peer. This is not the case for = the MPTCP proxy case: this is about proxy-supplied data that is sent to the= proxy, which is provisioned by the provider. Proxy-supplied data is not re= ceived by the remote peer. Joe --_000_787AE7BB302AE849A7480A190F8B93300A001A21OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

Please see inline.

 

Cheers,

Med

 

De := Joe Touch [mailto:touch@isi.edu]
Envoy=E9 : mercredi 5 juillet 2017 18:59
=C0 : Vladimir Olteanu; BOUCADAIR Mohamed IMT/OLN; David Schina= zi
Cc : multipathtcp; Int-area@ietf.org
Objet : Re: [multipathtcp] [Int-area] SOCKS 6 Draft<= /span>

 

 

 

On 7/5/2017 9:39 AM, Vladimir Olteanu wrote:

 It can also be stacked as many times as desir= ed for arbitrarily long proxy chains. However:
 * We avoid using the SYN's payload as extra option space (which, I th= ink, goes against TCP's core philosophy).

[Med] This is also true for MP_CONVERT Informati= on Element which is not a TCP option, but a data supplied for proxy purposes in the SYN payload.

Fair enough, but this is not a purely layer 5+ p= rotocol. It seems that you are strongly tied to TFO (between the client and= the proxy). MP_CONVERT must be part of the SYN's payload, because the foll= owing SYN+ACK depends on the contents of MP_CONVERT and signals that the remote server has accepted your connect= ion.


The biggest impact of including non-data information in the SYN payload are= a is that it completely defeats graceful fallback for SYN receivers that do= n't support the option. As you note, it can be *more* safe when tied to out= -of-band context (e.g., prior TFO support), but TCP has NO requirement that such context is absolutely maint= ained across different connections. You might be speaking to a different st= ack or demuxed off to a different virtual host behind a load balancer.

Ultimately, putting any non-data info in the SYN payload violates the requi= rement that TCP options can be ignored by receivers that don't support them= *without* impacting the ability of *that* connection attempt to succeed.

[Med] You are= right… if we are talking about TCP options that are inserted in the = payload of the SYN to every remote peer. This is not the case for the MPTCP proxy case: this is about proxy-supplied data that is sent to th= e proxy, which is provisioned by the provider. Proxy-supplied data is not r= eceived by the remote peer.   



Joe

--_000_787AE7BB302AE849A7480A190F8B93300A001A21OPEXCLILMA3corp_-- From nobody Fri Jul 7 00:19:13 2017 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 D3431126C23; Fri, 7 Jul 2017 00:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FQ0Ph3ok4Xei; Fri, 7 Jul 2017 00:19:03 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id A4607131A4F; Fri, 7 Jul 2017 00:19:02 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AM6DJsBSwGMLu8+KbuTTuayw4ddpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67ZBKAt8tkgFKBZ4jH8fUM07OQ6PG/HzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdwIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZH42y?= =?us-ascii?q?cYUPAeoCM+hWoYbyqFkBogelCAa2GO/i0CVFimP40KA61ekqDAHI3BYnH9ILqH?= =?us-ascii?q?nbo9H1O70PXuC0yanIzC/DZO5P1zf59IjHbAouofeRXbltdsfR100vGBnYgVWR?= =?us-ascii?q?rIzlPimV2v4Ks2if8+pvS/igi2g6qwxqvjev3d0gipHUho0O0FzE7yJ5zZ8zKN?= =?us-ascii?q?alRkB7ZtukH4FRtyGcL4Z2Q90tQ31muCogzb0Go5G7cS4Xw5ok3x7Sc+GLfoeV?= =?us-ascii?q?7h75V+ucIS10iGx7dL+9nRq//1Csx+n8W8Wu0ltHrzBJnsTSun0OzRDf9NSLRu?= =?us-ascii?q?Z780y8wziAzRrT5ftBIU0skKrbLIMuzaAom5oItETDAjf2mELrjK+Kbkkk+van?= =?us-ascii?q?6+DgYrj+uJ+cMpV7igD6Mqg0hsO/Gv40MhATX2eA4+i8zrrj8VX4QLVMkPI2jr?= =?us-ascii?q?HUvI3VKMgGvKK0AA9Y3pw95xqhDTqqytoVkWECLF1feRKHi4bpO0vJIPD9Ffq/?= =?us-ascii?q?nVCsny12yPDHO73hA4/NImLEkLflYbZy9VRTyAwuzd1E+51UEasNIOruWkDqrt?= =?us-ascii?q?DYFBg5PxSuw+n7ENV9yp8eWWWXD6CEK6PdrV+I5uMpI+aWZY4VuS3wJOI95/72?= =?us-ascii?q?iX82h0URcrWu3ZsScHq4BOhpI12FYXrwhdcMCWQEvgwiTODzklKCSyBcaGypUq?= =?us-ascii?q?I9+D47FIymAZ3ERoC3j7yLxD27EYFOZmBaFlCMFm/ld4CZW/cIdCKSI9dhnSYY?= =?us-ascii?q?VbihV48uyQmuuRT7y7V5MurU9DcUtZX51Nh6/+fTjw099SRoD8SB1GGAV2R0nm?= =?us-ascii?q?QIRzAs2aBwv1Fyxk2Y3qh/nvxXCcZc6O5TXQc7L57R1Ot6C8roVQLHcdeGVkyq?= =?us-ascii?q?TcmhATE0HZoNxIoLZEZ0HtiuyBrEwiGjD7YUjZSMHpUy/a+a1H/0Y45RwmjH2O?= =?us-ascii?q?EahFknRMJdNCXyirV09wnVDpzIu0yBj6KnM68b2Xie2n2EyD+wuEhUUQtxS+3i?= =?us-ascii?q?WWwSb03L5YDn4krOTrqvE/IgNhdMwMifAqBRLMX0hxNcQ6Gwa5zlf2utljLoVl?= =?us-ascii?q?6zzbSWYd+vIj1F0Q=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DyAQC3NF9ZjAPjVY1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBFQEBAQECAQEBAQgBAQEBgkSBTwOBEY58kHeYFC6FbgKEEwEBAQEBAQEBAgE?= =?us-ascii?q?SAQEBJleCMyQBgkEBAgECLUwQCxgnB0YRBgEMBgIBAReKGAyyZymLCwEBAQEBA?= =?us-ascii?q?QQBAQEBAQEBARsFgyiDTIFhK4J5hEZahT4FkVSNSIIjk3OFS4NOhnqMZIhTAla?= =?us-ascii?q?BCzEhhiSBdnMBhl6CPwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2DyAQC3NF9ZjAPjVY1cGwEBAQMBAQEJAQEBFQEBAQECAQE?= =?us-ascii?q?BAQgBAQEBgkSBTwOBEY58kHeYFC6FbgKEEwEBAQEBAQEBAgESAQEBJleCMyQBg?= =?us-ascii?q?kEBAgECLUwQCxgnB0YRBgEMBgIBAReKGAyyZymLCwEBAQEBAQQBAQEBAQEBARs?= =?us-ascii?q?FgyiDTIFhK4J5hEZahT4FkVSNSIIjk3OFS4NOhnqMZIhTAlaBCzEhhiSBdnMBh?= =?us-ascii?q?l6CPwEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,321,1496091600"; d="scan'208,217";a="877872" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 07 Jul 2017 10:18:58 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id E3D911A6014E; Fri, 7 Jul 2017 10:18:58 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QcVX8nJ2vKDU; Fri, 7 Jul 2017 10:18:58 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id C49131A60142; Fri, 7 Jul 2017 10:18:58 +0300 (EEST) Received: from [192.168.1.70] (unknown [95.76.128.201]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id B56141A600E5; Fri, 7 Jul 2017 10:18:58 +0300 (EEST) To: mohamed.boucadair@orange.com, David Schinazi Cc: "Int-area@ietf.org" , multipathtcp References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A001A07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Vladimir Olteanu Message-ID: <6ca9c64f-c9ca-f245-e28f-16073fa46c39@cs.pub.ro> Date: Fri, 7 Jul 2017 10:18:58 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A001A07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------10EB8E1C299B1C20217CF829" Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 07:19:07 -0000 This is a multi-part message in MIME format. --------------10EB8E1C299B1C20217CF829 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mohamed, I'm replying specifically to the parts quoted below. SOCKS is used by explicit proxies; anything related to transparent=20 proxies is beyond its scope. It does not preclude the deployment of=20 anything transparent. In other words, I merely propose it as an=20 alternative to MP_CONVERT. Discussing PCP, IPv6 source address preservation, UPnP etc. makes no=20 sense in this context. Cheers, Vlad On 7/6/2017 3:56 PM, mohamed.boucadair@orange.com wrote: > > *De :*Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] > *Envoy=E9 :* mercredi 5 juillet 2017 18:39 > *=C0 :* BOUCADAIR Mohamed IMT/OLN; David Schinazi > *Cc :* Int-area@ietf.org; multipathtcp > *Objet :* Re: [Int-area] SOCKS 6 Draft > > > > On 7/5/2017 9:00 AM, mohamed.boucadair@orange.com=20 > wrote: > > > > *De :*Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] > *Envoy=E9 :* mercredi 5 juillet 2017 01:35 > *=C0 :* BOUCADAIR Mohamed IMT/OLN; David Schinazi > *Cc :* Int-area@ietf.org ; multipathtcp > *Objet :* Re: [Int-area] SOCKS 6 Draft > > > > Can you please let me know if the proposal supports the following=20 > features: > > =B7Support incoming connections (Proxy<---Remote Host): That is the=20 > proxy intercept a TCP connection that it transforms into an MPTCP one. > > Yes. See section 7.2. The client makes a request and then has to keep=20 > the connection to the proxy open. When the proxy accepts a connection=20 > from a remote host, it informs the client of the remote host's address=20 > and starts relaying data. SOCKS 5 has the exact same feature. You are=20 > limited to one incoming connection per request, though. > > [Med] In the plain mode, there is no such limitation because we are=20 > leveraging on PCP (RFC6887). > > =B7If such feature is supported, how a host located behind a CPE=20 > (Host----CPE-----Proxy----Remote Host) can instruct dynamically the=20 > CPE so that it can forward appropriately incoming connections? > > It does not have to. The connection on the host-proxy leg is initiated=20 > by the client. > > [Med] I=92m not sure to understand your answer here. Let=92s consider t= hat=20 > your host is using UPnP IGD to talk with the CPE to accept incoming=20 > connections + those connections are eligible to the MPTCP service. How=20 > the solution would work? > > > > =B7IPv6 source address/prefix preservation > > I'm not sure what you mean by that. > > [Med] Please see slide 18 of=20 > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-networ= k-assisted-mptcp-03.pdf=20 > > --------------10EB8E1C299B1C20217CF829 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Mohamed,

I'm replying specifically to the parts quoted below.

SOCKS is used by explicit proxies; anything related to transparent proxies is beyond its scope. It does not preclude the deployment of anything transparent. In other words, I merely propose it as an alternative to MP_CONVERT.

Discussing PCP, IPv6 source address preservation, UPnP etc. makes no sense in this context.

Cheers,
Vlad


On 7/6/2017 3:56 PM, mohamed.boucadair@orange.com wrote:

De=A0: Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro= ]
Envoy=E9=A0: mercredi 5 juillet 2017 18:39
=C0=A0: BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc=A0: Int-area@ietf.org; multipathtcp
Objet=A0: Re: [Int-area] SOCKS 6 Draft

=A0<SNIP>

On 7/5/2017 9:00 AM, mohamed.boucadair@orange.com wrote:

<SNIP= >

=A0

De=A0: Vladimir Olteanu [mailto:vladimir.olteanu@cs.p= ub.ro]
Envoy=E9=A0: mercredi 5 juillet 2017 01:35
=C0=A0: BOUCADAIR Mohamed IMT/OLN; David Schinaz= i
Cc=A0: Int-area@ietf.org; multipathtcp
Objet=A0: Re: [Int-area] SOCKS 6 Draft

<SNIP>

Can you please let me know if the proposal supports the following features:<= o:p>

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Support incoming connections (Proxy<---Remote Host): That is the proxy intercept a TCP connection that it transforms into an MPTCP one.

Yes. See section 7.2. The client makes a request and then has to keep the connection to the proxy open. When the proxy accepts a connection from a remote host, it informs the client of the remote host's address and starts relaying data. SOCKS 5 has the exact same feature. You are limited to one incoming connection per request, though.

[Med] I= n the plain mode, there is no such limitation because we are leveraging on PCP (RFC6887).

=B7=A0=A0=A0=A0=A0=A0=A0=A0 If such feature is supported, how a host located behind a CPE (Host----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so that it can forward appropriately incoming connections?

It does not have to. The connection on the host-proxy leg is initiated by the client.

[Med] I=92m not sure to understand your answer here. Let=92s consider that your host is using UPnP IGD to talk with the CPE to accept incoming connections + those connections are eligible to the MPTCP service. How the solution would work?

<SNIP>

=B7=A0=A0=A0=A0=A0=A0=A0=A0 IPv6 source address/prefix preservation

=A0

I'm not sure what you mean by that.

[Med] Please see slide 18 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-= assisted-mptcp-03.pdf =A0


--------------10EB8E1C299B1C20217CF829-- From nobody Fri Jul 7 01:17:12 2017 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 6820F126CD6; Fri, 7 Jul 2017 01:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yQYBNICt1oIg; Fri, 7 Jul 2017 01:17:03 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB89D1241FC; Fri, 7 Jul 2017 01:17:02 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 0F1F5120697; Fri, 7 Jul 2017 10:17:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id E3475180084; Fri, 7 Jul 2017 10:17:00 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0352.000; Fri, 7 Jul 2017 10:17:00 +0200 From: To: Vladimir Olteanu , David Schinazi CC: "Int-area@ietf.org" , multipathtcp Thread-Topic: [Int-area] SOCKS 6 Draft Thread-Index: AQHS9vFOvbFXN1Rf6EegJF/ZWBQrJqJH/inQ Date: Fri, 7 Jul 2017 08:17:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A002076@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A001A07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6ca9c64f-c9ca-f245-e28f-16073fa46c39@cs.pub.ro> In-Reply-To: <6ca9c64f-c9ca-f245-e28f-16073fa46c39@cs.pub.ro> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A002076OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 08:17:05 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A002076OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vlad, Please see inline. Cheers, Med De : Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] Envoy=E9 : vendredi 7 juillet 2017 09:19 =C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft Hi Mohamed, I'm replying specifically to the parts quoted below. SOCKS is used by explicit proxies; anything related to transparent proxies = is beyond its scope. [Med] The definition we had so far is that "explicit proxy" means that the = client is aware about the presence of the proxy and such packets are sent e= xplicitly to that proxy. An explicit proxy can therefore behave either as t= ransparent or non-transparent. I understand, that the current design assume= s non-transparent mode. It does not preclude the deployment of anything transparent. In other word= s, I merely propose it as an alternative to MP_CONVERT. Discussing PCP, IPv6 source address preservation, UPnP etc. makes no sense = in this context. [Med] I disagree. The support of incoming connections is one of the require= ments of the MPTCP WG: "A session can be initiated from either end". This is why I'm wondering how this typical flow can be achieved with SOCKS. H<=3D=3D=3D=3D=3DCPE<----------proxy<=3D=3D=3DRM +----------+ Cheers, Vlad On 7/6/2017 3:56 PM, mohamed.boucadair@orange.com wrote: De : Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] Envoy=E9 : mercredi 5 juillet 2017 18:39 =C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft On 7/5/2017 9:00 AM, mohamed.boucadair@orange.com wrote: De : Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] Envoy=E9 : mercredi 5 juillet 2017 01:35 =C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft Can you please let me know if the proposal supports the following features: * Support incoming connections (Proxy<---Remote Host): That is the = proxy intercept a TCP connection that it transforms into an MPTCP one. Yes. See section 7.2. The client makes a request and then has to keep the c= onnection to the proxy open. When the proxy accepts a connection from a rem= ote host, it informs the client of the remote host's address and starts rel= aying data. SOCKS 5 has the exact same feature. You are limited to one inco= ming connection per request, though. [Med] In the plain mode, there is no such limitation because we are leverag= ing on PCP (RFC6887). * If such feature is supported, how a host located behind a CPE (Ho= st----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so tha= t it can forward appropriately incoming connections? It does not have to. The connection on the host-proxy leg is initiated by t= he client. [Med] I'm not sure to understand your answer here. Let's consider that your= host is using UPnP IGD to talk with the CPE to accept incoming connections= + those connections are eligible to the MPTCP service. How the solution wo= uld work? * IPv6 source address/prefix preservation I'm not sure what you mean by that. [Med] Please see slide 18 of https://www.ietf.org/proceedings/98/slides/sli= des-98-mptcp-sessa-network-assisted-mptcp-03.pdf --_000_787AE7BB302AE849A7480A190F8B93300A002076OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Vlad,

 

Please see inline.

 

Cheers,

Med

 

De := Vladimir Olteanu [mailto:vladimir.olteanu@cs.= pub.ro]
Envoy=E9 : vendredi 7 juillet 2017 09:19
=C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

 

Hi Mohamed,

I'm replying specific= ally to the parts quoted below.

SOCKS is used by explicit proxies; anything related to transparent proxies = is beyond its scope.

= [Med] The definition we had so far is that “explicit proxy” mea= ns that the client is aware about the presence of the proxy and such packets are sent explicitly to that proxy. An explicit proxy can ther= efore behave either as transparent or non-transparent. I understand, that t= he current design assumes non-transparent mode.   

=  It does not preclude the deployment of anything transparent. In other= words, I merely propose it as an alternative to MP_CONVERT.

Discussing PCP, IPv6 source address preservation, UPnP etc. makes no= sense in this context.

= [Med] I disagree. The support of incoming connections is one of the requirements of the MPTCP WG: "A session can be initiated fr= om either end”.

= This is why I’m wondering how this typical flow can be achieved with = SOCKS.

 

H<=3D=3D=3D=3D=3DCPE<= span style=3D"font-size:10.0pt;font-family:Wingdings;color:black">=DF--------proxy<=3D=3D=3DRM

     &= nbsp;   +----------+

 

=
Cheers,
Vlad

On 7/6/2017 3:56 PM, mohamed.b= oucadair@orange.com wrote:

De : Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro]
Envoy=E9 : mercredi 5 juillet 2017 18:39
=C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org= ; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

 <SNIP>

On 7/5/2017 9:00 AM, mohamed.boucadair@orange.co= m wrote:

<SNIP>

 

De : Vladimir Olteanu [mailto:vla= dimir.olteanu@cs.pub.ro]
Envoy=E9 : mercredi 5 juillet 2017 01:35
=C0 : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org= ; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

<SNIP>

Can you please let me know if th= e proposal supports the following features:

=B7         Support incoming connections= (Proxy<---Remote Host): That is the proxy intercept a TCP connection th= at it transforms into an MPTCP one.

Yes. See section 7.2. The client makes a request and then has to k= eep the connection to the proxy open. When the proxy accepts a connection f= rom a remote host, it informs the client of the remote host's address and starts relaying data. SOCKS 5 has the exa= ct same feature. You are limited to one incoming connection per request, th= ough.

[Med] In the plain= mode, there is no such limitation because we are leveraging on PCP (RFC688= 7).

=B7         If such feature is supported= , how a host located behind a CPE (Host----CPE-----Proxy----Remote Host) ca= n instruct dynamically the CPE so that it can forward appropriately incoming connections?

It does not have to. The connection on the host-proxy leg is initi= ated by the client.

[Med] I’m no= t sure to understand your answer here. Let’s consider that your host = is using UPnP IGD to talk with the CPE to accept incoming connections + those connections are eligible to the MPTCP service. How= the solution would work?


<SNIP>


=B7         IPv6 source address/prefix p= reservation

 

I'm not sure what you mean by that.

[Med] Please see s= lide 18 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-as= sisted-mptcp-03.pdf  

 

--_000_787AE7BB302AE849A7480A190F8B93300A002076OPEXCLILMA3corp_-- From nobody Fri Jul 7 04:23:58 2017 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 F4171129B01; Fri, 7 Jul 2017 04:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vl5z6n3c9gPb; Fri, 7 Jul 2017 04:23:51 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id A7DFD129AD2; Fri, 7 Jul 2017 04:23:50 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3Au1ZxdhHXJcs6iBNXtutEx51GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ76p8q9bnLW6fgltlLVR4KTs6sC0LuJ9fi4EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6/bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+?= =?us-ascii?q?RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPC?= =?us-ascii?q?TQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhz?= =?us-ascii?q?sGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSndbXstJSiJPHI28?= =?us-ascii?q?YYsMAeQPM+lXoIvyqEcVoBSkGQWhHvnixiNGi3L226AxzuQvERvB3AwlB98Bv3?= =?us-ascii?q?DUo8/oO6cTVOC1zbPIxijaYfNSxTfy9pLHchY8ofqRWr9wb87RxlMyGAPEi1WQ?= =?us-ascii?q?qJblMymS1uQJr2iU8fBvVeSyi2M8tw5xuSKjxt8xiobSnI4V0FfE+Dx/zY0oK9?= =?us-ascii?q?O4T0t7bsSlEJtWryyaNpV5Qt8sQ21yvyY60LIGtJimdyYJ0JQq3wPTZvOaf4SS?= =?us-ascii?q?4R/uVPydLSlmiH9nYr6yiQ6+/Eygx+HmVMS50UxGojdbntTPrHwByQDf5tWBR/?= =?us-ascii?q?Bg5EmuwyyP2BrW6uxcJEA0krfUJIA5z74rk5oTrVzDHijrmEXqlKOWdlsr+uyv?= =?us-ascii?q?6+n/fLXmo4WTN45wig3kLqsugdazAfwlMgcVRWSb4+O82KXi/U3/XrpKkuU7nr?= =?us-ascii?q?TWvZzHP8gWpa60DxVL3oo96RuzFTmr3MwdnXYdLVJFfByHj5LuO1HLOP34E/O/?= =?us-ascii?q?jE6xnzdqwvDGP6fhDo/KLnjHjLfuY6xy60hByAco0d9f/IhYCqkcIP3oQEPxrt?= =?us-ascii?q?vYAgcjMwOo2+bnFMl91oQGVG2SGa+WLKPSsV6O5u01IuiMZZQYtyzlK/g94/7h?= =?us-ascii?q?k2U1lkMafamsxZEXcmy3Hux6I0WFZnrhmtQPEWEWvgYnVuPqkkONXiRIanazQa?= =?us-ascii?q?08+j87BJihDYfZSYCnmKaB0zujHp1KemBGDUiBEXL1d4WAR/cMaTqSLdV9kjwE?= =?us-ascii?q?SbiuV5ch2AqvtADk17pnIPDY+ioCtZLszNJ1/fHclQku9TxoCMSQy2SNT2Z0nm?= =?us-ascii?q?wSQj85wr1wrVZmxVeEzKh3n+ZXGsFJ6PNISAc3Lpncz/ZgBND0VQLOYM2FR0qh?= =?us-ascii?q?QtWjUnkNSYc0xN8HZktxXd+lkxvK0yOrGZcSjbWNC5Fy+aXZmzDdLth8xz7936?= =?us-ascii?q?kgiVA0Q4MbOXathq95/hrSL4fRi0GU0a2tcPJP8jTK8TK9yWOCvURZSkZXVbnI?= =?us-ascii?q?VHYCLh/Iqd3150bDVfmpDagqOw1c4cWZbLNXYJvzigMVF7/YJN3CbjfpyC+LDh?= =?us-ascii?q?GSy+bJNdKydg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DAAQB0bl9ZjAPjVY1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgkSBTwOBEY58kFUimBQuhW4ChBsBAQEBAQE?= =?us-ascii?q?BAQIBEgEBASZXgjMkAYJBAQIBAi1MEAsYIAcHRhEGAQwGAgEBF4oYDLIfKYsLA?= =?us-ascii?q?QEBAQEBBAEBAQEBAQEBGwWDKINMgWErC4JuhEYOTIU+BYlbh3mFYYdngiOTc4V?= =?us-ascii?q?Lg06GeoxkiFMCVoELMSGGJIF2cwGGXoI/AQEB?= X-IPAS-Result: =?us-ascii?q?A2DAAQB0bl9ZjAPjVY1bGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgkSBTwOBEY58kFUimBQuhW4ChBsBAQEBAQEBAQIBEgEBASZXg?= =?us-ascii?q?jMkAYJBAQIBAi1MEAsYIAcHRhEGAQwGAgEBF4oYDLIfKYsLAQEBAQEBBAEBAQE?= =?us-ascii?q?BAQEBGwWDKINMgWErC4JuhEYOTIU+BYlbh3mFYYdngiOTc4VLg06GeoxkiFMCV?= =?us-ascii?q?oELMSGGJIF2cwGGXoI/AQEB?= X-IronPort-AV: E=Sophos;i="5.40,322,1496091600"; d="scan'208,217";a="878338" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 07 Jul 2017 14:23:45 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 105C91A600E5; Fri, 7 Jul 2017 14:23:46 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 85uvMC4ke7oq; Fri, 7 Jul 2017 14:23:45 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id E46931A60142; Fri, 7 Jul 2017 14:23:45 +0300 (EEST) Received: from [192.168.1.70] (unknown [95.76.128.201]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id D3D621A600E5; Fri, 7 Jul 2017 14:23:45 +0300 (EEST) To: mohamed.boucadair@orange.com, David Schinazi Cc: "Int-area@ietf.org" , multipathtcp References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A001A07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6ca9c64f-c9ca-f245-e28f-16073fa46c39@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A002076@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Vladimir Olteanu Message-ID: <347e289c-6559-0b3e-f0af-302857fb2d45@cs.pub.ro> Date: Fri, 7 Jul 2017 14:23:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A002076@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------A624619EBE58FDE8F9FE2892" Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 11:23:56 -0000 This is a multi-part message in MIME format. --------------A624619EBE58FDE8F9FE2892 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Med, As per usual, inline. Cheers, Vlad On 7/7/2017 11:17 AM, mohamed.boucadair@orange.com wrote: > > Hi Vlad, > > Please see inline. > > Cheers, > > Med > > *De :*Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] > *Envoy=E9 :* vendredi 7 juillet 2017 09:19 > *=C0 :* BOUCADAIR Mohamed IMT/OLN; David Schinazi > *Cc :* Int-area@ietf.org; multipathtcp > *Objet :* Re: [Int-area] SOCKS 6 Draft > > Hi Mohamed, > > I'm replying specifically to the parts quoted below. > > SOCKS is used by explicit proxies; anything related to transparent=20 > proxies is beyond its scope. > > [Med] The definition we had so far is that =93explicit proxy=94 means t= hat=20 > the client is aware about the presence of the proxy and such packets=20 > are sent explicitly to that proxy. An explicit proxy can therefore=20 > behave either as transparent or non-transparent. I understand, that=20 > the current design assumes non-transparent mode. > Yes, what I meant was "non-transparent". > > It does not preclude the deployment of anything transparent. In other=20 > words, I merely propose it as an alternative to MP_CONVERT. > > Discussing PCP, IPv6 source address preservation, UPnP etc. makes no=20 > sense in this context. > > [Med] I disagree. The support of incoming connections is one of the=20 > requirements of the MPTCP WG:"A session can be initiated from either en= d=94. > > This is why I=92m wondering how this typical flow can be achieved with=20 > SOCKS. > > H<=3D=3D=3D=3D=3DCPE=DF--------proxy<=3D=3D=3DRM > > +----------+ > My point was that if you want any transparent functionality, you have to=20 use something other than SOCKS, but now I see what you mean. Currently, SOCKS 6 has the same limited support for this scenario that=20 v5 has. The client opens a connection to the server and asks it to=20 listen for an incoming connection. When a remote host connects to the=20 proxy, the server sends a reply (v5)/operation reply (v6) to the client=20 (via the connection that the client initiated) containing the remote=20 host's address and starts relaying data back and forth. I think adequately handling this use case would mean adding a reverse=20 mode to SOCKS 6: * The client informs the proxy on which port it is listening. (It's=20 the client's job to set up port forwarding etc.) * For each incoming connection, the proxy opens a connection to the=20 client, sends an operation reply containing the remote host's IP and=20 port, and then relays data. > > > Cheers, > Vlad > > On 7/6/2017 3:56 PM, mohamed.boucadair@orange.com=20 > wrote: > > *De :*Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] > *Envoy=E9 :* mercredi 5 juillet 2017 18:39 > *=C0 :* BOUCADAIR Mohamed IMT/OLN; David Schinazi > *Cc :* Int-area@ietf.org ; multipathtcp > *Objet :* Re: [Int-area] SOCKS 6 Draft > > > > On 7/5/2017 9:00 AM, mohamed.boucadair@orange.com > wrote: > > > > *De :*Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.ro] > *Envoy=E9 :* mercredi 5 juillet 2017 01:35 > *=C0 :* BOUCADAIR Mohamed IMT/OLN; David Schinazi > *Cc :* Int-area@ietf.org ; multipatht= cp > *Objet :* Re: [Int-area] SOCKS 6 Draft > > > > Can you please let me know if the proposal supports the following > features: > > =B7Support incoming connections (Proxy<---Remote Host): That is the > proxy intercept a TCP connection that it transforms into an MPTCP o= ne. > > Yes. See section 7.2. The client makes a request and then has to > keep the connection to the proxy open. When the proxy accepts a > connection from a remote host, it informs the client of the remote > host's address and starts relaying data. SOCKS 5 has the exact > same feature. You are limited to one incoming connection per > request, though. > > [Med] In the plain mode, there is no such limitation because we > are leveraging on PCP (RFC6887). > > =B7If such feature is supported, how a host located behind a CPE > (Host----CPE-----Proxy----Remote Host) can instruct dynamically > the CPE so that it can forward appropriately incoming connections? > > It does not have to. The connection on the host-proxy leg is > initiated by the client. > > [Med] I=92m not sure to understand your answer here. Let=92s consid= er > that your host is using UPnP IGD to talk with the CPE to accept > incoming connections + those connections are eligible to the MPTCP > service. How the solution would work? > > > > > > =B7IPv6 source address/prefix preservation > > I'm not sure what you mean by that. > > [Med] Please see slide 18 of > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-ne= twork-assisted-mptcp-03.pdf > > --------------A624619EBE58FDE8F9FE2892 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Med,

As per usual, inline.

Cheers,
Vlad

On 7/7/2017 11:17 AM, mohamed.boucadair@orange.com wrote:

Hi Vlad,

=A0

Please see inline.

=A0

Cheers,

Med

=A0

De=A0: Vladimir Olteanu [mailto:vladimir.olteanu@cs.pub.r= o]
Envoy=E9=A0: vendredi 7 juillet 2017 09:19
=C0=A0: BOUCADAIR Mohamed IMT/OLN; David Schinaz= i
Cc=A0: Int-area@ietf.org; multipathtcp
Objet=A0: Re: [Int-area] SOCKS 6 Draft

=A0

Hi Mohamed,

I'm reply= ing specifically to the parts quoted below.

SOCKS is used by explicit proxies; anything related to transparent proxies is beyond its scope.

[Med] The definition we had so far is that =93explicit proxy=94 means that the client is aware about the presence of the proxy and such packets are sent explicitly to that proxy. An explicit proxy can therefore behave either as transparent or non-transparent. I understand, that the current design assumes non-transparent mode. =A0

Yes, what I meant was "non-transparent".

=A0It does not preclude the deployment of anything transparent. In other words, I merely propose it as an alternative to MP_CONVERT.

Discussing PCP, IPv6 source address preservation, UPnP etc<= /span>. makes no sense in this context.

[Med] I disagree. The support of incomin= g connections is one of the requirements of the MPTCP WG: "A session can be initiated from either end=94.

This is why I=92m wondering how this typical flow can be achieved with SOCKS.

=A0=

H<=3D=3D=3D=3D=3DC= PE=DF--------proxy<=3D=3D= =3DRM

=A0=A0=A0=A0=A0=A0 =A0= =A0+----------+

My point was that if you want any transparent functionality, you have to use something other than SOCKS, but now I see what you mean.<= br>
Currently, SOCKS 6 has the same limited support for this scenario that v5 has. The client opens a connection to the server and asks it to listen for an incoming connection. When a remote host connects to the proxy, the server sends=A0 a reply (v5)/operation reply (v6) to the client (via the connection that the client initiated) containing the remote host's address and starts relaying data back and forth.
I think adequately handling this use case would mean adding a reverse mode to SOCKS 6:
=A0* The client informs the proxy on which port it is listening. (It'= s the client's job to set up port forwarding etc.)
=A0* For each incoming connection, the proxy opens a connection to th= e client, sends an operation reply containing the remote host's IP and port, and then relays data.

=A0=


Cheers,
Vlad

On 7/6/2017 3:56 = PM, mohamed.bou= cadair@orange.com wrote:

De=A0: Vladimir Olteanu [mailto:vladimir.olteanu@cs= .pub.ro]
Envoy=E9=A0: mercredi 5 juillet 2017 18:39
=C0=A0: BOUCADAIR Mohamed IMT/OLN; David Schin= azi
Cc=A0: Int-area@ietf.org; multipathtcp
Objet=A0: Re: [Int-area] SOCKS 6 Draft<= o:p>

=A0<SNIP>

<SNIP>

=A0

De=A0: Vladimir Olteanu [mailto:vladimir.oltean= u@cs.pub.ro]
Envoy=E9=A0: mercredi 5 juillet 2017 01:35=
=C0=A0: BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc=A0: Int-area@ietf.org; multipathtcp
Objet=A0: Re: [Int-area] SOCKS 6 Draft

<SNIP>

Ca= n you please let me know if the proposal supports the following features:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Su= pport incoming connections (Proxy<---Remote Host): That is the proxy intercept a TCP connection that it transforms into an MPTCP one.

Yes. See section 7.2. The client makes a request and then has to keep the connection to the proxy open. When the proxy accepts a connection from a remote host, it informs the client of the remote host's address and starts relaying data. SOCKS 5 has the exact same feature. You are limited to one incoming connection per request, though.<= /p>

[Med] In the pl= ain mode, there is no such limitation because we are leveraging on PCP (RFC6887).

=B7=A0=A0=A0=A0=A0=A0=A0=A0 If such feature is supported, how a host located behind a CPE (Host----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so that it can forward appropriately incoming connections? <= /p>

It does not have to. The connection on the host-proxy leg is initiated by the client.

[Med] I=92m not= sure to understand your answer here. Let=92s consider that you= r host is using UPnP IGD to talk with the CPE to accept incoming connections + those connections are eligible to the MPTCP service. How the solution would work?


<SNIP>


=B7=A0=A0=A0=A0=A0=A0=A0=A0 IP= v6 source address/prefix preservation

=A0=

I'm not sure what you mean by that.

[Med] Please se= e slide 18 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-= assisted-mptcp-03.pdf =A0

=A0


--------------A624619EBE58FDE8F9FE2892-- From nobody Fri Jul 7 13:16:05 2017 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 70F2E131612 for ; Fri, 7 Jul 2017 13:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PrtH2fo2usEk for ; Fri, 7 Jul 2017 13:16:02 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3BD131442 for ; Fri, 7 Jul 2017 13:16:01 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 7 Jul 2017 21:15:58 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Jul 2017 21:15:58 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Jul 2017 21:15:58 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Fri, 7 Jul 2017 21:15:58 +0100 From: To: , Thread-Topic: [multipathtcp] Draft agenda for Prague Thread-Index: AdL2P9CsLYnyeHkHQzapNEbqyFbGawABxPmAAEWvY2I= Date: Fri, 7 Jul 2017 20:15:57 +0000 Message-ID: <1499458550270.70007@bt.com> References: , <3e2c4959-d256-fee2-e2e7-a091f460885c@uclouvain.be> In-Reply-To: <3e2c4959-d256-fee2-e2e7-a091f460885c@uclouvain.be> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Draft agenda for Prague X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:16:04 -0000 Excellent!=0A= =0A= I'll add a slot to the agenda for a report from the hackathon (5-10mins??)= =0A= =0A= phil=0A= =0A= =0A= ________________________________________=0A= From: Olivier Bonaventure =0A= Sent: 06 July 2017 12:59=0A= To: Eardley,PL,Philip,TUD1 R; multipathtcp@ietf.org=0A= Subject: Re: [multipathtcp] Draft agenda for Prague=0A= =0A= Phil,=0A= > We just uploaded a draft agenda.=0A= >=0A= > Please let us know if anyone else would like a time slot (or if we=0A= > missed your request), we have plenty of time at the moment.=0A= =0A= Forgot to mention and add to the wiki but several of us will participate=0A= to the hackathon on MPTCP. We are also experimenting with the iOS11=0A= implementation and will at least have demo applications and perhaps=0A= other results to share=0A= =0A= =0A= Olivier=0A= From nobody Mon Jul 10 00:00:22 2017 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 C52E4127286 for ; Mon, 10 Jul 2017 00:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 rWechyEPWY20 for ; Mon, 10 Jul 2017 00:00:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E3A126DED for ; Mon, 10 Jul 2017 00:00:13 -0700 (PDT) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DD850278223 for ; Mon, 10 Jul 2017 16:00:09 +0900 (JST) Received: by mail-lf0-f43.google.com with SMTP id b207so51972361lfg.2 for ; Mon, 10 Jul 2017 00:00:09 -0700 (PDT) X-Gm-Message-State: AIVw110qqEQL7mcvKnyqBXz1Xy75EEVEp8q1eWU78IhkVeobez3rWJTi OUybAdIrsKqviGEEuiTgKpdOiMIhyw== X-Received: by 10.25.67.5 with SMTP id q5mr627270lfa.109.1499670007674; Mon, 10 Jul 2017 00:00:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.35.87 with HTTP; Mon, 10 Jul 2017 00:00:07 -0700 (PDT) In-Reply-To: <96151c77-fd31-f6ca-dca0-bffb9780f89f@cs.pub.ro> References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <96151c77-fd31-f6ca-dca0-bffb9780f89f@cs.pub.ro> From: Yoshifumi Nishida Date: Mon, 10 Jul 2017 00:00:07 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Vladimir Olteanu Cc: multipathtcp , =?UTF-8?Q?Drago=C8=99_Niculescu?= Content-Type: multipart/alternative; boundary="f403045ea4ca1680330553f12234" Archived-At: Subject: Re: [multipathtcp] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 07:00:21 -0000 --f403045ea4ca1680330553f12234 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vlad and Dragos, I really appreciate you for preparing the draft and brought it to here. As you might know, we have been exploring solutions for proxying mptcp sessions. We've had lots of discussions on plain mode and other solutions, but because we didn't have concrete proposals other than plain mode, it was difficult to compare the pros and the cons properly. But, now I believe we have a good chance to advance this. BTW, as I'm curious about this approach to use with mptcp, I have some questions for a certain scenario. In the WG, one use case we discuss is using two proxies like below. client ---- proxy1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D proxy2= ---- server In this scenario, we presume using TCP for client-proxy1 and proxy2-server, while using mptcp for proxy1-proxy2. The draft says it supports TFO, but I still think it takes some RTTs with approach although I miss something. It would be great if you could clarify the following points. 1: How will the connection between proxy1 and proxy2 set up? Does proxy1 need to negotiate proxy2 for authentication, etc? If so, it might add another delays before clients can send data. 2: Do clients need to wait a response for CONNECT request? If not, how it handles an error case? Thanks, -- Yoshi On Thu, Jun 29, 2017 at 5:02 AM, Vladimir Olteanu < vladimir.olteanu@cs.pub.ro> wrote: > Hello, > > We have submitted a draft describing a new version of the SOCKS protocol, > which could help in the deployment of MPTCP. You can find the abstract an= d > a link to the draft below. > > Best, > Vlad and Drago=C8=99 > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.tx= t > Date: Wed, 28 Jun 2017 22:01:16 -0700 > From: internet-drafts@ietf.org > To: Vladimir Olteanu > , Dragos Niculescu > > > A new version of I-D, draft-olteanu-intarea-socks-6-00.txt > has been successfully submitted by Vladimir Olteanu and posted to the > IETF repository. > > Name: draft-olteanu-intarea-socks-6 > Revision: 00 > Title: SOCKS Protocol Version 6 > Document date: 2017-06-28 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-olteanu-intare= a-socks-6-00.txt > Status: https://datatracker.ietf.org/doc/draft-olteanu-intarea-so= cks-6/ > Htmlized: https://tools.ietf.org/html/draft-olteanu-intarea-socks-6= -00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-olteanu-intar= ea-socks-6-00 > > > Abstract: > The SOCKS protocol is used primarily to proxy TCP connections to > arbitrary destinations via the use of a proxy server. Under the > latest version of the protocol (version 5), it takes 2 RTTs (or 3, if > authentication is used) before data can flow between the client and > the server. > > This memo proposes SOCKS version 6, which reduces the number of RTTs > used, takes full advantage of TCP Fast Open, and adds support for > 0-RTT authentication. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --f403045ea4ca1680330553f12234 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vlad and Dragos,

I really appreciate= you for preparing the draft and brought it to here.
As you might= know, we have been exploring solutions for proxying mptcp sessions.=C2=A0<= /div>
We've had lots of discussions on plain mode and other solutio= ns, but because we didn't have concrete proposals other than plain mode= , it was difficult to compare the pros and the cons properly. But, now I be= lieve we have a good chance to advance this.=C2=A0

BTW, as I'm curious about this approach to use with mptcp, I have some= questions for a certain scenario. In the WG, one use case we discuss is us= ing two proxies like below.
=C2=A0
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 client ---- proxy1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D proxy2 ---- server

In this scenario, we pre= sume using TCP for client-proxy1 and proxy2-server, while using mptcp for p= roxy1-proxy2.=C2=A0
The draft says it supports TFO, but I still t= hink it takes some RTTs with approach although I miss something. It would b= e great if you could clarify the following points.=C2=A0

1: =C2=A0How will the connection between proxy1 and proxy2 set up? D= oes proxy1 need to negotiate proxy2 for authentication, etc? If so, it migh= t add another delays before clients can send data.

2: Do clients need to wait a response for CONNECT request? If not, how it = handles an error case?

Thanks,
--
Yoshi


On Thu, Jun 29, 2017 at 5:02 AM, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro> wrote:
=20 =20 =20

Hello,

We have submitted a draft describing a new version of the SOCKS protocol, which could help in the deployment of MPTCP. You can find the abstract and a link to the draft below.

Best,
Vlad and Drago=C8=99



-------- Forwarded Message --------
Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
Date: Wed, 28 Jun 2017 22:01:16 -0700
From: internet-drafts@ietf.org
To: Vladimir Olteanu <vladimir.olteanu@cs.p= ub.ro>, Dragos Niculescu <dragos.niculescu@cs.pub= .ro> 


A new version of I-D, draft-olteanu-intarea-socks-6-00.txt
has been successfully submitted by Vladimir Olteanu and posted to the
IETF repository.

Name:		draft-olteanu-intarea-socks-6
Revision:	00
Title:		SOCKS Protocol Version 6
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            ht=
tps://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-=
00.txt
Status:         https://data=
tracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
Htmlized:       https://tools.i=
etf.org/html/draft-olteanu-intarea-socks-6-00
Htmlized:       https=
://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00=



Abstract:
   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipa= thtcp


--f403045ea4ca1680330553f12234-- From nobody Mon Jul 10 00:44:39 2017 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 D1A68128768 for ; Mon, 10 Jul 2017 00:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 zx_f4DXjbL6j for ; Mon, 10 Jul 2017 00:44:35 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A551275AB for ; Mon, 10 Jul 2017 00:44:35 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B323467DB0F; Mon, 10 Jul 2017 09:44:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be B323467DB0F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1499672665; bh=pHP8kQvNRrYDkcDlLkoLQObDvqhvPhG0Ygm8rVluPB4=; h=Reply-To:To:From:Subject:Date; b=q8EXHDLMaVx6zbjs+s2WU1dnkHkxHKRZTt2myeGiqtcx7Ga9fsG+w0JdT7tUArc54 AtQNT9N6A/KeTwVkRtCkU6/s9HB0ww5PlB903fAxIFvqojN0fBRBxiAkiNxR09KzBB IChUBdCdHlqdLmk8Ele1R1A2PDdYSxVkY0pzTH/U= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-1 Reply-To: Olivier.Bonaventure@uclouvain.be To: multipathtcp , "" From: Olivier Bonaventure Message-ID: Date: Mon, 10 Jul 2017 09:44:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: B323467DB0F.A2E13 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [multipathtcp] IETF'99 haskathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 07:44:38 -0000 Hello, Several of us will participate to the IETF99 in Prague. Since we'll arrive during the weekend, we plan to participate to the hackathon, at least on Sunday. If you are also in Prague, let us know so that we can coordinate and work on MPTCP related topics together. Thanks Olivier From nobody Mon Jul 10 09:16:05 2017 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 BDA501317D0 for ; Mon, 10 Jul 2017 09:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 qlZ2iKFlqt9E for ; Mon, 10 Jul 2017 09:16:01 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2951317D8 for ; Mon, 10 Jul 2017 09:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1499703361; x=1531239361; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=fY2LxRNG6PUAcOtDrsSlHSi6PcwdcIY4Rj+HanUjR7Y=; b=DTkejx7juTKddfyEydxYtdAhtfOHVRyrQR/Akr7Jt1klOU/F4cJLMIBG Rp/YyziNSKZ08xVJ46g9stNMMSm8nkar47f6P91iBXHHR0ssWhwhgP+MS hU8sllAElM8kCHaxzNnhuxeVG8E7PMYWaE0y7RDy4sJJEO5SNlSoKSRZJ R+biAA9L9wqMoaS7lyBl6qXRtlYkv1bmz/IrHxvqiPhd1izm6J+RayHI9 Z8eh9wUAcqluJpJZOglWRlgjTcGtD3oqOI+ScqC9kEDjb5hGeZrUjbnPs iLJpEK0WFNj1EmO7N4AyseeYKeThxnX4I5wLhuwqUt1CC2lX0sjqEm3No A==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2017 18:15:58 +0200 X-IronPort-AV: E=Sophos;i="5.40,341,1496095200"; d="scan'208";a="624689648" Received: from he105685.emea1.cds.t-internal.com ([10.169.119.47]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 10 Jul 2017 18:15:58 +0200 Received: from HE105686.EMEA1.cds.t-internal.com (10.169.119.48) by HE105685.emea1.cds.t-internal.com (10.169.119.47) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 18:15:58 +0200 Received: from HE105686.EMEA1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9]) by HE105686.emea1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9%26]) with mapi id 15.00.1263.000; Mon, 10 Jul 2017 18:15:58 +0200 From: To: Thread-Topic: A proposal for MPTCP Robust session Establishment (MPTCP RobE) Thread-Index: AdL5l2p+5KDR4ahqRJeh9onNd2ThSg== Date: Mon, 10 Jul 2017 16:15:57 +0000 Message-ID: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.36.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 16:16:05 -0000 Hi all, My name is Markus Amend from Deutsche Telekom Research & Innovation and I w= ant to propose an idea how to make MPTCP robust against outages during esta= blishment process of the initial flow. I want to start the discussion right= now in advance to the IETF 99 meeting, where I will present this topic for= discussion. It would be appreciated to receive some feedback in advance. --- Let's start with a short motivation --- A proposal for MPTCP Robust session Establishment (MPTCP RobE), related to = the real world problem: What happens if the default gateway (GW) does not p= rovide end-to-end connectivity, but an additional route is available?=20 I guess, all of you already faced the problem with your smartphone (or any = other device with more than one interface), connected to a bad WiFi, where = you manually switched off the WiFi interface to have at least connectivity = or a more stable connection over cellular network. This happens, because yo= ur smartphone decides for you to use the cheaper way, the WiFi way, but it = doesn't take care about reachability and stability. So, whenever a physical= WiFi connectivity is given, the smartphone puts the default GW to it. In t= he worst case, the WiFi is not able to establish an end-to-end connectivity= and it will fail, even if a proper cellular connectivity is available at t= he same time. The problem is not just related to smartphone implementations= , it is related to any device with more than one interface available! MPTCP implementations struggle with this as well and even more aggravated, = because MPTCP promises apparently redundancy if more the one path to destin= ation is available. But this isn't the case all the time, why? MPTCP relies on a concept of an initial flow, which has to be established f= irst, to negotiate MP capability and afterwards proceeds to establish subse= quent flows to enable redundancy or even capacity aggregation. If the initi= al flow fails to establish a (MP-)TCP connection, MPTCP will never make use= of other available paths and from an application view, there is no connect= ion possible. To summarize at this point again, first we need a proper initial flow estab= lishment before subsequent flows can be established and exploit multipath c= apabilities. Also in a scenario where we have a lot of working paths availa= ble, but the path used for the initial flow (mostly the default GW, or more= generic: default route) is unable to finish handshaking, we end in a zero = connectivity scenario. We demand: "If there is at least one functional path, a connection must be possible" With the idea of MPTCP Robust Establishment "MPTCP RobE" we try to solve or= mitigate the challenge of blocked or unstable path during initial flow est= ablishment and it would shift the full multipath capabilities to the very b= eginning of a MPTCP session. --- stop motivation --- --- start rough description --- Over the last year we developed three proposals, to tackle the challenge. W= e tried to meet the following criteria: 1. Robustness: If there is at least one functional path, a connection must = be possible 2. Overhead and latency: The solution should not introduce excessive amount= s of overhead and latency compared to standard MPTCP=20 3. Standard compliance: A solution should use and integrate with existing s= tandards and work around limitations In general, all proposals make use of redefining the initial flow towards a= >potential< initial flow. That gives the freedom to use several potential = initial flows at the very beginning of a session or shift the potential flo= ws between different path. Technically it is based on duplicating the MP_CA= PABLE option. Following the proposals (which will be explained in detail first during the= IETF 99 session), which all includes at least the first criteria: 1. "Downgrade" approach: Start on all available path potential initial flows, the first successfu= l one remains as the initial flow the others are "downgraded" to subsequent= ones. 2. "Break before Make" approach: Start on all available path potential initial flows, first successful on= e remains as the initial flow the others are reset. Standard MPTCP procedur= e follows to establish subsequent flows 3. "Timer" approach: One potential initial flow is started, if during a defined time slot no = establishment becomes apparent, a separate potential initial flow is starte= d on another path.=20 Currently the "Downgrade" approach is preferred from our side, because it p= rovides beside robustness the benefit of reducing handshaking time and sub = flows are created simultaneously and not delayed by initial flow establishm= ent -> The path providing the lowest latency determined the overall connect= ion latency. But there are still some minor drawbacks which needs to be solved. The solu= tion of potential initial flows leads to the problem, that the SYN-Receiver= cannot distinguish anymore between a valid Key A connection request or an = invalid one, which is accidentally used by a foreign requester or deliberat= ely by an attacker (e.g. brute force). MPTCP RobE tries to mitigate this ch= allenge by reducing the time frame of accepting new SYN-Key A requests for = a specific connection to the duration until the first initial flow is set u= p. But this is still not perfect and may be discussed in terms of security = aspects. Also the question of how to handle Address IDs in the context of p= otential initial flows, needs to be discussed. On the other hand the "Timer" approach can integrate with the existing stan= dard best, but doesn't exploit the full potential of a possible MPTCP RobE = standard/implementation and may be delay connection establishment for a lon= g while. Whereas the "Break before Make" approach behaves like the first on= e but will not speed up the overall latency in the same way, but incorporat= es better with the MPTCP standard. --- end rough description --- --- start outlook --- A first reference implementation was already done by us, based on MPTCP v0.= 90 and the "Downgrade" approach and is currently under lab investigation an= d optimization. Btw., we know the presentation from NICT (https://www.ietf.org/proceedings/= 98/slides/slides-98-mptcp-sessa-synduplication-00.pdf), but we see fundamen= tal differences, because robustness wasn't addressed there.=20 --- end outlook --- I'm looking forward to your comments. Kind regards Markus Amend DEUTSCHE TELEKOM AG T-Labs (Research & Innovation) Markus Amend LIFE IS FOR SHARING. =20 You can find the obligatory information on www.telekom.com/compulsory-state= ment BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. From nobody Mon Jul 10 16:19:40 2017 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 8317613194D for ; Mon, 10 Jul 2017 16:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vELcRD-_w3Oa for ; Mon, 10 Jul 2017 16:19:35 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5E131945 for ; Mon, 10 Jul 2017 16:19:33 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3ADMO63xFdegHn28aALqN+xp1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ7zrs+wAkXT6L1XgUPTWs2DsrQf2rWQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbQhFgDiwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VC+85Kl3VhDnlC?= =?us-ascii?q?YHNyY48G7JjMxwkLlbqw+lqxBm3oLYfJ2ZOP94c6jAf90VWHBBU95MWSJfDIOy?= =?us-ascii?q?b4gBAeQPMulXrYbyu0ADogGiCQS2Hu7j1jFFi33w0KYn0+ohCwbG3Ak4Et0BtH?= =?us-ascii?q?Tbtsj6NKYXUeC01qnD0CzNb/dK2Tjj8ofIdA0hquyLULJudcre01QgFwLAjlWR?= =?us-ascii?q?s4zpJTSV1uARs2eF9eVgU/+vhnU7pAFquDSv3toshZLTioIPzVDJ7CN0y5s2K9?= =?us-ascii?q?2gUEN3fNGpHIZKuyyZN4Z6WN0uT39qtSogxLAKoZq2cSgQxJklxhPTceGLf5aL?= =?us-ascii?q?7x75SuqdPSp0iXR4c7ylnRmy61KvyujkW8mx11ZFszRKn8HXtnAIyxzT8s+HSu?= =?us-ascii?q?Zh/ku52TaAyQTT6uZcLEAqkKrUMZ8hwroqmpUPqkTPBDf2mFjtg6OMbEUk/fCk?= =?us-ascii?q?6+XhYrr4up+RL5J4hw7jPqg0mcGyAf40PhYQU2WZ4+ix2qXv/UjjT7VLiv02nL?= =?us-ascii?q?PZsJffJckDuK65BxVa3Zsi6xa6Djemys4UnX4DLFJZZh2IlY7pO0zVLf/kFvez?= =?us-ascii?q?mUyskCpwyPzcJL3hBY3BLmLfn7f5YbZ990lcxRI2zdBC45JUFrABIOrpVU/ttN?= =?us-ascii?q?zYEgM2MxSvzubmFtp9yo0eVXiIAq+DP6PYqUWI6f43I+mQeI8Vvy7wK/4k5/71?= =?us-ascii?q?jX85mEIScrOy0JsMZnC3Au5qIkuYYXXxnNgNC30FsRckQOzokF3RGQJUMke1RK?= =?us-ascii?q?I96Cw+CcqADJzDR4ykyOiH3Ty7H5FfTntIARaTEHvlMYyIHfUUPnG8OMhkxwIA?= =?us-ascii?q?XLSgTo47nTaqqALzzacvevTQ8yEZsJP5kt9x++Dakwwa/icyF9mXlXuKGTIn1l?= =?us-ascii?q?gUTiM7ifgs6Xd2zU2OhO0h26RV?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AoAQBFCmRZjAPjVY1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBhBMDgRGOfJB4mBQhAQyDaoEQTwKEAwEBAQE?= =?us-ascii?q?BAQEBAgESAQEBJleCMyQBgkABAQEBAwEBIQRHCxAJAhEDAQIBHQoDAgInHwkIB?= =?us-ascii?q?g0GAgEBF4oYDI1jnWOBbDonixUBAQEBBgEBAQEBAQEhgyiDTIIMgW2BDIRUIhS?= =?us-ascii?q?Cc4JhBYlihm2BBY1KgiOFJY5OV4EPg2WDT4Z8lT4CD0eBCzEhVyqEWkmBcgRzA?= =?us-ascii?q?YhjAQEB?= X-IPAS-Result: =?us-ascii?q?A2AoAQBFCmRZjAPjVY1dGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBhBMDgRGOfJB4mBQhAQyDaoEQTwKEAwEBAQEBAQEBAgESAQEBJ?= =?us-ascii?q?leCMyQBgkABAQEBAwEBIQRHCxAJAhEDAQIBHQoDAgInHwkIBg0GAgEBF4oYDI1?= =?us-ascii?q?jnWOBbDonixUBAQEBBgEBAQEBAQEhgyiDTIIMgW2BDIRUIhSCc4JhBYlihm2BB?= =?us-ascii?q?Y1KgiOFJY5OV4EPg2WDT4Z8lT4CD0eBCzEhVyqEWkmBcgRzAYhjAQEB?= X-IronPort-AV: E=Sophos;i="5.40,343,1496091600"; d="scan'208,217";a="884836" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 11 Jul 2017 02:19:29 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 150A71A6003E; Tue, 11 Jul 2017 02:19:29 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3iTv_jn0PGLD; Tue, 11 Jul 2017 02:19:29 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id E8CB31A600A4; Tue, 11 Jul 2017 02:19:28 +0300 (EEST) Received: from [192.168.1.70] (unknown [95.76.128.201]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id CE7FD1A6003E; Tue, 11 Jul 2017 02:19:28 +0300 (EEST) To: Yoshifumi Nishida Cc: multipathtcp , =?UTF-8?Q?Drago=c8=99_Niculescu?= References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <96151c77-fd31-f6ca-dca0-bffb9780f89f@cs.pub.ro> From: Vladimir Olteanu Message-ID: Date: Tue, 11 Jul 2017 02:19:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2ED8F6937392F404F95911F9" Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:19:38 -0000 This is a multi-part message in MIME format. --------------2ED8F6937392F404F95911F9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Yoshi, As a response to question 2, the client can send some initial data as=20 part of the request. It does have to wait for a reply to send any more=20 data, though. As such, the client can get a data response from the=20 server in 1 RTT, same as when contacting the server directly with TFO, if= : * Everyone uses TFO (otherwise, RTTs are incurred only on the segments=20 where TFO is not available). * Authentication is not required, or 0-RTT authentication succeeds.=20 (Otherwise, some extra RTTs are incurred, same as above.) If nobody uses TFO, but authentication is not an issue (either it's not=20 needed or done in 0 RTTs), then SOCKS 6 does no worse than regular TCP=20 (2 RTTs for a data response). As for the use case, there are two possible ways in which it can be handl= ed: * The client knows about both proxies. * The client knows only about proxy1, but proxy1 is configured to go=20 via proxy2 when contacting the server. Assuming the client knows about both of them, it can speak SOCKS 6 over=20 SOCKS 6. The relevant messages are: C->P1 request(P2, auth data 1, initial data(request(S, auth data 2,=20 initial data(application data)))) P1->P2 request(S, auth data 2, initial data(application data)) P2->S application data If proxy1 is configured to use proxy2: C->P1 request(S, auth data 1, initial data(application data)) P1->P2 request(S, auth data 2, initial data(application data)) P2->S application data Cheers, Vlad On 07/10/2017 10:00 AM, Yoshifumi Nishida wrote: > Hi Vlad and Dragos, > > I really appreciate you for preparing the draft and brought it to here. > As you might know, we have been exploring solutions for proxying mptcp=20 > sessions. > We've had lots of discussions on plain mode and other solutions, but=20 > because we didn't have concrete proposals other than plain mode, it=20 > was difficult to compare the pros and the cons properly. But, now I=20 > believe we have a good chance to advance this. > > BTW, as I'm curious about this approach to use with mptcp, I have some=20 > questions for a certain scenario. In the WG, one use case we discuss=20 > is using two proxies like below. > > client ---- proxy1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pr= oxy2 ---- server > > In this scenario, we presume using TCP for client-proxy1 and=20 > proxy2-server, while using mptcp for proxy1-proxy2. > The draft says it supports TFO, but I still think it takes some RTTs=20 > with approach although I miss something. It would be great if you=20 > could clarify the following points. > > 1: How will the connection between proxy1 and proxy2 set up? Does=20 > proxy1 need to negotiate proxy2 for authentication, etc? If so, it=20 > might add another delays before clients can send data. > > 2: Do clients need to wait a response for CONNECT request? If not, how=20 > it handles an error case? > > Thanks, > -- > Yoshi > > > On Thu, Jun 29, 2017 at 5:02 AM, Vladimir Olteanu=20 > > wrote: > > Hello, > > We have submitted a draft describing a new version of the SOCKS > protocol, which could help in the deployment of MPTCP. You can > find the abstract and a link to the draft below. > > Best, > Vlad and Drago=C8=99 > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-olteanu-intarea-socks-6-00.txt > Date: Wed, 28 Jun 2017 22:01:16 -0700 > From: internet-drafts@ietf.org > To: Vladimir Olteanu > , Dragos Niculescu > > > > > A new version of I-D, draft-olteanu-intarea-socks-6-00.txt > has been successfully submitted by Vladimir Olteanu and posted to t= he > IETF repository. > > Name: draft-olteanu-intarea-socks-6 > Revision: 00 > Title: SOCKS Protocol Version 6 > Document date: 2017-06-28 > Group: Individual Submission > Pages: 12 > URL:https://www.ietf.org/internet-drafts/draft-olteanu-intarea-sock= s-6-00.txt > > Status:https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks= -6/ > > Htmlized:https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-= 00 > > Htmlized:https://datatracker.ietf.org/doc/html/draft-olteanu-intare= a-socks-6-00 > > > > Abstract: > The SOCKS protocol is used primarily to proxy TCP connections t= o > arbitrary destinations via the use of a proxy server. Under th= e > latest version of the protocol (version 5), it takes 2 RTTs (or= 3, if > authentication is used) before data can flow between the client= and > the server. > > This memo proposes SOCKS version 6, which reduces the number of= RTTs > used, takes full advantage of TCP Fast Open, and adds support f= or > 0-RTT authentication. > > = =20 > > > Please note that it may take a couple of minutes from the time of s= ubmission > until the htmlized version and diff are available attools.ietf.org = . > > The IETF Secretariat > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > > --------------2ED8F6937392F404F95911F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Yoshi,

As a response to question 2, the client can send some initial data as part of the request. It does have to wait for a reply to send any more data, though. As such, the client can get a data response from the server in 1 RTT, same as when contacting the server directly with TFO, if:
=C2=A0* Everyone uses TFO (otherwise, RTTs are incurred only on the segments where TFO is not available).
=C2=A0* Authentication is not required, or 0-RTT authentication succe= eds. (Otherwise, some extra RTTs are incurred, same as above.)

If nobody uses TFO, but authentication is not an issue (either it's not needed or done in 0 RTTs), then SOCKS 6 does no worse than regular TCP (2 RTTs for a data response).

As for the use case, there are two possible ways in which it can be handled:
=C2=A0* The client knows about both proxies.
=C2=A0* The client knows only about proxy1, but proxy1 is configured = to go via proxy2 when contacting the server.

Assuming the client knows about both of them, it can speak SOCKS 6 over SOCKS 6. The relevant messages are:
C->P1 request(P2, auth data 1, initial data(request(S, auth data 2, initial data(application data))))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data

If proxy1 is configured to use proxy2:
C->P1 request(S, auth data 1, initial data(application data))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data

Cheers,
Vlad

On 07/10/2017 10:00 AM, Yoshifumi Nishida wrote:
Hi Vlad and Dragos,

I really appreciate you for preparing the draft and brought it to here.
As you might know, we have been exploring solutions for proxying mptcp sessions.=C2=A0
We've had lots of discussions on plain mode and other solutions, but because we didn't have concrete proposals other than plain mode, it was difficult to compare the pros and the cons properly. But, now I believe we have a good chance to advance this.=C2=A0

BTW, as I'm curious about this approach to use with mptcp, I have some questions for a certain scenario. In the WG, one use case we discuss is using two proxies like below.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client ---- proxy1 =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D proxy2 ---- server

In this scenario, we presume using TCP for client-proxy1 and proxy2-server, while using mptcp for proxy1-proxy2.=C2=A0
The draft says it supports TFO, but I still think it takes some RTTs with approach although I miss something. It would be great if you could clarify the following points.=C2=A0

1: =C2=A0How will the connection between proxy1 and proxy2 s= et up? Does proxy1 need to negotiate proxy2 for authentication, etc? If so, it might add another delays before clients can send data.

2: Do clients need to wait a response for CONNECT request? If not, how it handles an error case?

Thanks,
--
Yoshi


On Thu, Jun 29, 2017 at 5:02 AM, Vladimir Olteanu <vladimir.olt= eanu@cs.pub.ro> wrote:

Hello,

We have submitted a draft describing a new version of the SOCKS protocol, which could help in the deployment of MPTCP. You can find the abstract and a link to the draft below.

Best,
Vlad and Drago=C8=99



-------- Forwarded Message --------
Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
Date: Wed, 28 Jun 2017 22:01:16 -0700
From: = internet-drafts@ietf.org
To: Vladimir Olteanu = <vladimir.olteanu@cs.pub.ro>, Dragos Niculescu = <dragos.niculescu@cs.pub.ro> 


A new version of I-D, draft-olteanu-intarea-sock=
s-6-00.txt
has been successfully submitted by Vladimir Olteanu and posted to the
IETF repository.

Name:		draft-olteanu-intarea-socks-6
Revision:	00
Title:		SOCKS Protocol Version 6
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/dr=
aft-olteanu-intarea-socks-6-00.txt
Status:         https://datatracker.ietf.org/doc/draft-olteanu-in=
tarea-socks-6/
Htmlized:       https://tools.ietf.org/html/draft-olteanu-intarea-so=
cks-6-00
Htmlized:       https://datatracker.ietf.org/doc/html/draf=
t-olteanu-intarea-socks-6-00


Abstract:
   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/l= istinfo/multipathtcp



--------------2ED8F6937392F404F95911F9-- From nobody Wed Jul 12 00:51:51 2017 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 E3163131468 for ; Wed, 12 Jul 2017 00:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 kSONR5xdMgjL for ; Wed, 12 Jul 2017 00:51:48 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A074131447 for ; Wed, 12 Jul 2017 00:51:47 -0700 (PDT) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C109127850D for ; Wed, 12 Jul 2017 16:51:45 +0900 (JST) Received: by mail-lf0-f50.google.com with SMTP id t72so8797777lff.1 for ; Wed, 12 Jul 2017 00:51:45 -0700 (PDT) X-Gm-Message-State: AIVw110Pi4E2wgz9GMBWjTJkJznMjQceCthxJSJiVHuzJHZSGlRxaozt rkPwvoWBcs+EUS5DKWmczi0bHJZmsw== X-Received: by 10.25.150.148 with SMTP id y142mr1335726lfd.180.1499845903542; Wed, 12 Jul 2017 00:51:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.35.87 with HTTP; Wed, 12 Jul 2017 00:51:42 -0700 (PDT) In-Reply-To: References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <96151c77-fd31-f6ca-dca0-bffb9780f89f@cs.pub.ro> From: Yoshifumi Nishida Date: Wed, 12 Jul 2017 00:51:42 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Vladimir Olteanu Cc: Yoshifumi Nishida , multipathtcp , =?UTF-8?Q?Drago=C8=99_Niculescu?= Content-Type: multipart/alternative; boundary="001a114022384c723705541a16a6" Archived-At: Subject: Re: [multipathtcp] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 07:51:50 -0000 --001a114022384c723705541a16a6 Content-Type: text/plain; charset="UTF-8" Hi Vlad, Thanks for the response. On Mon, Jul 10, 2017 at 4:19 PM, Vladimir Olteanu < vladimir.olteanu@cs.pub.ro> wrote: > Hi Yoshi, > > As a response to question 2, the client can send some initial data as part > of the request. It does have to wait for a reply to send any more data, > though. As such, the client can get a data response from the server in 1 > RTT, same as when contacting the server directly with TFO, if: > * Everyone uses TFO (otherwise, RTTs are incurred only on the segments > where TFO is not available). > * Authentication is not required, or 0-RTT authentication succeeds. > (Otherwise, some extra RTTs are incurred, same as above.) > > If nobody uses TFO, but authentication is not an issue (either it's not > needed or done in 0 RTTs), then SOCKS 6 does no worse than regular TCP (2 > RTTs for a data response). > > As for the use case, there are two possible ways in which it can be > handled: > * The client knows about both proxies. > * The client knows only about proxy1, but proxy1 is configured to go via > proxy2 when contacting the server. > > Assuming the client knows about both of them, it can speak SOCKS 6 over > SOCKS 6. The relevant messages are: > C->P1 request(P2, auth data 1, initial data(request(S, auth data 2, > initial data(application data)))) > P1->P2 request(S, auth data 2, initial data(application data)) > P2->S application data > > If proxy1 is configured to use proxy2: > C->P1 request(S, auth data 1, initial data(application data)) > P1->P2 request(S, auth data 2, initial data(application data)) > P2->S application data > > Thanks for the clarification. So, in both cases, if C piggy-backs all requests (authentication, connect, etc if any) and application data in SYN payload with TFO, P1 can forward it as soon as it receives and P2 can do the same thing? (We might presume no authentication or 0-rtt authentication here, though.) -- Yoshi --001a114022384c723705541a16a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vlad,

Thanks for the response.

On Mon, Jul 10, 201= 7 at 4:19 PM, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>= ; wrote:
=20 =20 =20
Hi Yoshi,

As a response to question 2, the client can send some initial data as part of the request. It does have to wait for a reply to send any more data, though. As such, the client can get a data response from the server in 1 RTT, same as when contacting the server directly with TFO, if:
=C2=A0* Everyone uses TFO (otherwise, RTTs are incurred only on the segments where TFO is not available).
=C2=A0* Authentication is not required, or 0-RTT authentication succeed= s. (Otherwise, some extra RTTs are incurred, same as above.)

If nobody uses TFO, but authentication is not an issue (either it's not needed or done in 0 RTTs), then SOCKS 6 does no worse than regular TCP (2 RTTs for a data response).

As for the use case, there are two possible ways in which it can be handled:
=C2=A0* The client knows about both proxies.
=C2=A0* The client knows only about proxy1, but proxy1 is configured to go via proxy2 when contacting the server.=C2=A0

Assuming the client knows about both of them, it can speak SOCKS 6 over SOCKS 6. The relevant messages are:
C->P1 request(P2, auth data 1, initial data(request(S, auth data 2, initial data(application data))))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data

If proxy1 is configured to use proxy2:
C->P1 request(S, auth data 1, initial data(application data))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data


Thanks for the clarification.
So, in both cases, if C piggy-backs all requests (authentication, connect,= etc if any) and application data in SYN payload with TFO, P1 can forward i= t as soon as it receives and P2 can do the same thing? (We might presume no= authentication or 0-rtt authentication here, though.)
--
Yoshi

--001a114022384c723705541a16a6-- From nobody Wed Jul 12 07:15:35 2017 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 292EE1316C9 for ; Wed, 12 Jul 2017 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GfZ77QpZ1Q1Z for ; Wed, 12 Jul 2017 07:15:30 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7D01316A8 for ; Wed, 12 Jul 2017 07:15:29 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AhNolpRfLqj9OUakgSQ9GrdORlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcSzYR7h7PlgxGXEQZ/co6odzbGH7Oa4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Y75+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hy?= =?us-ascii?q?gbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTzFPDJ2y?= =?us-ascii?q?b4UPDOQPM+hXoIb/qFQSthaxHxWgCfn1xzNUiHL736s32PkhHwHc2wwgGsoDv3?= =?us-ascii?q?vQrNrvKagSUOW1zKjSzT7edv1W3Sv955bSfRAnvPGHQLV9cdTVyUY1CgzFj1CQ?= =?us-ascii?q?qY3/Pz+P0eQNt3Sb4PR6WuKplm4qsB1+oiO1ysc0l4nGnZgZykrD9Shgxos+ON?= =?us-ascii?q?62SFZjbNK5H5ZcqjuWOoh2T884XW1kpiQ3xqcItJKjYSQHx4krywTcZvGHaYSE?= =?us-ascii?q?/BzuWeiLLTtli39pZrSyjAuo/0e60O3zTMy03U5PripCj9bDqGgA1wfW6sibUv?= =?us-ascii?q?t9+Vqh2SqX2wDT9O5EJUc0mLLFK54k2LEwl54TvV7fES/tgkn2lLKWeV4+9uiy?= =?us-ascii?q?7OTrerTmppmCOI9okgzyL6sjltGlDek7MgUCRXaX9fq+2bH580D1WLBKgec3kq?= =?us-ascii?q?ndvpDaP8MbpquhDg9L1oYs8QuwDzaj0NQZh3kLNlVFeBabj4f3IV7OJu34AOyj?= =?us-ascii?q?jFS3ijtr3+3GMab7DpXXKXjPiK3hcqpl605A1AozyshS55dJCrEFPPLzW1fxu8?= =?us-ascii?q?bEDh85Lwy73/7nBc581owARWKPDLWVMKTIsV+H/ugvOfWDZJcJuDbhLPgo//ju?= =?us-ascii?q?jX4imV8dfKmmwIEYZWujHvRoP0qVe3TtgtYcHmgUpAYxVvHlhEeAUT5LND6OWP?= =?us-ascii?q?cN4So7CYy7CIaLYIG2gL2N1W/vGJxNZmFKA3iXH3yuaISIVrEFZGSQOpkyvCYD?= =?us-ascii?q?UO2fT4Yt1BSvrkfdz6ZqJ+zJsnkGsZvv1d10/avUkQ0//DppJ8+GlXmQRSdumT?= =?us-ascii?q?VbFHcNwKljrBklmR+42q9ijqkdTIQL6g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DHAgClLmZZjAPjVY1cHAEBBAEBCgEBF?= =?us-ascii?q?gEBAQMBAQEJAQEBhBaBEY58kH2YFIV2AoQlAQEBAQEBAQECARIBAQEmV4IzJAG?= =?us-ascii?q?CQQECAyMEUhALGCcDAgJGEQYNBgIBAYovrRaBbDoninsBAQEBBgEBAQEBI4Mog?= =?us-ascii?q?02CDIJ5hFSDKYJhBZFZhWOHbIIjnRKGf5VPAlaBCzEhhiSBdnOIWQEBAQ?= X-IPAS-Result: =?us-ascii?q?A2DHAgClLmZZjAPjVY1cHAEBBAEBCgEBFgEBAQMBAQEJAQE?= =?us-ascii?q?BhBaBEY58kH2YFIV2AoQlAQEBAQEBAQECARIBAQEmV4IzJAGCQQECAyMEUhALG?= =?us-ascii?q?CcDAgJGEQYNBgIBAYovrRaBbDoninsBAQEBBgEBAQEBI4Mog02CDIJ5hFSDKYJ?= =?us-ascii?q?hBZFZhWOHbIIjnRKGf5VPAlaBCzEhhiSBdnOIWQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,350,1496091600"; d="scan'208,217";a="889253" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 12 Jul 2017 17:15:28 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id E86A91A60148; Wed, 12 Jul 2017 17:15:27 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fcJ6Yyc8O-pG; Wed, 12 Jul 2017 17:15:27 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id CACAE1A601AC; Wed, 12 Jul 2017 17:15:27 +0300 (EEST) Received: from [172.19.2.57] (unknown [141.85.233.142]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id C5A131A60148; Wed, 12 Jul 2017 17:15:27 +0300 (EEST) To: Yoshifumi Nishida Cc: multipathtcp , =?UTF-8?Q?Drago=c8=99_Niculescu?= References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <96151c77-fd31-f6ca-dca0-bffb9780f89f@cs.pub.ro> From: Vladimir Olteanu Message-ID: Date: Wed, 12 Jul 2017 17:15:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E62651342DCE0CA702E6CC88" Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 14:15:34 -0000 This is a multi-part message in MIME format. --------------E62651342DCE0CA702E6CC88 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Yoshi, On 07/12/2017 10:51 AM, Yoshifumi Nishida wrote: > Hi Vlad, > > Thanks for the response. > > On Mon, Jul 10, 2017 at 4:19 PM, Vladimir Olteanu > > wrote: > > Hi Yoshi, > > As a response to question 2, the client can send some initial data > as part of the request. It does have to wait for a reply to send > any more data, though. As such, the client can get a data response > from the server in 1 RTT, same as when contacting the server > directly with TFO, if: > * Everyone uses TFO (otherwise, RTTs are incurred only on the > segments where TFO is not available). > * Authentication is not required, or 0-RTT authentication > succeeds. (Otherwise, some extra RTTs are incurred, same as above.) > > > If nobody uses TFO, but authentication is not an issue (either > it's not needed or done in 0 RTTs), then SOCKS 6 does no worse > than regular TCP (2 RTTs for a data response). > > As for the use case, there are two possible ways in which it can > be handled: > * The client knows about both proxies. > * The client knows only about proxy1, but proxy1 is configured to > go via proxy2 when contacting the server. > > > Assuming the client knows about both of them, it can speak SOCKS 6 > over SOCKS 6. The relevant messages are: > C->P1 request(P2, auth data 1, initial data(request(S, auth data > 2, initial data(application data)))) > P1->P2 request(S, auth data 2, initial data(application data)) > P2->S application data > > If proxy1 is configured to use proxy2: > C->P1 request(S, auth data 1, initial data(application data)) > P1->P2 request(S, auth data 2, initial data(application data)) > P2->S application data > > > Thanks for the clarification. > So, in both cases, if C piggy-backs all requests (authentication, > connect, etc if any) and application data in SYN payload with TFO, P1 > can forward it as soon as it receives and P2 can do the same thing? > (We might presume no authentication or 0-rtt authentication here, though.) > Yes, that is the case. Vlad --------------E62651342DCE0CA702E6CC88 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Yoshi,


On 07/12/2017 10:51 AM, Yoshifumi Nishida wrote:
Hi Vlad,

Thanks for the response.

On Mon, Jul 10, 2017 at 4:19 PM, Vladimir Olteanu <vladimir.olt= eanu@cs.pub.ro> wrote:
Hi Yoshi,

As a response to question 2, the client can send some initial data as part of the request. It does have to wait for a reply to send any more data, though. As such, the client can get a data response from the server in 1 RTT, same as when contacting the server directly with TFO, if:
=C2=A0* Everyone uses TFO (otherwise, RTTs are incurred only on the segments where TFO is not available).
=C2=A0* Authentication is not required, or 0-RTT authentication succeeds. (Otherwise, some extra RTTs are incurred, same as above.)

If nobody uses TFO, but authentication is not an issue (either it's not needed or done in 0 RTTs), then SOCKS 6 does no worse than regular TCP (2 RTTs for a data response).

As for the use case, there are two possible ways in which it can be handled:
=C2=A0* The client knows about both proxies.
=C2=A0* The client knows only about proxy1, but proxy1 = is configured to go via proxy2 when contacting the server.=C2=A0

Assuming the client knows about both of them, it can speak SOCKS 6 over SOCKS 6. The relevant messages are:<= br> C->P1 request(P2, auth data 1, initial data(request(S, auth data 2, initial data(application data))))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data

If proxy1 is configured to use proxy2:
C->P1 request(S, auth data 1, initial data(application data))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data


Thanks for the clarification.
So, in both cases, if C piggy-backs all requests (authentication, connect, etc if any) and application data in SYN payload with TFO, P1 can forward it as soon as it receives and P2 can do the same thing? (We might presume no authentication or 0-rtt authentication here, though.)

Yes, that is the case.

Vlad
--------------E62651342DCE0CA702E6CC88-- From nobody Wed Jul 12 14:17:39 2017 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 B8B001317B6 for ; Wed, 12 Jul 2017 14:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 T1RgEGmUtPZS for ; Wed, 12 Jul 2017 14:17:33 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4B612EC41 for ; Wed, 12 Jul 2017 14:17:33 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 85E8F67DD15; Wed, 12 Jul 2017 23:17:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp6.sgsi.ucl.ac.be 85E8F67DD15 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1499894243; bh=gJRzZn56rBpcjzfCf0w4IdB1qQ4OY7YwW18AinHorKc=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=q8kpRTmwaX5AxYHWz82+DECJgqMP53H15eX9FGeL9Y+5zRwFbqICIBL1q1ONb3wg/ t5fI/MaqwV8j0ifzHnqnE4MU19BKINGdugCLNOClEaL014fk1ZZji0fy0oAkiwDIL4 26Z42IQi9SFApfxEB92GIqVWoBTzoX9dC/5Crb60= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-6 Reply-To: Olivier.Bonaventure@uclouvain.be To: Markus.Amend@telekom.de, multipathtcp@ietf.org References: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> From: Olivier Bonaventure Message-ID: Date: Wed, 12 Jul 2017 21:48:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 85E8F67DD15.A5B5C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:17:38 -0000 Markus, The problem that you raise is very similar to the HappyEyeBalls solutions that is used by web browsers on dual-stack hosts. The final goal is to make sure that applications can connect quickly to a destination when there are two paths available and one of them is bad. I think that there are two ways to solve this problem : 1. Enhance MPTCP so that MPTCP can support this use case without requiring any modification to the applications 2. Enhance the applications without adding complexity to MPTCP Concerning the first approach, I guess that you solution is to let the server parse through all the received SYN with a given key to check whether this is a dual connection establishment or a regular connection establishment. The limitation of this approach is that server needs to lookup all the keys of the received SYNs (possibly during a given period of time as you mention in your email) everytime it receives a SYN. This increases the SYN processing time on servers and thus the risk of denial of service attacks. It would be interesting to see how your implementation copes with this issue. Note that it requires the presence of a key inside the SYN (as defined in RFC6824). This implies that this is not compatible with RFC6824bis. The second approach has been used successfully with HappyEyeBalls by web browers. It could be integrated in any library or higher level programming language by simply trying to open separate MPTCP connections and reset that one that connects slowly. A kernel implementation could probably also include code to support these parallel establishments of MPTCP connections. This would allow all applications to benefit from this feature, even those that use the C socket API directly. The main benefit of the second approach is that the client is in control. It can delay the transmission of the second SYN as in HappyEyeBalls to avoid doubling unnecessarily the number of SYNs that a server has to process. Since the client is less loaded than the server, it is less an issue to put some complexity (e.g. timers, remembering the best interface, ...) on the client side. If you travel to Prague, I'd be happy to discuss with you. We'll also participate to the hackathon on Sunday if you'd like to discuss about your implementation. Best regards, Olivier From nobody Wed Jul 12 20:32:58 2017 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 51C5012700F for ; Wed, 12 Jul 2017 20:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zSnq0HGbXGXC for ; Wed, 12 Jul 2017 20:32:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA9C120725 for ; Wed, 12 Jul 2017 20:32:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQZ94716; Thu, 13 Jul 2017 03:32:52 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Jul 2017 04:32:50 +0100 Received: from DGGEMM508-MBX.china.huawei.com ([169.254.2.19]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Thu, 13 Jul 2017 11:32:43 +0800 From: "Zuojing (2012 Laboratories)" To: "Olivier.Bonaventure@uclouvain.be" , "Markus.Amend@telekom.de" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) Thread-Index: AdL5l2p+5KDR4ahqRJeh9onNd2ThSgBbU6KAAB/B3eA= Date: Thu, 13 Jul 2017 03:32:42 +0000 Message-ID: <4AD902A48032F745A3D7866E6CAE8CB0655C9CCB@dggemm508-mbx.china.huawei.com> References: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.163.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5966E9E4.0085, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.19, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 28985a4584a51e357fa1214f5dcb7b44 Archived-At: Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 03:32:56 -0000 Hi, Olivier and Markus, I meet the same problem that the connection establishment fails due to weak= WiFi signal although LTE is good. The HappyEyeBalls is a good solution that we do not need modify the MPTCP. = However, it requires the enhancement of the applications, as you mentioned.= =20 How about if the application does not support the enhancement, since we can= 't control the design of applications?=20 I am considering that we may modify the MPTCP, e.g., let the MPTCP stack op= en two separate connections with indicated network IP addresses instead of = the applications do. Moreover, this solution does not increase as much comp= lexity as 'Duplicate SYN' does. Instead, the duplicate SYNs are sent to bui= ld two separate MPTCP connections without modifying the process of MPTCP co= nnection establishment. How do you think? Kind regards, Jing =20 > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > Olivier Bonaventure > Sent: Thursday, July 13, 2017 3:48 AM > To: Markus.Amend@telekom.de; multipathtcp@ietf.org > Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establish= ment > (MPTCP RobE) >=20 > Markus, >=20 > The problem that you raise is very similar to the HappyEyeBalls solutions= that is > used by web browsers on dual-stack hosts. The final goal is to make sure = that > applications can connect quickly to a destination when there are two path= s > available and one of them is bad. >=20 > I think that there are two ways to solve this problem : >=20 > 1. Enhance MPTCP so that MPTCP can support this use case without requirin= g > any modification to the applications >=20 > 2. Enhance the applications without adding complexity to MPTCP >=20 > Concerning the first approach, I guess that you solution is to let the se= rver parse > through all the received SYN with a given key to check whether this is a = dual > connection establishment or a regular connection establishment. The limit= ation > of this approach is that server needs to lookup all the keys of the recei= ved SYNs > (possibly during a given period of time as you mention in your email) eve= rytime > it receives a SYN. This increases the SYN processing time on servers and = thus the > risk of denial of service attacks. It would be interesting to see how you= r > implementation copes with this issue. Note that it requires the presence = of a > key inside the SYN (as defined in RFC6824). This implies that this is not > compatible with RFC6824bis. >=20 > The second approach has been used successfully with HappyEyeBalls by web > browers. It could be integrated in any library or higher level programmin= g > language by simply trying to open separate MPTCP connections and reset th= at > one that connects slowly. A kernel implementation could probably also inc= lude > code to support these parallel establishments of MPTCP connections. This > would allow all applications to benefit from this feature, even those tha= t use > the C socket API directly. >=20 > The main benefit of the second approach is that the client is in control.= It can > delay the transmission of the second SYN as in HappyEyeBalls to avoid dou= bling > unnecessarily the number of SYNs that a server has to process. Since the = client > is less loaded than the server, it is less an issue to put some complexit= y (e.g. > timers, remembering the best interface, ...) on the client side. >=20 > If you travel to Prague, I'd be happy to discuss with you. We'll also par= ticipate to > the hackathon on Sunday if you'd like to discuss about your implementatio= n. >=20 > Best regards, >=20 >=20 > Olivier >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jul 13 00:03:45 2017 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 6963E12EC19 for ; Thu, 13 Jul 2017 00:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 ztT2DjwlV0tV for ; Thu, 13 Jul 2017 00:03:41 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F356129B29 for ; Thu, 13 Jul 2017 00:03:41 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 734B867DC4E; Thu, 13 Jul 2017 09:03:27 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 734B867DC4E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1499929408; bh=KJ3UpriSYkcKiLnZyJD1o6qiDaaJ74WZKkSXRM0zOik=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=LHr0Jh6i1FcJeCEvbbOsvwcXWHcUaLmDVf3JRlgJ4qArZrrK8mCmr0m4TBmKStyU2 qW5n1kQNQl9sWlwneb2ba3vX1RYVZ7XumVo4JRuExk0E6F/um9fsL11nV8rG5p6zs+ iSnY7PhDwr8D6TPx1P2xCfXAGS+aZ+GRYOuMeDts= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2 Reply-To: Olivier.Bonaventure@uclouvain.be To: "Zuojing (2012 Laboratories)" , "Markus.Amend@telekom.de" , "multipathtcp@ietf.org" References: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> <4AD902A48032F745A3D7866E6CAE8CB0655C9CCB@dggemm508-mbx.china.huawei.com> From: Olivier Bonaventure Message-ID: Date: Thu, 13 Jul 2017 09:03:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4AD902A48032F745A3D7866E6CAE8CB0655C9CCB@dggemm508-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 734B867DC4E.A5F97 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 07:03:43 -0000 Jing, > > I meet the same problem that the connection establishment fails due to weak WiFi signal although LTE is good. > The HappyEyeBalls is a good solution that we do not need modify the MPTCP. However, it requires the enhancement of the applications, as you mentioned. On smartphones, most applications use a library that manages the underlying socket. By changing this library, you can enable most applications to benefit from the change. > How about if the application does not support the enhancement, since we can't control the design of applications? > I am considering that we may modify the MPTCP, e.g., let the MPTCP stack open two separate connections with indicated network IP addresses instead of the applications do. Moreover, this solution does not increase as much complexity as 'Duplicate SYN' does. Instead, the duplicate SYNs are sent to build two separate MPTCP connections without modifying the process of MPTCP connection establishment. How do you think? It should be possible to change the implementation of the connect system call so that instead of selecting one source IP address and trying to create one connection it tries to create two MPTCP connections, typically one immediately with the default interface and the other one later after some timeout and then returns the first established connection and discards the other one (i.e. sends a RST upon reception of the SYN+ACK for the second). Olivier From nobody Thu Jul 13 04:48:10 2017 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 1980A131461 for ; Thu, 13 Jul 2017 04:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 CLMDk0--vn1e for ; Thu, 13 Jul 2017 04:48:06 -0700 (PDT) Received: from MAILOUT31.telekom.de (MAILOUT31.telekom.de [80.149.113.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2579E12ECEF for ; Thu, 13 Jul 2017 04:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1499946486; x=1531482486; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DXzt3Exj3Il5JiP0qsd5Tn6zCVZXJURkbPHUSgGw/C0=; b=hlnDUVotOOtOplJFR0CdIWpk/9CaSepNYK68y4P16Npi7GBZ0e/h5sdN GEWuilwF4WJwp0hskaOn2il24Vj7L1ma0Viy6MHRo1EM3IgsV5LkYm1+7 P73osCM2U9uP6hWJfJZJO4LNlV24EzqSW1Le6jEOndRGONramS0wRUMAc 6a6VssKJw+Rsb2o7h9ibPjc13FVy1YPGmjPhNS8+pX+s41vatQrkFfne5 qe412MTAHiA39ZMYbOnE9GGkKNbXMDTynF+n68PEOdWaHlnaD1CLhekpT BAcII4Miy9p5HK1qtJfTayArpJDysIfEjOTnXz5EAlTxXPndh2FSrFtv/ Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2017 13:48:01 +0200 X-IronPort-AV: E=Sophos;i="5.40,353,1496095200"; d="scan'208";a="40726866" Received: from he105686.emea1.cds.t-internal.com ([10.169.119.48]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 13 Jul 2017 13:48:01 +0200 Received: from HE105686.EMEA1.cds.t-internal.com (10.169.119.48) by HE105686.emea1.cds.t-internal.com (10.169.119.48) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Jul 2017 13:48:00 +0200 Received: from HE105686.EMEA1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9]) by HE105686.emea1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9%26]) with mapi id 15.00.1263.000; Thu, 13 Jul 2017 13:48:00 +0200 From: To: Thread-Topic: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) Thread-Index: AdL5l2p+5KDR4ahqRJeh9onNd2ThSgBn5kmAACWZiyA= Date: Thu, 13 Jul 2017 11:48:00 +0000 Message-ID: <79ac6cb307784db3a6d8ae1550a49573@HE105686.emea1.cds.t-internal.com> References: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.30.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 11:48:09 -0000 DQpIaSBPbGl2aWVyLA0KDQp0aGFua3MgZm9yIHlvdXIgZmVlZGJhY2ssIHNlZSBpbmxpbmUuLi4N Cg0KQlINCg0KTWFya3VzIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IE9saXZpZXIgQm9uYXZlbnR1cmUgW21haWx0bzpPbGl2aWVyLkJvbmF2ZW50dXJlQHVjbG91dmFp bi5iZV0NCj4gU2VudDogTWl0dHdvY2gsIDEyLiBKdWxpIDIwMTcgMjE6NDgNCj4gVG86IEFtZW5k LCBNYXJrdXMgPE1hcmt1cy5BbWVuZEB0ZWxla29tLmRlPjsgbXVsdGlwYXRodGNwQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbbXVsdGlwYXRodGNwXSBBIHByb3Bvc2FsIGZvciBNUFRDUCBSb2J1 c3Qgc2Vzc2lvbiANCj4gRXN0YWJsaXNobWVudCAoTVBUQ1AgUm9iRSkNCj4gDQo+IE1hcmt1cywN Cj4gDQo+IFRoZSBwcm9ibGVtIHRoYXQgeW91IHJhaXNlIGlzIHZlcnkgc2ltaWxhciB0byB0aGUg SGFwcHlFeWVCYWxscyANCj4gc29sdXRpb25zIHRoYXQgaXMgdXNlZCBieSB3ZWIgYnJvd3NlcnMg b24gZHVhbC1zdGFjayBob3N0cy4gVGhlIGZpbmFsIA0KPiBnb2FsIGlzIHRvIG1ha2Ugc3VyZSB0 aGF0IGFwcGxpY2F0aW9ucyBjYW4gY29ubmVjdCBxdWlja2x5IHRvIGEgDQo+IGRlc3RpbmF0aW9u IHdoZW4gdGhlcmUgYXJlIHR3byBwYXRocyBhdmFpbGFibGUgYW5kIG9uZSBvZiB0aGVtIGlzIGJh ZC4NCj4gDQo+IEkgdGhpbmsgdGhhdCB0aGVyZSBhcmUgdHdvIHdheXMgdG8gc29sdmUgdGhpcyBw cm9ibGVtIDoNCj4gDQo+IDEuIEVuaGFuY2UgTVBUQ1Agc28gdGhhdCBNUFRDUCBjYW4gc3VwcG9y dCB0aGlzIHVzZSBjYXNlIHdpdGhvdXQgDQo+IHJlcXVpcmluZyBhbnkgbW9kaWZpY2F0aW9uIHRv IHRoZSBhcHBsaWNhdGlvbnMNCg0KVGhhdCBpcyBleGFjdGx5IHdoYXQgd2UgYWltIHRvLCBiZWNh dXNlIG9mIGFwcGxpY2F0aW9uIHRyYW5zcGFyZW5jeS4gTVBUQ1AgaXMgYSB3b25kZXJmdWwgcHJv dG9jb2wgd2hpY2ggZXh0ZW5kcyBUQ1BzIHNpbmdsZSBwYXRoIGxpbWl0YXRpb24gdG8gbXVsdGlw YXRoIHN1cHBvcnQuIEJ1dCBhZ2FpbiwgbGlrZSB0aGUgVENQIGl0IHRyaWVzIHRvIGltcHJvdmUg aW4gcmVzcGVjdCB0byBtdWx0aXBhdGggc3VwcG9ydCwgaXQgZGVwZW5kcyBkdXJpbmcgc2Vzc2lv bnMgZXN0YWJsaXNobWVudCBmcm9tIGEgc2luZ2xlIHBhdGguIFdlIHNlZSB0aGUgY2hhbmNlIHRv IG1ha2UgTVBUQ1AgYm90aCByb2J1c3QgYWdhaW5zdCBkZWZhdWx0IHJvdXRlIGJsb2NraW5nIGFu ZCBhdCB0aGUgc2FtZSB0aW1lIHJlZHVjZSBlc3RhYmxpc2htZW50IGxhdGVuY3kgdG8gdGhlIGZh c3Rlc3QgcGF0aCBpbiBnYW1lLiBUaGlzIGlkZWEgb2Ygcm9idXN0bmVzcyBhbmQgYWNjZWxlcmF0 aW9uIGlzIGltcGxlbWVudGVkIGluIG91ciAiRG93bmdyYWRlIiBwcm9wb3NhbCwgd2l0aG91dCBh bnkgbmV0d29yayBvdmVyaGVhZCwgYnV0IG9idmlvdXNseSBhIHByb3Bvc2FsIHdpdGggaGlnaGVy IGNvbXBsZXhpdHkuIEVzcGVjaWFsbHkgY29tcGFyZWQgdG8gYW4gYXBwcm9hY2ggd2hpY2ggb25s eSB0cmllcyB0byBzb2x2ZSByb2J1c3RuZXNzIGNoYWxsZW5nZS4NCg0KPiANCj4gMi4gRW5oYW5j ZSB0aGUgYXBwbGljYXRpb25zIHdpdGhvdXQgYWRkaW5nIGNvbXBsZXhpdHkgdG8gTVBUQ1ANCj4g DQoNCllvdSBhcmUgYWJzb2x1dGVseSByaWdodCB0byByYWlzZSB0aGlzIG9wdGlvbiwgd2hpY2gg d2FzIG5ldmVyIGluIGZvY3VzIG9mIHVzLCBiZWNhdXNlIHdlIHRoaW5rL3Rob3VnaHQgaXQgc2hv dWxkIGJlIGEgTVBUQ1AgaW5oZXJlbnQgY2FwYWJpbGl0eSwgc2VlIGFib3ZlLiBCdXQgd2h5IG5v dC4uLg0KQXQgdGhlIGVuZCBpdCBuZWVkcyBzcGVjaWFsIHRyZWF0bWVudCBmcm9tIGFwcGxpY2F0 aW9uIGRldmVsb3BlcnMsIHdoZXJlIEkgZXZlciB0aG91Z2h0LCB0aGF0IE1QVENQIGZvY3VzIGlz IHRvIGJlIGFwcGxpY2F0aW9uIHRyYW5zcGFyZW50Lg0KDQo+IENvbmNlcm5pbmcgdGhlIGZpcnN0 IGFwcHJvYWNoLCBJIGd1ZXNzIHRoYXQgeW91IHNvbHV0aW9uIGlzIHRvIGxldCB0aGUgDQo+IHNl cnZlciBwYXJzZSB0aHJvdWdoIGFsbCB0aGUgcmVjZWl2ZWQgU1lOIHdpdGggYSBnaXZlbiBrZXkg dG8gY2hlY2sgDQo+IHdoZXRoZXIgdGhpcyBpcyBhIGR1YWwgY29ubmVjdGlvbiBlc3RhYmxpc2ht ZW50IG9yIGEgcmVndWxhciANCj4gY29ubmVjdGlvbiBlc3RhYmxpc2htZW50LiBUaGUgbGltaXRh dGlvbiBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgDQo+IHNlcnZlciBuZWVkcyB0byBsb29rdXAg YWxsIHRoZSBrZXlzIG9mIHRoZSByZWNlaXZlZCBTWU5zIChwb3NzaWJseSANCj4gZHVyaW5nIGEg Z2l2ZW4gcGVyaW9kIG9mIHRpbWUgYXMgeW91IG1lbnRpb24gaW4geW91cg0KPiBlbWFpbCkgZXZl cnl0aW1lIGl0IHJlY2VpdmVzIGEgU1lOLiBUaGlzIGluY3JlYXNlcyB0aGUgU1lOIHByb2Nlc3Np bmcgDQo+IHRpbWUgb24gc2VydmVycyBhbmQgdGh1cyB0aGUgcmlzayBvZiBkZW5pYWwgb2Ygc2Vy dmljZSBhdHRhY2tzLg0KDQpZZXMsIGdvb2Qgb2JzZXJ2YXRpb24uIEluZGVlZCwgaXQgaXMgYSBy aXNrIGFuZCBJIGd1ZXNzIHdpdGhvdXQgYWRkaXRpb25hbCBwcm9jZXNzaW5nLCBjb21wYXJlZCB0 byBNUFRDUCwgaXQgaXMgaGFyZCB0byBzb2x2ZS4NCg0KT3VyIGltcGxlbWVudGF0aW9uIHVzZXMg dGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBhcyBleGlzdHMgaW4gdGhlIE1QVENQIHJlZmVyZW5jZSBp bXBsZW1lbnRhdGlvbiBmb3IgZW5zdXJpbmcgbG9jYWwgdW5pcXVlbmVzcyBvZiBrZXlzIHJlc3Bl Y3RpdmVseSB0aGUgY29ycmVzcG9uZGluZyB0b2tlbiAoaGFzaHRhYmxlcykuIFRodXMgdGhlIGNv bXBsZXhpdHkgaXMgcmVkdWNlZCB0byBzZWFyY2ggdGhlIGNvcnJlY3QgaGFzaCB0YWJsZSBlbnRy eSBhbmQgdGhlbiBvbmx5IHBhcnNlIHRoZSBsaW5rZWQgbGlzdCBzdG9yZWQgYXQgdGhpcyBwb2lu dC4NCg0KPiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZw0KPiB0byBzZWUgaG93IHlvdXIgaW1wbGVt ZW50YXRpb24gY29wZXMgd2l0aCB0aGlzIGlzc3VlLiBOb3RlIHRoYXQgaXQgDQo+IHJlcXVpcmVz IHRoZSBwcmVzZW5jZSBvZiBhIGtleSBpbnNpZGUgdGhlIFNZTiAoYXMgZGVmaW5lZCBpbiBSRkM2 ODI0KS4gDQo+IFRoaXMgaW1wbGllcyB0aGF0IHRoaXMgaXMgbm90IGNvbXBhdGlibGUgd2l0aCBS RkM2ODI0YmlzLg0KDQpJdCBzZWVtcyBzbywganVzdCByZWFkIGl0IHRoZSBmaXJzdCB0aW1lIGFu ZCB5ZXMsIGlmIEtleUEgaXMgbWlzc2luZyBpdCBpcyBoYXJkIHRvIGZpZ3VyZSBvdXQgU1lOcywg cmVsYXRlZCB0byB0aGUgc2FtZSByZXF1ZXN0Lg0KDQo+IFRoZSBzZWNvbmQgYXBwcm9hY2ggaGFz IGJlZW4gdXNlZCBzdWNjZXNzZnVsbHkgd2l0aCBIYXBweUV5ZUJhbGxzIGJ5IA0KPiB3ZWIgYnJv d2Vycy4gSXQgY291bGQgYmUgaW50ZWdyYXRlZCBpbiBhbnkgbGlicmFyeSBvciBoaWdoZXIgbGV2 ZWwgDQo+IHByb2dyYW1taW5nIGxhbmd1YWdlIGJ5IHNpbXBseSB0cnlpbmcgdG8gb3BlbiBzZXBh cmF0ZSBNUFRDUCANCj4gY29ubmVjdGlvbnMgYW5kIHJlc2V0IHRoYXQgb25lIHRoYXQgY29ubmVj dHMgc2xvd2x5LiBBIGtlcm5lbCANCj4gaW1wbGVtZW50YXRpb24gY291bGQgcHJvYmFibHkgYWxz byBpbmNsdWRlIGNvZGUgdG8gc3VwcG9ydCB0aGVzZSBwYXJhbGxlbCBlc3RhYmxpc2htZW50cyBv ZiBNUFRDUCBjb25uZWN0aW9ucy4NCj4gVGhpcyB3b3VsZCBhbGxvdyBhbGwgYXBwbGljYXRpb25z IHRvIGJlbmVmaXQgZnJvbSB0aGlzIGZlYXR1cmUsIGV2ZW4gDQo+IHRob3NlIHRoYXQgdXNlIHRo ZSBDIHNvY2tldCBBUEkgZGlyZWN0bHkuDQoNCkl0IGlzIGxpa2UgdGhlICJCcmVhayBiZWZvcmUg bWFrZSIgb3IgIlRpbWVyIiBwcm9wb3NhbCBmcm9tIG15IG9yaWdpbmFsIGVtYWlsLCB3aGljaCBp cyB2ZXJ5IHNpbWlsYXIgdG8gSGFwcHlFeWVCYWxscyBpZGVhIGluIGtlcm5lbCBzcGFjZS4NCg0K PiBUaGUgbWFpbiBiZW5lZml0IG9mIHRoZSBzZWNvbmQgYXBwcm9hY2ggaXMgdGhhdCB0aGUgY2xp ZW50IGlzIGluIA0KPiBjb250cm9sLiBJdCBjYW4gZGVsYXkgdGhlIHRyYW5zbWlzc2lvbiBvZiB0 aGUgc2Vjb25kIFNZTiBhcyBpbiANCj4gSGFwcHlFeWVCYWxscyB0byBhdm9pZCBkb3VibGluZyB1 bm5lY2Vzc2FyaWx5IHRoZSBudW1iZXIgb2YgU1lOcyB0aGF0IGEgc2VydmVyIGhhcyB0byBwcm9j ZXNzLg0KPiBTaW5jZSB0aGUgY2xpZW50IGlzIGxlc3MgbG9hZGVkIHRoYW4gdGhlIHNlcnZlciwg aXQgaXMgbGVzcyBhbiBpc3N1ZSANCj4gdG8gcHV0IHNvbWUgY29tcGxleGl0eSAoZS5nLiB0aW1l cnMsIHJlbWVtYmVyaW5nIHRoZSBiZXN0IGludGVyZmFjZSwgDQo+IC4uLikgb24gdGhlIGNsaWVu dCBzaWRlLg0KDQpJIGd1ZXNzLCB5b3UgbWVhbiB0aGUgdGhpcmQgIlRpbWVyIiBwcm9wb3NhbCwg d2hpY2ggZnVsZmlsbCB0aGUgcmVxdWlyZW1lbnQgb2Ygcm9idXN0bmVzcyBhcyB3ZWxsLiBBcyB5 b3UgYWxyZWFkeSB3cm90ZSwgd2UgcG9zc2libHkgZGVsYXkhISEgcmVxdWVzdHMsIHRoYXQncyB3 aHkgd2UgZG9uJ3QgcHJlZmVyIGl0IGN1cnJlbnRseSwgZXNwZWNpYWxseSBjb21wYXJlZCB0byB0 aGUgIkRvd25ncmFkZSIgcHJvcG9zYWwuDQpXZSBrbm93IGFib3V0IHRoZSBjb21wbGV4aXR5IG9m IHRoZSBmaXJzdCAiRG93bmdyYWRlIiBwcm9wb3NhbCwgYnV0IGhleSwgdG8gYmUgaG9uZXN0LCBN UFRDUCBpcyBzb21laG93IGFsc28gbm90IGVhc3kgOi0pDQoNCkkgdGhpbmsgaW4gZnVydGhlciBk aXNjdXNzaW9uIHdlIGhhdmUgdG8gY2xhcmlmeSwgaWYgd2UgcmFpc2Ugd2l0aCB0aGUgcXVlc3Rp b24gZm9yIE1QVENQIHJvYnVzdCBlc3RhYmxpc2htZW50IGEgc3RhbmRhcmQgcmVsZXZhbnQgdG9w aWMgb3IgaXMgaXQganVzdCBpbXBsZW1lbnRhdGlvbiByZWxhdGVkPw0KDQo+IElmIHlvdSB0cmF2 ZWwgdG8gUHJhZ3VlLCBJJ2QgYmUgaGFwcHkgdG8gZGlzY3VzcyB3aXRoIHlvdS4gV2UnbGwgYWxz byANCj4gcGFydGljaXBhdGUgdG8gdGhlIGhhY2thdGhvbiBvbiBTdW5kYXkgaWYgeW91J2QgbGlr ZSB0byBkaXNjdXNzIGFib3V0IA0KPiB5b3VyIGltcGxlbWVudGF0aW9uLg0KPiANCg0KVW5mb3J0 dW5hdGVseSwgSSBhcnJpdmUgU3VuZGF5IGxhdGUgYXJvdW5kIDhwbS4gQnV0IEkgbGlrZSB0byBk aXNjdXNzIHRoZSBpZGVhcyB3aXRoIHlvdSBhbmQgYW55b25lIHdobyBpcyBpbnRlcmVzdGVkLiBQ ZXJoYXBzLCB3ZSBhZ3JlZSBkdXJpbmcgdGhlIGZpcnN0IE1QVENQIHNlc3Npb24gb24gVHVlc2Rh eSBzb21lIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbj8gT3RoZXJ3aXNlIHlvdSBjYW4gY29udGFjdCBt ZSBkaXJlY3RseSBpZiB5b3UgaGF2ZSBzb21lIHRpbWUgb24gU3VuZGF5IGV2ZW5pbmcgb3IgTW9u ZGF5Lg0KSSdtIGxvb2tpbmcgZm9yd2FyZCB0byBtZWV0IHlvdSBpbiBQcmFndWUuIA0KDQo+IEJl c3QgcmVnYXJkcywNCj4gDQo+IA0KPiBPbGl2aWVyDQoNCg== From nobody Thu Jul 13 08:35:55 2017 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 8CE05131698; Thu, 13 Jul 2017 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ke4uTQ_Qt80l; Thu, 13 Jul 2017 08:35:47 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A7A12ECC6; Thu, 13 Jul 2017 08:35:45 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id AD5E23406C1; Thu, 13 Jul 2017 17:35:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.4608); Thu, 13 Jul 2017 17:35:43 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 13 Jul 2017 17:35:43 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 23671054; Thu, 13 Jul 2017 17:35:42 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_9F23D08E-6064-428B-B718-334FEE2BF903"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 13 Jul 2017 17:35:41 +0200 Message-Id: <481A6610-DC1F-437E-BB6E-AA8DE757803F@trammell.ch> To: alto@ietf.org, teas@ietf.org, banana@ietf.org, plus@ietf.org, multipathtcp@ietf.org, iccrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [multipathtcp] Proposed Path Aware Networking Research Group in Prague X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 15:35:49 -0000 --Apple-Mail=_9F23D08E-6064-428B-B718-334FEE2BF903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, and apologies for the cross-posting, We'll be having a first meeting of the proposed Path Aware Networking (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall 3. It's been suggested The scope of this RG might be of interest to your working group, research group, or BoF, so I hope you'll have a chance to drop by. Olivier Bonaventure will give a review and overview of research to date in this space, and Adrian Perrig will present a fully path-aware Internet architecture, as an illustration of what is possible when path-awareness is promoted to a first-order goal. =46rom our proposed charter = (https://datatracker.ietf.org/group/panrg/about): The Internet architecture assumes a division between the end-to-end functionality of the transport layer and the properties of the path = between the endpoints. The path is assumed to be invisible, homogeneous, singular, = with dynamics solely determined by the connectivity of the endpoints and the = Internet control plane. Endpoints have very little information about the paths = over which their traffic is carried, and no control at all beyond the destination = address. Increased diversity in access networks, and ubiquitous mobile = connectivity, have made this architecture's assumptions about paths less tenable. Multipath protocols taking advantage of this mobile connectivity begin to show us = a way forward, though: if endpoints cannot control the path, at least they can determine the properties of the path by choosing among paths available = to them. This research group aims to support research in bringing path awareness = to transport and application layer protocols, and to bring research in this = space to the attention of the Internet engineering and protocol design = community. The scope of work within the RG includes, but is not strictly limited = to: - communication and discovery of information about the properties of a = path on local networks and in internetworks, exploration of trust and risk = models associated with this information, and algorithms for path selection at endpoints based on this information. - algorithms for making transport-layer scheduling decisions based on information about path properties. - algorithms for reconciling path selection at endpoints with widely = deployed routing protocols and network operations best practices. The research group's scope overlaps with existing IETF and IRTF efforts, = and will collaborate with groups chartered to work on multipath transport = protocols (MPTCP, QUIC, TSVWG), congestion control in multiply-connected = environments (ICCRG), and alternate routing architectures (e.g. LISP), and is related = to the questions raised in the multiple recent BoF sessions that have = addressed path awareness and multiply-connected networks (e.g. SPUD, PLUS, = BANANA). The PAN(P)RG intends to meet at each IETF meeting until a determination is made whether or not to charter it. Afterward, the RG = intends to meet at 1-3 IETF meetings per year, and hold one workshop per year, = collocated with a related academic conference. Thanks, cheers Brian (as co-chair PAN PRG) --Apple-Mail=_9F23D08E-6064-428B-B718-334FEE2BF903 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZZ5NOAAoJEIoSt78L6kajB9QQAL1Gzdel96nFRwEv7bo1rKUn HBlBczp70W1RVA97ebOjwn8JUG6PMXsuR44JkORAc8FHiQ7A6al1uGJTm2iRIwYn SMapVECN1C5CTOUhyzzI1TXRMI2kvr+aSs7esqK8KknlUkF4ItT/Fg0jzcuNcJFs v9tRnkiNvrrJ1FIJp6lju6iH+hO3gVsBUsRoHhkpRYMxx47eTspdJx43sCEkQxpZ rB8qhf4LyOqSmgjeTmfU6zfyvElubHQn9tQw4zI+ZOh5/NldW/RlLbtTS9p0n9eX xKfLngDuv/KRF76wN0xZqlfqI0q7snZhX2KY6tPuAcS6Gxgn2C4wXvTfFqL9AaR7 JTeWhal/cKdwagNzwm8/zEDpj46uHJkXSTYZpdzgqUsy4/LAfzDfHroDQVUJgv+o 3u5xnvz/TWkncnxEiel+7HDYNnfkgpSxCUBKoIhIPhTcHqgPg+3SaUg0eS9USqkA m5yWeXB1dYadHNZ2UY4Kks6ECc3Bnt0Xg2gm3Ch4eTCn39mW+28XjnFdQ1I/uonl RrqjNozvjUl3kLlb55GfaUMjrEwjVyQc5j9r9SyUm8dIm8eWpsmc8+LUhZIA3tP+ no02PudNG46cycm+c7SNhqi8FgePLSbg4YJa6zdtbrLQrMUSl3b7UnqYuERIDFPs wzSk89DuTK5fD+Jlemka =+TWK -----END PGP SIGNATURE----- --Apple-Mail=_9F23D08E-6064-428B-B718-334FEE2BF903-- From nobody Thu Jul 13 10:07:46 2017 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 2DC6F1201F8; Thu, 13 Jul 2017 10:07:38 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7l9GFsv8PNTC; Thu, 13 Jul 2017 10:07:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6741316FF; Thu, 13 Jul 2017 10:07:37 -0700 (PDT) Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v6DH7BpN003269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 10:07:13 -0700 (PDT) To: =?UTF-8?Q?Drago=c8=99_Niculescu?= Cc: Vladimir Olteanu , mohamed boucadair , David Schinazi , multipathtcp , int-area References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> From: Joe Touch Message-ID: Date: Thu, 13 Jul 2017 10:07:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-MailScanner-ID: v6DH7BpN003269 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 17:07:38 -0000 On 7/6/2017 1:41 AM, Dragoș Niculescu wrote: > ----- On Jul 5, 2017, at 7:59 PM, Joe Touch touch@isi.edu wrote: > >> On 7/5/2017 9:39 AM, Vladimir Olteanu wrote: >> >> >> It can also be stacked as many times as desired for arbitrarily long proxy >> chains. However: >> * We avoid using the SYN's payload as extra option space (which, I think, goes >> against TCP's core philosophy). >> >> [Med] This is also true for MP_CONVERT Information Element which is not a TCP >> option, but a data supplied for proxy purposes in the SYN payload. >> Fair enough, but this is not a purely layer 5+ protocol. It seems that you are >> strongly tied to TFO (between the client and the proxy). MP_CONVERT must be >> part of the SYN's payload, because the following SYN+ACK depends on the >> contents of MP_CONVERT and signals that the remote server has accepted your >> connection. >> The biggest impact of including non-data information in the SYN payload area is >> that it completely defeats graceful fallback for SYN receivers that don't >> support the option. As you note, it can be *more* safe when tied to out-of-band >> context (e.g., prior TFO support), but TCP has NO requirement that such context >> is absolutely maintained across different connections. You might be speaking to >> a different stack or demuxed off to a different virtual host behind a load >> balancer. >> >> Ultimately, putting any non-data info in the SYN payload violates the >> requirement that TCP options can be ignored by receivers that don't support >> them *without* impacting the ability of *that* connection attempt to succeed. >> >> Joe > SOCKSv6 proposal makes use of extra data in the SYN (SOCKS data, and user data), but > its correctness and backward compatibility does not depend on TFO, only its RTT performance. > In fact, when TFO is not available neither between client and proxy, nor between proxy and > server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But TFO is likely to be the most > common case in the future - Linux kernel has TFO client side on by default since 3.12 > (November 2013)[1], and it seems to be the default in all Android phones and default > Linux installs. What happens with a legacy receiver? Joe From nobody Thu Jul 13 10:10:21 2017 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 C0B4F12F257; Thu, 13 Jul 2017 10:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qArnJ4dBuT-Z; Thu, 13 Jul 2017 10:10:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3F51298BA; Thu, 13 Jul 2017 10:10:12 -0700 (PDT) Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v6DH9pgs004172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 10:09:53 -0700 (PDT) To: mohamed.boucadair@orange.com, Vladimir Olteanu , David Schinazi Cc: multipathtcp , "Int-area@ietf.org" References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A001A21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <57f2db33-7367-5eea-371a-fae3573a307a@isi.edu> Date: Thu, 13 Jul 2017 10:09:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A001A21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------7A791AE29B718741E670D7B9" Content-Language: en-US X-MailScanner-ID: v6DH9pgs004172 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 17:10:14 -0000 This is a multi-part message in MIME format. --------------7A791AE29B718741E670D7B9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 7/6/2017 6:02 AM, mohamed.boucadair@orange.com wrote: > > Ultimately, putting any non-data info in the SYN payload violates the > requirement that TCP options can be ignored by receivers that don't > support them *without* impacting the ability of *that* connection > attempt to succeed. > > [Med] You are right if we are talking about TCP options that are > inserted in the payload of the SYN to every remote peer. This is not > the case for the MPTCP proxy case: this is about proxy-supplied data > that is sent to the proxy, which is provisioned by the provider. > Proxy-supplied data is not received by the remote peer. > You have not considered what happens when the remote peer changes or disappears. In that case, your E2E TCP connection is no longer falling back safely and correctly, based on the principle that all unknown options can be ignored - as is required by RFC793. Further, I have no idea what you think is happening above, but at *best* it's TCP between the proxies, perhaps triggered by packets between the endpoints. However, it's no longer a TCP "connection" in any sense of any IETF standard of which I am familiar. Joe --------------7A791AE29B718741E670D7B9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 7/6/2017 6:02 AM, mohamed.boucadair@orange.com wrote:

Ultimately, putting any non-data info in the SYN payload violates the requirement that TCP options can be ignored by receivers that don't support them *without* impacting the ability of *that* connection attempt to succeed.

[Med] You are right if we are talking about TCP options that are inserted in the payload of the SYN to every remote peer. This is not the case for the MPTCP proxy case: this is about proxy-supplied data that is sent to the proxy, which is provisioned by the provider. Proxy-supplied data is not received by the remote peer.

You have not considered what happens when the remote peer changes or disappears.

In that case, your E2E TCP connection is no longer falling back safely and correctly, based on the principle that all unknown options can be ignored - as is required by RFC793.

Further, I have no idea what you think is happening above, but at *best* it's TCP between the proxies, perhaps triggered by packets between the endpoints. However, it's no longer a TCP "connection" in any sense of any IETF standard of which I am familiar.

Joe

--------------7A791AE29B718741E670D7B9-- From nobody Fri Jul 14 00:44:20 2017 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 6CFDF1317BE; Fri, 14 Jul 2017 00:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 tLPSR1r8LR4r; Fri, 14 Jul 2017 00:44:16 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id A66EA1317A9; Fri, 14 Jul 2017 00:44:15 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AuIfTPx97bhlAOP9uRHKM819IXTAuvvDOBiVQ1KB+?= =?us-ascii?q?0+sWIJqq85mqBkHD//Il1AaPBtSEraocw8Pt8InYEVQa5piAtH1QOLdtbDQizf?= =?us-ascii?q?ssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1?= =?us-ascii?q?JuPoEYLOksi7ze6/9pnRbglSmDaxfa55IQmrownWqsQYm5ZpJLwryhvOrHtIeu?= =?us-ascii?q?BWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3o05MLwqxbO?= =?us-ascii?q?SxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDtU7s6RSqt4LtqSB/wiS?= =?us-ascii?q?cIKTg58H3MisdtiK5XuQ+tqwBjz4LRZoyeKfhwcb7Hfd4CS2RPXthfWS9DDYOy?= =?us-ascii?q?coUAAPYOM+lfoYnhvFYOsQK+ChWwCO711jNFhHn71rA63eQ7FgHG2RQtEdwUsH?= =?us-ascii?q?vOo9X1M6cQWv2twqnJ0TrDcvdW1inm6IfUbxAqvPaBUq9qccXLxkkvEBjFgk+W?= =?us-ascii?q?qYzkIzyVy+ANvHaA7+V8SOKikHIoqxprrji328cjkZPFhpgSyl3d8yhy3YU7Jc?= =?us-ascii?q?WgRUJmbtOoDYFcuiKaOodsXM8uXWNltDw0x7AApJW1ZjIFyI49yB7ac/GHdo+I?= =?us-ascii?q?7Q/9W+uJOjd4gW5leKq4hxav7Uis0u38Wdew0FZNtidFjNzMuWoM1xzX8MSIVu?= =?us-ascii?q?B98l252TaSzA/f8PtEIUcsmaraLZ4u3KIwm4IOvUnMAyP6gkb7ga+Mekk65OSl?= =?us-ascii?q?6f7rb7v+qp+ZLYB0iwX+Mqo0msy4BOQ1KhUBX3KB9uSz073j5lf1QLNLjvIqj6?= =?us-ascii?q?nZtI7VJd8Hqa6kGAJazp0j5wynDze7y9sUh2MHLFVddBKdk4fpI03OIOz/Dfqn?= =?us-ascii?q?nlusiytkx/DHPr3nGJrML3nDnaz7crZl805czBQ8wcpD6JJTD7ELOOjzVVPptN?= =?us-ascii?q?zEEh85NBS5zeXhCNVhz48RQ3iPDbGDP67JsF+H+P4vI+eWaI8Sojb9JOAv5+Ty?= =?us-ascii?q?gn8hhV8dYa6p0IMSaHClGvRmP0SZYWL2jdcdEWcKohYxTPTxhV2DTzFTe3iyU7?= =?us-ascii?q?g75jEhB4KsFZ3DSZy1gLydwCe7GYVbZnxBClCRDXjod56JW/YXaCKTOMNujCEL?= =?us-ascii?q?VaW5QY87yR6urBP6y6ZgLufM/y0YspLj28Jw5+LNiB4+7yd7D8OA026RVW57g3?= =?us-ascii?q?kHRz4s3K1kpkx90E2M0a53g/NGD9Bc+/RJUgJpfaLbms59BpjOXR/Kfp/dVFG7?= =?us-ascii?q?SdWOACowCN893oldTVx6HoCOlBnM2MjiJb4eiriGH5cpuvbQxXH+IN07zXfNya?= =?us-ascii?q?0slFI7asBUc3W7jOhl8F6AVMbyj0yFmvPyJuwn1ynX+TLGlDLWsQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BcAwDrdGhZXQPjVY1dDg4BAQQBAQoBA?= =?us-ascii?q?RcBAQQBAQoBAYUnjn6QZSKYFYV2AoRDAQEBAQEBAQECAQUZFwVYgjMkAYJAAQE?= =?us-ascii?q?BAQIBI0IUBQsCAQgYAgINGQICQxQCBBOKJwyuL4Imix4BAQgCJoELgh2FZIJuh?= =?us-ascii?q?FQWgxOCYQWRXQGNU6ZClVQCVoELUodYQnOIUAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2BcAwDrdGhZXQPjVY1dDg4BAQQBAQoBARcBAQQBAQoBAYU?= =?us-ascii?q?njn6QZSKYFYV2AoRDAQEBAQEBAQECAQUZFwVYgjMkAYJAAQEBAQIBI0IUBQsCA?= =?us-ascii?q?QgYAgINGQICQxQCBBOKJwyuL4Imix4BAQgCJoELgh2FZIJuhFQWgxOCYQWRXQG?= =?us-ascii?q?NU6ZClVQCVoELUodYQnOIUAEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,357,1496091600"; d="scan'208";a="949657" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 14 Jul 2017 10:44:11 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 09ED81A600EE; Fri, 14 Jul 2017 10:44:11 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0kcSbKwqO1sY; Fri, 14 Jul 2017 10:44:10 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id DEE901A60102; Fri, 14 Jul 2017 10:44:10 +0300 (EEST) Received: from vmail.cs.pub.ro (vmail.cs.pub.ro [141.85.227.3]) by vmail.cs.pub.ro (Postfix) with ESMTP id DA32B1A600EE; Fri, 14 Jul 2017 10:44:10 +0300 (EEST) Date: Fri, 14 Jul 2017 10:44:10 +0300 (EEST) From: =?utf-8?Q?Drago=C8=99?= Niculescu To: Joe Touch Cc: Vladimir Olteanu , mohamed boucadair , David Schinazi , multipathtcp , int-area Message-ID: <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> In-Reply-To: References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC59 (Mac)/8.6.0_GA_1194) Thread-Topic: SOCKS 6 Draft Thread-Index: xVWpqn13Eak9fCysYUNjHcpFZr8XQw== Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 07:44:18 -0000 ----- On Jul 13, 2017, at 8:07 PM, Joe Touch touch@isi.edu wrote: > On 7/6/2017 1:41 AM, Drago=C8=99 Niculescu wrote: >> ----- On Jul 5, 2017, at 7:59 PM, Joe Touch touch@isi.edu wrote: >> >>> On 7/5/2017 9:39 AM, Vladimir Olteanu wrote: >>> >>> >>> It can also be stacked as many times as desired for arbitrarily long pr= oxy >>> chains. However: >>> * We avoid using the SYN's payload as extra option space (which, I thin= k, goes >>> against TCP's core philosophy). >>> >>> [Med] This is also true for MP_CONVERT Information Element which is not= a TCP >>> option, but a data supplied for proxy purposes in the SYN payload. >>> Fair enough, but this is not a purely layer 5+ protocol. It seems that = you are >>> strongly tied to TFO (between the client and the proxy). MP_CONVERT mus= t be >>> part of the SYN's payload, because the following SYN+ACK depends on the >>> contents of MP_CONVERT and signals that the remote server has accepted = your >>> connection. >>> The biggest impact of including non-data information in the SYN payload= area is >>> that it completely defeats graceful fallback for SYN receivers that don= 't >>> support the option. As you note, it can be *more* safe when tied to out= -of-band >>> context (e.g., prior TFO support), but TCP has NO requirement that such= context >>> is absolutely maintained across different connections. You might be spe= aking to >>> a different stack or demuxed off to a different virtual host behind a l= oad >>> balancer. >>> >>> Ultimately, putting any non-data info in the SYN payload violates the >>> requirement that TCP options can be ignored by receivers that don't sup= port >>> them *without* impacting the ability of *that* connection attempt to su= cceed. >>> >>> Joe >> SOCKSv6 proposal makes use of extra data in the SYN (SOCKS data, and use= r data), >> but >> its correctness and backward compatibility does not depend on TFO, only = its RTT >> performance. >> In fact, when TFO is not available neither between client and proxy, nor= between >> proxy and >> server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But TFO = is >> likely to be the most >> common case in the future - Linux kernel has TFO client side on by defau= lt since >> 3.12 >> (November 2013)[1], and it seems to be the default in all Android phones= and >> default >> Linux installs. > What happens with a legacy receiver? >=20 > Joe Legacy receiver will use plain TCP. Proxies (SOCKS and others) are routinel= y used to bridge new options to legacy receivers. In this case, TFO will wo= rk between client and proxy, but not between proxy and legacy server.=20 --=20 Drago=C8=99 From nobody Mon Jul 17 15:04:13 2017 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 8059A131CC3 for ; Mon, 17 Jul 2017 15:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 FMVKjC16IpI3 for ; Mon, 17 Jul 2017 15:04:10 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B911126C23 for ; Mon, 17 Jul 2017 15:04:10 -0700 (PDT) Received: from mbpobo.local (unknown [80.188.36.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E50F867DE21 for ; Tue, 18 Jul 2017 00:03:59 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp6.sgsi.ucl.ac.be E50F867DE21 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1500329040; bh=7vWH+9tsmGWdte+lY1OvZmk8+fmZ/xnqaLQ37Y3sJ10=; h=Reply-To:To:From:Subject:Date; b=0QuWs55zmb4QhSnZ/fECEn14bEZfHH8P4KzHdoYYJZ14CJWR17I6+L4L5E/pQZGlT IllWEyIEt1UslDIjVPqFn8JUuIoDD0mps0+YTkGolKmOPOGkd7zCntqUAmxtXs5eYT qJbPSrmozN8gJdJP+rxGfgiyH5gExDvFH8w7fRjE= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-6 Reply-To: Olivier.Bonaventure@uclouvain.be To: multipathtcp From: Olivier Bonaventure Message-ID: <8a787baa-6e1a-ca0a-8d92-f2a200d223d0@uclouvain.be> Date: Tue, 18 Jul 2017 00:03:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: E50F867DE21.A2D49 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [multipathtcp] New version of draft-bonaventure-mptcp-converters X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 22:04:12 -0000 Hello, We have slightly updated the draft that I will present on Tuesday at IETF99. You can find links to the revised version below. Changes are minor compared to the initial version that was posted two weeks ago. Name: draft-bonaventure-mptcp-converters Revision: 01 Title: 0-RTT TCP converters Document date: 2017-07-17 Group: Individual Submission Pages: 34 URL: https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt Status: https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-converters/ Htmlized: https://tools.ietf.org/html/draft-bonaventure-mptcp-converters-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-bonaventure-mptcp-converters-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-bonaventure-mptcp-converters-01 Abstract: This document proposes the utilisation of Transport Converters to aid the deployment of TCP extensions such as Multipath TCP. Olivier From nobody Mon Jul 17 22:40:36 2017 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 7C373129B4B for ; Mon, 17 Jul 2017 22:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 CK8Sc_z8S9mm for ; Mon, 17 Jul 2017 22:40:32 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0130.outbound.protection.outlook.com [104.47.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8623D129B43 for ; Mon, 17 Jul 2017 22:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aqevvWkNsBqhjyncDjwRZC73el8X+9PvaGo38m5bGJA=; b=rabi45J+LFO9mu6JnxHuzCkCnYU8+QyXx7ZZ5w6TCBwhOLqB5byzktxQ8L3OeV00IE6jHPWhFJ5FCHYXuKBOaS9gi/txwQAFyDEx7Pdt9mtQZHujpT0fvmPtlMAz+lZCZ6/kYaGDaDP8/FN3i6QFqIJi75WLbSElSv3KCnXOhWk= Received: from HE1PR07MB0970.eurprd07.prod.outlook.com (10.162.27.151) by HE1PR07MB3498.eurprd07.prod.outlook.com (10.170.247.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Tue, 18 Jul 2017 05:40:29 +0000 Received: from HE1PR07MB0970.eurprd07.prod.outlook.com ([fe80::89c8:633c:6fd2:68c1]) by HE1PR07MB0970.eurprd07.prod.outlook.com ([fe80::89c8:633c:6fd2:68c1%13]) with mapi id 15.01.1282.008; Tue, 18 Jul 2017 05:40:29 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "Olivier.Bonaventure@uclouvain.be" , multipathtcp Thread-Topic: [multipathtcp] New version of draft-bonaventure-mptcp-converters Thread-Index: AQHS/0ijskroMCPNFU23BH6xa7DI+6JZM64A Date: Tue, 18 Jul 2017 05:40:29 +0000 Message-ID: <52603713-B647-4604-AE54-611F5A41CDBE@nokia.com> References: <8a787baa-6e1a-ca0a-8d92-f2a200d223d0@uclouvain.be> In-Reply-To: <8a787baa-6e1a-ca0a-8d92-f2a200d223d0@uclouvain.be> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 authentication-results: uclouvain.be; dkim=none (message not signed) header.d=none;uclouvain.be; dmarc=none action=none header.from=nokia.com; x-originating-ip: [62.168.35.67] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3498; 7:S4WJfiVK3pMsu60Mah4Bjf4anF8jiCn4ilRncf6D4pRhojGY+z/5/dLWyP/Fu3ymHpO1HkLbfL6jultyzzPYb7LM0j0lGbcBaXD4mNL29DFK5lgZyINDxnmbnMBpkY39aR1R5TbevdOQ00B6+9zX23HQ93u6VQk4NsGDhVaotrMFi5e9HydELTw0zuVn/Q+iwO0iSao6uCO3tLYmgVgNiy9CwSrldkNoyRrw3arh3Vz1xnPWAJA+yb8TFKQNXI0IE4p7bmHyFBTAH/iywP2Le9Guue+frO/LMfL+bxgGqZQBfF1y3ruYsmqGaZX6wxUaus2oxJqI7s795yOhY5t+psjS5R+w0x8Xwd0gaTD9tsUclxCYKVXnifMyKIc9Gt3BvhGbfJcm2yZpI9sWkyQEweCkzFJQFrPoo3MNXIQADjclTn+UtCMUxIs/EcuVIOv363m9F1Q2UcC+Vps3m7wbuR7DDB4cHSJ8cPMTcx4YzUx+LhifBraeefhKIQImRa7amMxxBGDqGcT5Wd9aYacuE8dP0pUaYVoq6JsdkmGSiyfPq5i8y6EuBRuhODqduEeknhhN8yqG50NMjg3lgmWM7hp5irHs+lcfb04MLYJ7L8SPojYl0DiGqw92yBxx++eisme3Tj8BRzbb7fUbyZANHh7onfjeRW8+65EldURuHFB2z8pYg8mRxV0l1CSM3yzQnTm9qCr+C724tFZ9Ibju37jDBE9uvc6NTKqeLW9ashxRfybU1bKwXOMya42vIVbgL9DusyxCBThUL0gLt+oueGXys7uGjNpLqvdxnflZUrA= x-ms-office365-filtering-correlation-id: ea39fee6-38ab-4291-43e6-08d4cd9f7fd0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR07MB3498; x-ms-traffictypediagnostic: HE1PR07MB3498: x-exchange-antispam-report-test: UriScan:(278178393323532)(120809045254105)(236129657087228)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3498; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39410400002)(39840400002)(39400400002)(39850400002)(24454002)(377424004)(83506001)(3846002)(82746002)(102836003)(6116002)(33656002)(6436002)(38730400002)(6246003)(6512007)(6306002)(99286003)(53936002)(3660700001)(3280700002)(229853002)(5250100002)(8676002)(2906002)(6486002)(81166006)(6506006)(2950100002)(86362001)(8936002)(2501003)(189998001)(53546010)(2900100001)(7736002)(305945005)(478600001)(25786009)(36756003)(14454004)(66066001)(4001350100001)(230783001)(50986999)(54356999)(76176999)(83716003)(5660300001)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB3498; H:HE1PR07MB0970.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <630B3EB9EDDDAC49A2FF276AC878BA55@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 05:40:29.2994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3498 Archived-At: Subject: Re: [multipathtcp] New version of draft-bonaventure-mptcp-converters X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 05:40:34 -0000 T2xpdmllciwgZ29vZCBkcmFmdC4gVGh4IA0KDQpPbiAxOC8wNy8yMDE3LCAwMDowNCwgIm11bHRp cGF0aHRjcCBvbiBiZWhhbGYgb2YgT2xpdmllciBCb25hdmVudHVyZSIgPG11bHRpcGF0aHRjcC1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBPbGl2aWVyLkJvbmF2ZW50dXJlQHVjbG91dmFp bi5iZT4gd3JvdGU6DQoNCiAgICBIZWxsbywNCiAgICANCiAgICANCiAgICBXZSBoYXZlIHNsaWdo dGx5IHVwZGF0ZWQgdGhlIGRyYWZ0IHRoYXQgSSB3aWxsIHByZXNlbnQgb24gVHVlc2RheSBhdCAN CiAgICBJRVRGOTkuIFlvdSBjYW4gZmluZCBsaW5rcyB0byB0aGUgcmV2aXNlZCB2ZXJzaW9uIGJl bG93LiBDaGFuZ2VzIGFyZSANCiAgICBtaW5vciBjb21wYXJlZCB0byB0aGUgaW5pdGlhbCB2ZXJz aW9uIHRoYXQgd2FzIHBvc3RlZCB0d28gd2Vla3MgYWdvLg0KICAgIA0KICAgIE5hbWU6CQlkcmFm dC1ib25hdmVudHVyZS1tcHRjcC1jb252ZXJ0ZXJzDQogICAgUmV2aXNpb246CTAxDQogICAgVGl0 bGU6CQkwLVJUVCBUQ1AgY29udmVydGVycw0KICAgIERvY3VtZW50IGRhdGU6CTIwMTctMDctMTcN CiAgICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOgkJMzQNCiAgICBV Ukw6IA0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib25h dmVudHVyZS1tcHRjcC1jb252ZXJ0ZXJzLTAxLnR4dA0KICAgIFN0YXR1czogDQogICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9uYXZlbnR1cmUtbXB0Y3AtY29udmVy dGVycy8NCiAgICBIdG1saXplZDogDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJvbmF2ZW50dXJlLW1wdGNwLWNvbnZlcnRlcnMtMDENCiAgICBIdG1saXplZDogDQogICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib25hdmVudHVyZS1t cHRjcC1jb252ZXJ0ZXJzLTAxDQogICAgRGlmZjogDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWJvbmF2ZW50dXJlLW1wdGNwLWNvbnZlcnRlcnMtMDENCiAgICAN CiAgICBBYnN0cmFjdDoNCiAgICAgICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0aGUgdXRpbGlz YXRpb24gb2YgVHJhbnNwb3J0IENvbnZlcnRlcnMgdG8gYWlkDQogICAgICAgIHRoZSBkZXBsb3lt ZW50IG9mIFRDUCBleHRlbnNpb25zIHN1Y2ggYXMgTXVsdGlwYXRoIFRDUC4NCiAgICANCiAgICAN CiAgICBPbGl2aWVyDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICBtdWx0aXBhdGh0Y3AgbWFpbGluZyBsaXN0DQogICAgbXVsdGlw YXRodGNwQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tdWx0aXBhdGh0Y3ANCiAgICANCg0K From nobody Tue Jul 18 05:10:11 2017 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 E0A5C12EBF7 for ; Tue, 18 Jul 2017 05:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 A6ykwEO8lLCJ for ; Tue, 18 Jul 2017 05:10:07 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1309A127599 for ; Tue, 18 Jul 2017 05:10:06 -0700 (PDT) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Jul 2017 13:10:04 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 18 Jul 2017 13:10:02 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Jul 2017 13:10:02 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Tue, 18 Jul 2017 13:10:02 +0100 From: To: Thread-Topic: Volunteers for MPTCP notetakers and jabber Thread-Index: AdL/vNRF7gVpMU/ZRWmC5t49X93RTg== Date: Tue, 18 Jul 2017 12:10:01 +0000 Message-ID: <3f7443ec8c6e44aabaaa889b92c431dc@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.216.161.24] Content-Type: multipart/alternative; boundary="_000_3f7443ec8c6e44aabaaa889b92c431dcrew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Volunteers for MPTCP notetakers and jabber X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:10:10 -0000 --_000_3f7443ec8c6e44aabaaa889b92c431dcrew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you can help out with note-taking or jabber scribing /monitoring for tod= ay's session, please can you let me know Ps the minute takers usually type them directly into http://etherpad.tools.= ietf.org:9000/p/notes-ietf-99-mptcp?useMonospaceFont=3Dtrue Thanks very much, phil --_000_3f7443ec8c6e44aabaaa889b92c431dcrew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you can help out with note-taking or jabber scribing /monitorin= g for today’s session, please can you let me know

Ps the minute takers usually type them directly into http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-mptcp?useMonospaceFont= =3Dtrue

Thanks very much,

phil

 

--_000_3f7443ec8c6e44aabaaa889b92c431dcrew09926dag03bdomain1sy_-- From nobody Wed Jul 19 00:45:36 2017 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 EF816131C05 for ; Wed, 19 Jul 2017 00:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 EYf5gJvUVId5 for ; Wed, 19 Jul 2017 00:45:33 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AC912ECC3 for ; Wed, 19 Jul 2017 00:45:33 -0700 (PDT) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A52AD278317 for ; Wed, 19 Jul 2017 16:45:31 +0900 (JST) Received: by mail-it0-f52.google.com with SMTP id h199so25396097ith.1 for ; Wed, 19 Jul 2017 00:45:31 -0700 (PDT) X-Gm-Message-State: AIVw111U6x+9rSwgzMeNkZcrM4KEE0HGDTUj2sFGOMcMP0aSUDbTZ98p aafsiIX5E5TrIolb6K7XUNzZUFgW2A== X-Received: by 10.36.39.77 with SMTP id g74mr1012697ita.89.1500450330402; Wed, 19 Jul 2017 00:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.19 with HTTP; Wed, 19 Jul 2017 00:45:29 -0700 (PDT) From: Yoshifumi Nishida Date: Wed, 19 Jul 2017 00:45:29 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="001a11474b8cf2c4690554a6d0eb" Archived-At: Subject: [multipathtcp] q about draft-bonaventure-mptcp-converters X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:45:35 -0000 --001a11474b8cf2c4690554a6d0eb Content-Type: text/plain; charset="UTF-8" Hi Olivier, I am sorry that my question was not clear during the meeting. I think one use case we had before was a client which doesn't support mptcp can still utilize mptcp in some part of the path. Could you explain how to handle this case? Thanks, -- Yoshi --001a11474b8cf2c4690554a6d0eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Olivier,

I am sorry that my question= was not clear during the meeting.
I think one use case we had be= fore was a client which doesn't support mptcp can still utilize mptcp i= n some part of the path.=C2=A0
Could you explain how to handle th= is case?=C2=A0

Thanks,
--
Yosh= i=C2=A0

=C2=A0
--001a11474b8cf2c4690554a6d0eb-- From nobody Wed Jul 19 01:00:01 2017 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 D11B3131C1D for ; Wed, 19 Jul 2017 00:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 Mav86SXBzff7 for ; Wed, 19 Jul 2017 00:59:54 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F421A131C08 for ; Wed, 19 Jul 2017 00:59:53 -0700 (PDT) Received: from mbpobo.local (unknown [80.188.36.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F105267DAD4; Wed, 19 Jul 2017 09:59:43 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp4.sgsi.ucl.ac.be F105267DAD4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1500451184; bh=eZwRIKcb1USj/M8Hnz3VpNCTnFEirgLwRkWKGWkQ3sY=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=NjpnIWZBzZBjM0SdsMlmnvDxwtS7I8iSbP13CPBxPalB+MXovSAv25AS2zMFnFLDW Xh82nUW8QWbinSxiJ59FS9uqeE6Kne/hk7hMYIMr7mFWFjxtnhB7fB+yQkCa+8ozOG CS273PKLh0v95T93stm56Wx2uS4m3LVbclNsq4t8= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-4 Reply-To: Olivier.Bonaventure@uclouvain.be To: Yoshifumi Nishida , multipathtcp References: From: Olivier Bonaventure Message-ID: <0d42fc28-07ec-15c1-d8ac-ae88849a154d@uclouvain.be> Date: Wed, 19 Jul 2017 09:59:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: F105267DAD4.A0FED X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] q about draft-bonaventure-mptcp-converters X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:59:57 -0000 Yoshifumi, > > I am sorry that my question was not clear during the meeting. > I think one use case we had before was a client which doesn't support > mptcp can still utilize mptcp in some part of the path. > Could you explain how to handle this case? Thanks for the clarification. The situation is typically the following : client -- cpe -- net 1 --- converter ---- server +---- net 2 ------+ In this case, the cpe runs a transparent TCP proxy that intercepts the TCP connection established by the client. This TCP proxy implements the converter protocol and interacts with the converter through net1 and/or net2. The transparent TCP proxy running on the cpe does not need to be standardised and various forms of such proxies are deployed. What needs to the standardised is the format of the messages that the cpe exchanges with the converter and this is what the draft proposes. Olivier From nobody Wed Jul 19 11:27:00 2017 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 6F02912EC18; Wed, 19 Jul 2017 11:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 yMBogzFTT9gC; Wed, 19 Jul 2017 11:26:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6831300CE; Wed, 19 Jul 2017 11:26:50 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JIQK7C018626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 11:26:20 -0700 (PDT) To: =?UTF-8?Q?Drago=c8=99_Niculescu?= Cc: Vladimir Olteanu , mohamed boucadair , David Schinazi , multipathtcp , int-area References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> From: Joe Touch Message-ID: <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> Date: Wed, 19 Jul 2017 11:26:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> Content-Type: multipart/alternative; boundary="------------9C0BC14394BAB7A3C067289C" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:26:51 -0000 This is a multi-part message in MIME format. --------------9C0BC14394BAB7A3C067289C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/14/2017 12:44 AM, Dragoș Niculescu wrote: >>> SOCKSv6 proposal makes use of extra data in the SYN (SOCKS data, and user data), >>> but >>> its correctness and backward compatibility does not depend on TFO, only its RTT >>> performance. >>> In fact, when TFO is not available neither between client and proxy, nor between >>> proxy and >>> server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But TFO is >>> likely to be the most >>> common case in the future - Linux kernel has TFO client side on by default since >>> 3.12 >>> (November 2013)[1], and it seems to be the default in all Android phones and >>> default >>> Linux installs. >> What happens with a legacy receiver? >> >> Joe > Legacy receiver will use plain TCP. No - a legacy receiver will interpret the SYN information as user data, which there is no way to "undo". You can't know that you're not talking to a legacy receiver until you receive the SYN-ACK. Even if you cache TFO availability, you could be wrong - the endpoint could reboot or be replaced with a new endpoint, etc. Ultimately, the onus is on you to NEVER poison a TCP connection that could be to a legacy receiver. That's a requirement in RFC793. Joe --------------9C0BC14394BAB7A3C067289C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 7/14/2017 12:44 AM, Dragoș Niculescu wrote:
SOCKSv6 proposal makes use of extra data in the SYN (SOCKS data, and user data),
but
its correctness and backward compatibility does not depend on TFO, only its RTT
performance.
In fact, when TFO is not available neither between client and proxy, nor between
proxy and
server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But TFO is
likely to be the most
common case in the future - Linux kernel has TFO client side on by default since
3.12
(November 2013)[1], and it seems to be the default in all Android phones and
default
Linux installs.

What happens with a legacy receiver?

Joe

Legacy receiver will use plain TCP.

No - a legacy receiver will interpret the SYN information as user data, which there is no way to "undo".

You can't know that you're not talking to a legacy receiver until you receive the SYN-ACK. Even if you cache TFO availability, you could be wrong - the endpoint could reboot or be replaced with a new endpoint, etc.

Ultimately, the onus is on you to NEVER poison a TCP connection that could be to a legacy receiver. That's a requirement in RFC793.
Joe

--------------9C0BC14394BAB7A3C067289C-- From nobody Wed Jul 19 12:23:28 2017 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 E4552129AD3; Wed, 19 Jul 2017 12:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 dsuHGA-kkdpz; Wed, 19 Jul 2017 12:23:25 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 48DE3127078; Wed, 19 Jul 2017 12:23:23 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3ANqY5ahDo/KAxYaIc1q4CUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP37r8+wAkXT6L1XgUPTWs2DsrQf2rWQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbQhFgDiwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VC+85Kl3VhDnlC?= =?us-ascii?q?YHNyY48G7JjMxwkLlbqw+lqxBm3oLYfJ2ZOP94c6jAf90VWHBBU95MWSJfDIOy?= =?us-ascii?q?b4gBAeQPMulXrYbyu0ADogGiCQS2Hu7j1jFFi33w0KYn0+ohCwbG3Ak4Et0BtH?= =?us-ascii?q?Tbtsj6NKYXUeC01qnD0CzNb/dK2Tjj8ofIdA0hquyLULJudcre01QgFwLAjlWR?= =?us-ascii?q?s4zpJTSV1uARs2eF9eVgU/+vhnU7pAFquDSv3toshZLTioIPzVDJ7CN0y5s2K9?= =?us-ascii?q?2gUEN3fNGpHIZKuyyZN4Z6WN0uT39qtSogxLAKoYO3cSsKxZg92hLSa/2Kf5KV?= =?us-ascii?q?7h79SOqdOzR1iG5jdbminRi961Kgxff5VsSs1VZKqTdKncfUu3AW0hzT9tCHSv?= =?us-ascii?q?xg/ke9wTqP1x7c6uVDIU0si6rbLoQuwr80lpYJrUvDBTX6mF3rjKCNbEkk4O+o?= =?us-ascii?q?5/zmYrXguJCcK5d5hhzxP6gzgMCyAuQ1PhIQU2SF++mwzrPu8VX8QLpQj/02lq?= =?us-ascii?q?fZsIrdJcQevqO5HQtV3Zw+5Ba+Cjem0c4YkWMALFJBZBKIkZLmO1fTIP3jEfi/?= =?us-ascii?q?mE6gkC92x//dJLHhGJLNImDZkLj9ZbZ991JcyA0rwN9C/JJbFrEBIPP1WkDrtd?= =?us-ascii?q?3YDwQ0PBasw+b/DNVyyJkSVn6IAq+cKKnSq0OH5vozI+mQY48YoDXzK/455/L3?= =?us-ascii?q?l3A5g0EScrOy0JsWdn+4AvpmL1+eYXr2jdcLCX0KsRYmTOz2lF2CViZeZ3OvX6?= =?us-ascii?q?I4+jE7CZqmAp3fRoCtnLyOwD+7E4ZXZm9YFlCMH23kd4KeW/cDcCiSONNukiQY?= =?us-ascii?q?Vbi9TI8szQ2utAjny7V7LurZ4SwYtYni1NRv+eLciAwy/yRuD8uBy2GNU310nm?= =?us-ascii?q?QQSj8z26B/oVZyylKd3qdlmfBXDttT5+5VXQggKJHT1e16C8rpVwLGZNeGUlCm?= =?us-ascii?q?Qtq4Dj0rUt0xxNoOMA5BHICAiR2L4y23CL9dw6CMGZc02qPH3j78K9srjz7qzq?= =?us-ascii?q?AuiLsRZMpEKGmrnaViv1zfHYfGlF7fkaehaKARxyXQ3GyYi3KTtgdCV1gjf7/C?= =?us-ascii?q?WCUhYkLarNH4/AvlS6OjALI6el9fzceOK65LcJvuiUlLTfH+EN/FJXqskSGqAk?= =?us-ascii?q?Dblfu3cIP2djBFj23mA08enlVWpC7eOA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2A7AwBmsG9ZRwPjVY1cDg0BAQEDAQEBC?= =?us-ascii?q?QEBARYBAQEDAQEBCQEBAZQlkFEimBWFRwKEOQEBAQEBAQEBAgEFAQEzWIIzJAG?= =?us-ascii?q?CQQEFI0oMEAsEFCoCAkMUBgEMCAEBii+zJoImJ4p2AQEBAQEBAQMBAQEBAQEBA?= =?us-ascii?q?QEBAR2DKINNggwLgm6EVIMpgmEFkV+NWoImpCOVWgJWgQsxIYYUHIEoQooTAQE?= =?us-ascii?q?B?= X-IPAS-Result: =?us-ascii?q?A2A7AwBmsG9ZRwPjVY1cDg0BAQEDAQEBCQEBARYBAQEDAQE?= =?us-ascii?q?BCQEBAZQlkFEimBWFRwKEOQEBAQEBAQEBAgEFAQEzWIIzJAGCQQEFI0oMEAsEF?= =?us-ascii?q?CoCAkMUBgEMCAEBii+zJoImJ4p2AQEBAQEBAQMBAQEBAQEBAQEBAR2DKINNggw?= =?us-ascii?q?Lgm6EVIMpgmEFkV+NWoImpCOVWgJWgQsxIYYUHIEoQooTAQEB?= X-IronPort-AV: E=Sophos;i="5.40,381,1496091600"; d="scan'208,217";a="1111131" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 19 Jul 2017 22:23:19 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 80DC21A6014C; Wed, 19 Jul 2017 22:23:19 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id L4owHU7GrhcW; Wed, 19 Jul 2017 22:23:19 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 5F6D21A61C08; Wed, 19 Jul 2017 22:23:19 +0300 (EEST) Received: from painkiller.localdomain (unknown [185.156.120.80]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id C4B041A6014C; Wed, 19 Jul 2017 22:23:18 +0300 (EEST) To: Joe Touch , =?UTF-8?Q?Drago=c8=99_Niculescu?= Cc: mohamed boucadair , David Schinazi , multipathtcp , int-area References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> From: Vladimir Olteanu Message-ID: Date: Wed, 19 Jul 2017 22:23:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> Content-Type: multipart/alternative; boundary="------------9C4C7B278A2763B8E578AF50" Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:23:27 -0000 This is a multi-part message in MIME format. --------------9C4C7B278A2763B8E578AF50 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 07/19/2017 09:26 PM, Joe Touch wrote: > > > > On 7/14/2017 12:44 AM, Drago=C8=99 Niculescu wrote: >>>> SOCKSv6 proposal makes use of extra data in the SYN (SOCKS data, and= user data), >>>> but >>>> its correctness and backward compatibility does not depend on TFO, o= nly its RTT >>>> performance. >>>> In fact, when TFO is not available neither between client and proxy,= nor between >>>> proxy and >>>> server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But = TFO is >>>> likely to be the most >>>> common case in the future - Linux kernel has TFO client side on by d= efault since >>>> 3.12 >>>> (November 2013)[1], and it seems to be the default in all Android ph= ones and >>>> default >>>> Linux installs. >>> What happens with a legacy receiver? >>> >>> Joe >> Legacy receiver will use plain TCP. > > No - a legacy receiver will interpret the SYN information as user=20 > data, which there is no way to "undo". > > You can't know that you're not talking to a legacy receiver until you=20 > receive the SYN-ACK. Even if you cache TFO availability, you could be=20 > wrong - the endpoint could reboot or be replaced with a new endpoint, e= tc. > > Ultimately, the onus is on you to NEVER poison a TCP connection that=20 > could be to a legacy receiver. That's a requirement in RFC793. > Joe > I think there's a misunderstanding here. SOCKSv6 runs strictly on top of=20 TCP. The "user data" to which we're referring is data meant to be=20 relayed by the proxy to the server. The SYN's payload (both SOCKS=20 request and said user data) is irrevocably part of the client-proxy data=20 stream and we do not change it retroactively after learning that the=20 proxy does not support TFO. Vlad --------------9C4C7B278A2763B8E578AF50 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/19/2017 09:26 PM, Joe Touch wrote:



On 7/14/2017 12:44 AM, Drago=C8=99 Niculescu wrote:
SOCKSv6 proposal makes use of extra data in th=
e SYN (SOCKS data, and user data),
but
its correctness and backward compatibility does not depend on TFO, only i=
ts RTT
performance.
In fact, when TFO is not available neither between client and proxy, nor =
between
proxy and
server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But TFO i=
s
likely to be the most
common case in the future - Linux kernel has TFO client side on by defaul=
t since
3.12
(November 2013)[1], and it seems to be the default in all Android phones =
and
default
Linux installs.

What happens with a legacy receiver?

Joe

Legacy receiver will use plain TCP.

No - a legacy receiver will interpret the SYN information as user data, which there is no way to "undo".

You can't know that you're not talking to a legacy receiver until you receive the SYN-ACK. Even if you cache TFO availability, you could be wrong - the endpoint could reboot or be replaced with a new endpoint, etc.

Ultimately, the onus is on you to NEVER poison a TCP connection that could be to a legacy receiver. That's a requirement in RFC793.
Joe

I think there's a misunderstanding here. SOCKSv6 runs strictly on top of TCP. The "user data" to which we're referring is data meant to be relayed by the proxy to the server. The SYN's payload (both SOCKS request and said user data) is irrevocably part of the client-proxy data stream and we do not change it retroactively after learning that the proxy does not support TFO.

Vlad
--------------9C4C7B278A2763B8E578AF50-- From nobody Wed Jul 19 12:41:21 2017 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 AE880126DC2; Wed, 19 Jul 2017 12:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 x6oY_ruhU6uT; Wed, 19 Jul 2017 12:41:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C765128A32; Wed, 19 Jul 2017 12:41:18 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJekWA007395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:40:47 -0700 (PDT) To: Vladimir Olteanu , =?UTF-8?Q?Drago=c8=99_Niculescu?= Cc: mohamed boucadair , David Schinazi , multipathtcp , int-area References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> From: Joe Touch Message-ID: <2ff22633-8f12-f4ef-868f-9c6c698ae32f@isi.edu> Date: Wed, 19 Jul 2017 12:40:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:41:20 -0000 On 7/19/2017 12:23 PM, Vladimir Olteanu wrote: > I think there's a misunderstanding here. SOCKSv6 runs strictly on top > of TCP. OK, so to clarify - TCP is between the two SOCKS endpoints. The user data travels over SOCKS. Can you confirm that's correct? > The "user data" to which we're referring is data meant to be relayed > by the proxy to the server. The SYN's payload (both SOCKS request and > said user data) is irrevocably part of the client-proxy data stream > and we do not change it retroactively after learning that the proxy > does not support TFO. If the above is correct, then it would be useful to NEVER speak of "putting data in the SYN payload". You simply don't have that control. The interface to TCP *allows* pending "user" (as in TCP user, which in this case is the SOCKS layer) data to be placed in the SYN, but never requires it. So you can talk about putting information in the SOCKS stream, but shouldn't be referring to individual TCP segments. Joe From nobody Wed Jul 19 17:32:43 2017 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 584F612EC39; Wed, 19 Jul 2017 17:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 5A_E1yTHWbbc; Wed, 19 Jul 2017 17:32:39 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 860C212EC06; Wed, 19 Jul 2017 17:32:37 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3ABzmxzB0sLMkELDVjsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?sesWIvnxwZ3uMQTl6Ol3ixeRBMOAuq0C07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9ZDeZwdFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD?= =?us-ascii?q?8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfFjfK3SYMkaSHJcUMhPWSxPAoCy?= =?us-ascii?q?YYUBAOUOP+lXs4bzqkASrRa8HwSgGP/jxzFKi3LwwKY00/4hEQbD3AE4EN0OtG?= =?us-ascii?q?7bo8j0NKcXUOC11rTDwyzHb/NKxzjy8o7Icg08qvyLQ7JwddDexlQuFwPAj1WQ?= =?us-ascii?q?s5bpPzSR1uQRrWeU9exgVf+0hmE7sAF9uCCvxto3hYXTnIIVzUnJ+CNky4g2Pd?= =?us-ascii?q?21UFN3bNG5HJdKtCyXN5F6Tt08T2xqoio3xKUKtYO4cSUK0pgr2h7SZv2df4SV?= =?us-ascii?q?/B7vSPydLDRkiH9jZbmxnQy98VK6xe35TsS01VFKoTdbndTUrXAN0gDT6tCASv?= =?us-ascii?q?tg4ketwTaP2B7X6uFDOU00i6/bJIQgwr40jJYcrV/DEjXumEXrl6CabF8k+u+w?= =?us-ascii?q?5+TmZLXpuIOcOpdphgzxL6gigM+yDOQiPgQQQWSW+/6w2bP78U38WrpKj/k2kq?= =?us-ascii?q?fDsJDdIMQWvrC5AwtP3Yk+6ha/Cjam0M4CkXkAKFJFZAyIgJLvO1HTO/33Eey/?= =?us-ascii?q?j060kDd23P/KJKfhApLVInjZjLjhZap961JbyAcr0N9f/I5bCrEAIPL1QEDwtd?= =?us-ascii?q?3YAwQjPAys2+bnDMty2pkCVmKIB6+TKLnSvkOQ5uIzP+mMY5cYtjX7K/g5/vLh?= =?us-ascii?q?l2U5lkEHcqSy3JsYdmy4Hvp8L0Wee3rsjc8LEX0WsQomUOzqlFqCXCZWZ3avW6?= =?us-ascii?q?I8+jA7CJq8AoffRoCtnKCO3D+gE51XeG9GFl6MHW3vd4WeVPcGcDiSLdN5kjwY?= =?us-ascii?q?SbihTJcs1Q2ptA/n17VnLvHZ+iwDtZLiztR6+fDclQwq/zxuE8udy32NT31znm?= =?us-ascii?q?4QQj8226B/rlZ4ylidzKd0medXFdtO5/xVSAg1KITTz+1gC93pXQLBZM2GSFCp?= =?us-ascii?q?Qtq4Gz0+UtUxw9pdK3p6Tvelg1j/2DehA/dBi7uWD5wc87ndmXX9OpA5g1rc3a?= =?us-ascii?q?YmbW4AQ8BSMWC9jbM3owTJDoHOiAOflq23cakH1zPl/3zF1XeE+ltfBl1eS6LA?= =?us-ascii?q?CE4bb0fXqNXjrmTGU7KnD6lvZhVFwMKDL6pQLNrtkVhPQurLM8+Ye3+73X23U0?= =?us-ascii?q?XbjoiQZZbnLj1OlB7WD1IJxkVKpS6L?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CqAQBX+W9ZRwPjVY1cDgwBAQEBAgEBA?= =?us-ascii?q?QEIAQEBARUBAQEBAgEBAQEIAQEBAZQlkHSYFYVHAoQ6AQEBAQEBAQECAQUBATN?= =?us-ascii?q?YgjMkAYJBAQUjFTUMEAsYAgIZDQICQxQGAQwIAQGKL7BygiaLIQEBAQEBBQIBJ?= =?us-ascii?q?YELgh2DTYFgLIJ5hFSDKYJhBZFfjVqCJqQjlVoCVoELMSGGFByBKEKKEwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2CqAQBX+W9ZRwPjVY1cDgwBAQEBAgEBAQEIAQEBARUBAQE?= =?us-ascii?q?BAgEBAQEIAQEBAZQlkHSYFYVHAoQ6AQEBAQEBAQECAQUBATNYgjMkAYJBAQUjF?= =?us-ascii?q?TUMEAsYAgIZDQICQxQGAQwIAQGKL7BygiaLIQEBAQEBBQIBJYELgh2DTYFgLIJ?= =?us-ascii?q?5hFSDKYJhBZFfjVqCJqQjlVoCVoELMSGGFByBKEKKEwEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,382,1496091600"; d="scan'208";a="1167784" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 20 Jul 2017 03:32:32 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 7EE531A60068; Thu, 20 Jul 2017 04:28:11 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LwnkYLLZhSWj; Thu, 20 Jul 2017 04:28:11 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 604551A6007C; Thu, 20 Jul 2017 04:28:11 +0300 (EEST) Received: from painkiller.localdomain (unknown [185.156.120.80]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id EB54E1A60068; Thu, 20 Jul 2017 04:28:10 +0300 (EEST) To: Joe Touch , =?UTF-8?Q?Drago=c8=99_Niculescu?= Cc: mohamed boucadair , David Schinazi , multipathtcp , int-area References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> <2ff22633-8f12-f4ef-868f-9c6c698ae32f@isi.edu> From: Vladimir Olteanu Message-ID: <5c61bf79-5a8f-65cf-e6b7-02a29db37073@cs.pub.ro> Date: Thu, 20 Jul 2017 03:32:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2ff22633-8f12-f4ef-868f-9c6c698ae32f@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 00:32:41 -0000 On 07/19/2017 10:40 PM, Joe Touch wrote: > > On 7/19/2017 12:23 PM, Vladimir Olteanu wrote: >> I think there's a misunderstanding here. SOCKSv6 runs strictly on top >> of TCP. > OK, so to clarify - TCP is between the two SOCKS endpoints. > The user data travels over SOCKS. > Can you confirm that's correct? Yes. >> The "user data" to which we're referring is data meant to be relayed >> by the proxy to the server. The SYN's payload (both SOCKS request and >> said user data) is irrevocably part of the client-proxy data stream >> and we do not change it retroactively after learning that the proxy >> does not support TFO. > If the above is correct, then it would be useful to NEVER speak of > "putting data in the SYN payload". You simply don't have that control. > The interface to TCP *allows* pending "user" (as in TCP user, which in > this case is the SOCKS layer) data to be placed in the SYN, but never > requires it. We're perfectly aware of that. We were only talking about putting data in the SYN for the sake of brevity, because said data is very likely to actually make it into the SYN under typical circumstances. However, you do have a point, especially given that MPTCP-PM and O-RTT converters are being actively discussed and they do require data to be placed in the SYN. > So you can talk about putting information in the SOCKS stream, but > shouldn't be referring to individual TCP segments. > If we were not discussing performance, I would agree with you. However, it's impractical (and not useful, either) to reason about the RTT overhead without making some assumptions about what data goes into which segment. SOCKS 6 is is designed to take advantage of how the stack is likely to split the data into segments in typical use cases. Cheers, Vlad From nobody Wed Jul 19 17:41:29 2017 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 93A9A129A9C; Wed, 19 Jul 2017 17:41:21 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 bzfszydj9qyR; Wed, 19 Jul 2017 17:41:19 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF46B126E64; Wed, 19 Jul 2017 17:41:19 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v6K0em49021035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 17:40:49 -0700 (PDT) To: Vladimir Olteanu , =?UTF-8?Q?Drago=c8=99_Niculescu?= Cc: mohamed boucadair , David Schinazi , multipathtcp , int-area References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> <2ff22633-8f12-f4ef-868f-9c6c698ae32f@isi.edu> <5c61bf79-5a8f-65cf-e6b7-02a29db37073@cs.pub.ro> From: Joe Touch Message-ID: <1cf7caa4-22a2-b61a-662f-8927197baf09@isi.edu> Date: Wed, 19 Jul 2017 17:40:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5c61bf79-5a8f-65cf-e6b7-02a29db37073@cs.pub.ro> Content-Type: multipart/alternative; boundary="------------45623A4508A275C9BB7AECC7" Content-Language: en-US X-MailScanner-ID: v6K0em49021035 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 00:41:22 -0000 This is a multi-part message in MIME format. --------------45623A4508A275C9BB7AECC7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 5:32 PM, Vladimir Olteanu wrote: >> If the above is correct, then it would be useful to NEVER speak of >> "putting data in the SYN payload". You simply don't have that control. >> The interface to TCP *allows* pending "user" (as in TCP user, which in >> this case is the SOCKS layer) data to be placed in the SYN, but never >> requires it. > We're perfectly aware of that. We were only talking about putting data > in the SYN for the sake of brevity, because said data is very likely > to actually make it into the SYN under typical circumstances. > > However, you do have a point, especially given that MPTCP-PM and O-RTT > converters are being actively discussed and they do require data to be > placed in the SYN. And those would fall under the category of attack devices, IMO. I.e., if you're speaking of just an application proxy, then the doc needs to be very clear of that goal AND use only the required TCP "user" API -- which does not have any indication of an arriving SYN (it would only indicate when the connection was established, e.g., after the TWHS completes). If you're speaking of something that rewrites TCP segments directly, then you need to be clear that this is what you intend (and I cannot see how you can do that and be compliant with TCP). >> So you can talk about putting information in the SOCKS stream, but >> shouldn't be referring to individual TCP segments. >> > If we were not discussing performance, I would agree with you. > However, it's impractical (and not useful, either) to reason about the > RTT overhead without making some assumptions about what data goes into > which segment. SOCKS 6 is is designed to take advantage of how the > stack is likely to split the data into segments in typical use cases. You can make some *assumptions* about what might happen, and even talk about ways to configure the outgoing TCP to encourage its putting data in the SYN (e.g., by writing before connecting). However, if we're talking about an application layer proxy, you cannot assume availability of the incoming SYN data unless you also assume TFO - and at best, it's an assumption (your application would never know). I.e., if you do everything right, you MIGHT end up looking "LIKE" you rewrote the TCP SYN as it "passes through", but speaking of that as the actual mechanism violates TCP. So at best, there is need for a significant revision to clear this all up. Joe --------------45623A4508A275C9BB7AECC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/19/2017 5:32 PM, Vladimir Olteanu wrote:
If the above is correct, then it would be useful to NEVER speak of
"putting data in the SYN payload". You simply don't have that control.
The interface to TCP *allows* pending "user" (as in TCP user, which in
this case is the SOCKS layer) data to be placed in the SYN, but never
requires it.
We're perfectly aware of that. We were only talking about putting data in the SYN for the sake of brevity, because said data is very likely to actually make it into the SYN under typical circumstances.

However, you do have a point, especially given that MPTCP-PM and O-RTT converters are being actively discussed and they do require data to be placed in the SYN.

And those would fall under the category of attack devices, IMO.

I.e., if you're speaking of just an application proxy, then the doc needs to be very clear of that goal AND use only the required TCP "user" API -- which does not have any indication of an arriving SYN (it would only indicate when the connection was established, e.g., after the TWHS completes).

If you're speaking of something that rewrites TCP segments directly, then you need to be clear that this is what you intend (and I cannot see how you can do that and be compliant with TCP).

So you can talk about putting information in the SOCKS stream, but
shouldn't be referring to individual TCP segments.

If we were not discussing performance, I would agree with you. However, it's impractical (and not useful, either) to reason about the RTT overhead without making some assumptions about what data goes into which segment. SOCKS 6 is is designed to take advantage of how the stack is likely to split the data into segments in typical use cases.

You can make some *assumptions* about what might happen, and even talk about ways to configure the outgoing TCP to encourage its putting data in the SYN (e.g., by writing before connecting). However, if we're talking about an application layer proxy, you cannot assume availability of the incoming SYN data unless you also assume TFO - and at best, it's an assumption (your application would never know).

I.e., if you do everything right, you MIGHT end up looking "LIKE" you rewrote the TCP SYN as it "passes through", but speaking of that as the actual mechanism violates TCP.

So at best, there is need for a significant revision to clear this all up.

Joe

--------------45623A4508A275C9BB7AECC7-- From qzy888@gmail.com Thu Jul 20 00:16:00 2017 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 45071131D04 for ; Thu, 20 Jul 2017 00:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CsqGYfMUKTbH for ; Thu, 20 Jul 2017 00:15:59 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5505F131D0B for ; Thu, 20 Jul 2017 00:15:41 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 35so16532178uax.3 for ; Thu, 20 Jul 2017 00:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=o7f7UI4igTK7yEhrNXRFimpcyCttvzDFha2lTnLu7F0=; b=VuRazhefBTRu88D0BJZMI95UVf6pKm2MMhm4v4dgJh11zTkHhmi0ZtOcmSErGH38pF rLTZVhqijNJdJk3GEYcaDfQZV0PsijMSoslZDk6MH/eGrM9YcCtsdywVEYTKLxSkdG+c YA+xkszlPZQJScjn6mwB0bLobQzk9kQM4h5QLgown3p4VSneQNK8W+7mF6ADfu+vO9g/ yL1RAsOIqQbCNx2vrTM3w62/dgS4unBnlaVNhzxY8141Z4gAXWHnbwl6MC9f+nNZNbUL BSI9SV+/TUvY4bC9ZTrUj17z38Q1j+EEb1dH2uPk7zPTykiPqGNDJ1J71hY+oeg0z/iR Kyjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=o7f7UI4igTK7yEhrNXRFimpcyCttvzDFha2lTnLu7F0=; b=E/OOkNH4rKjnyTpXVlV7z3xRwjY8BA5ouXpsoy/uV1n3Aw/VvbBjj89Kx8ZlFbsxlb KNZm1MHlkhG3jz6DzWgSifBejAPa0m8neQhmHeL2LebDPi/JBkJ5FSt6QsCGJQrDrQEg loGrB8g9rOnMPnuBAobSE/SDbt9W1tTHqiqrqUA/7jNsemo/Ktp1Wh3OpWccf2c4OCop 2jCEo+zQzepNIOtYG0F3D44uQgZkTGvSbs20V0jQPO5lFY6kpuX2gif2r3UA/wOjchBh BoiaWlkQa6bvaXXW3Bwq/EgCzmHabgNon142DSeH+Et9RJlyysbPS4kWZRhgPQ2Oxj5P 2MUw== X-Gm-Message-State: AIVw113vdzzenp8RaW1baFJQ2pBljnWy4aPpnjCYwSSPKVGMrutJ92Ez WPLezYSatpfByzH4uszasjKMZ9i64tJs X-Received: by 10.31.159.201 with SMTP id i192mr1393337vke.116.1500534940130; Thu, 20 Jul 2017 00:15:40 -0700 (PDT) MIME-Version: 1.0 Sender: qzy888@gmail.com Received: by 10.103.149.65 with HTTP; Thu, 20 Jul 2017 00:15:39 -0700 (PDT) From: Zhiyun Qian Date: Thu, 20 Jul 2017 00:15:39 -0700 X-Google-Sender-Auth: KolM8jBEwMTPOca4SkZfFFLEoTw Message-ID: To: multipathtcp@ietf.org Cc: Ali Munir , Zubair , Alex Liu , Franck Le , Olivier Bonaventure Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:17:48 -0000 Dear all, We are a group of researchers (cc:ed on the email) who recently discovered a security flaw in the MP_PRIO messge that allows a man-in-the-middle attacker on a single path to divert all traffic to its own path, effectively hijacking the entire MPTCP connection. Below we describe the problem in brief (more details will be found in our upcoming ICNP paper. We also hope to submit an Internet draft soon). We thank Olivier Bonaventure for his valuable feedback. --------------------------------------------------------------- MPTCP supports using sub-connections as backup =E2=80=93 i.e., using a sub-connection to send data only if there is no other sub-connection available. Specifically, an MPTCP host can send a request to the other host to set any sub-connection as a backup by using the MPTCP MP_PRIO option. Hosts can request change in the priority to use a subconnection as regular or backup. To set a sub-connection as backup, a host can request a change in the sub-connection priority by sending MPTCP MP_PRIO option to the other host with the corresponding address identifier. The key property of MP_PRIO messages is that they can be sent on any sub-connection. The reason is that if a sub-connection is already congested, it may not be possible to deliver the message to pause itself. After receiving such a control packet, the sender will stop sending data and the corresponding sub-connection=E2=80=99s throughput will drop to zero. Unfortunately, unlike MP_JOIN, such a MP_PRIO option has no authentication required by the specification whatsoever, allowing an attacker controlling only one path to set any sub-connection as backup and launch traffic divergence and connection hijack attacks. The backup flag vulnerability allows an attacker to divert traffic among MPTCP sub-connections. An attacker can offload traffic from the eavesdropped sub-connection to other MPTCP sub-connections by sending forged packets with the MP_PRIO option to set the eavesdropped sub-connection as a backup. An attacker can also onload traffic from non-eavesdropped sub-connections to the eavesdropped sub-connection by sending forged packets with the MP_PRIO option to set all other sub-connections as backup. This attack is similar to connection hijack attack, where an attacker diverts all the traffic to pass through the sub-connection on the eavesdropped path. Connection Hijack Example: Consider a scenario where two sub-connections of an MPTCP connection pass through paths p1 and p2. An attacker can hijack the non-eavesdropped subconnection on p2 by dynamically changing the priority of a sub-connection and declaring it as backup. To launch this attack an attacker only needs to know the address identifier of the host , which can be obtained by eavesdropping other paths or easily guessed as they are set incrementally in current Linux implementation of MPTCP. Since the identifier has only 8 bits, it can even be brute forced. To set a non-eavesdropped sub-connection as backup between hosts A and B, an attacker can request a change in the sub-connection priority by sending MPTCP MP_PRIO option to host B with the address identifier of host A. Since by design the MP_PRIO messages can be sent on any sub-connection, the attacker eavesdropping on any path capable of sending such a forged backup message can pause any other path. Note that a backup MPTCP sub-connection may still be used for data transmission later, which can be detected by the attacker by observing the overall MPTCP throughput. Effectively, this attack degrades an MPTCP connection to a regular TCP connection as all traffic will be routed through the attacker-controlled path. We argue that this vulnerability makes MPTCP less secure than TCP, because the entire MPTCP connection can be compromised (fully controlled by an attacker) as long as any one of the communication paths is compromised. Unfortunately, MPTCP specification does not include any authentication mechanism whatsoever regarding the MP_PRIO message. We discuss several solutions in a forthcoming paper [ICNP2017], but a simple approach to cope with this attack would be to reconsider the utilisation of the address identifier in the MP_PRIO option. This option allows a host to set/change the priority of all the subflows associated to a given address identifier on another subflow. It could have use cases, such as sending MP_PRIO over a WiFi subflow to put the cellular subflow in backup mode without sending a packet over the cellular interface, but this looks like an edge case. Looking at the attack that we have identified, the working group should evaluate the removal of the address identifier in rfc6824bis. If the MP_PRIO option does not include an address identifier, then it becomes impossible for an attacker who is on-path of a given subflow to change the priority of the other subflows. Best, -Zhiyun From nobody Thu Jul 20 00:22:37 2017 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 71E97126CD6; Thu, 20 Jul 2017 00:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 3bfLKOaiB3B1; Thu, 20 Jul 2017 00:22:28 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 97476126557; Thu, 20 Jul 2017 00:22:27 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AOy5rghPo6oAwy3WbqoAl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0I/j7rarrMEGX3/hxlliBBdydsKMbzbKO+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFKiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPde?= =?us-ascii?q?RWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbY?= =?us-ascii?q?UwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0vRz+s87lkRwPpiC?= =?us-ascii?q?cfNj427mfXitBrjKlGpB6tvgFzz5LIbI2QMvd1Y6HTcs4ARWdZUMhfVzJPDIC+?= =?us-ascii?q?YIsBEuQOMvpXoYb6qVsStha+GRCsC//zxjJSmnP736s32PkhHwHc2wwgGsoDvn?= =?us-ascii?q?rOrNrvO6cSVuC3x7TQwzXCc/xWxDP955bTch89vPGHQLV9ftfLyUY1GAPFiU6Q?= =?us-ascii?q?pZbjPzOUyusNrmyb4PR7Ve2zlm4qsB1+oiO1ysc0l4nGnZgZykrD9Shgxos+ON?= =?us-ascii?q?O2SEl+YdG+EZtQsTmXN4R3QsM+Q2FopT01xqcatp68eSgG0JUnyADDa/yJaYSI?= =?us-ascii?q?5QjjVOmXLDxlh3xlYKqyiwu9/ES90OHxVcm53ExUoiZbkNTArH4A2hrO4cadUP?= =?us-ascii?q?R95F2u2TOX2gDW7eFLPF47mLLAK54k3r4wjp0TsVnfHiPumEX5kquWdkI89+i2?= =?us-ascii?q?7uToeLTmppuGO4BokQHyKLwumtGkDugiKAgOWHCX+eW61LL94U30WKhGg/Irnq?= =?us-ascii?q?XDs53XJd4XqrCnDwJXyIou5Q6zDzK839QZmXkHIkhFeBWCj4XxJl7OOur3Dfi4?= =?us-ascii?q?g1S3ijtrwfHGMaH8ApXJMHfDi6vufatm5kFA0wo/18hf549PBb0bOvLzXVf9tM?= =?us-ascii?q?bEAR8hLwy03+HnBc1+2IMYRWKDG7WWMLnMvlCS/e8vIveDZJMbuDrnLPgl/fHu?= =?us-ascii?q?h2cjmVABZampwYcXaHegE/RjPkWZZWbsgtYZEWgQogo+TPDqh0GaUTNIZna9Qb?= =?us-ascii?q?485j8hBIKhF4fDSZingKad0yejAp1WemdGB0iQEXfvaoWLR/cMZTmTIs96kzwI?= =?us-ascii?q?T6auRJI81ULmiAiv6b1qZtbT5yYY/cb/08V+58XSjhB0+DBpWZezyWaIGk1ul2?= =?us-ascii?q?wPpXcQ3atipUFmwUrLhaRiivNfDppV5vhUVgohPoP0xPc8E834HBjGKITaAG26?= =?us-ascii?q?S8mrVGliBuk6xMUDNgMkQ42v?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CHBgC/WXBZRwPjVY1cDg8BBQELARgBB?= =?us-ascii?q?QELAYQTgRSOfpBSIpgWLoUZAoRCAQEBAQEBAQECAQUBATNYgjMkAYJBAQMBASN?= =?us-ascii?q?WBQsCAQgaAg0ZAgJDFAIEijoMDLBugiaLIAEBCAIBIAWBC4IdhS42gm6EVBaDE?= =?us-ascii?q?4JhBZFiAY1bh0ufA5VcAlaBC1KHWEJzAYl5AQEB?= X-IPAS-Result: =?us-ascii?q?A2CHBgC/WXBZRwPjVY1cDg8BBQELARgBBQELAYQTgRSOfpB?= =?us-ascii?q?SIpgWLoUZAoRCAQEBAQEBAQECAQUBATNYgjMkAYJBAQMBASNWBQsCAQgaAg0ZA?= =?us-ascii?q?gJDFAIEijoMDLBugiaLIAEBCAIBIAWBC4IdhS42gm6EVBaDE4JhBZFiAY1bh0u?= =?us-ascii?q?fA5VcAlaBC1KHWEJzAYl5AQEB?= X-IronPort-AV: E=Sophos;i="5.40,382,1496091600"; d="scan'208";a="1190261" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 20 Jul 2017 10:22:25 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 9E1421A6215B; Thu, 20 Jul 2017 10:22:25 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SdHSvMI0-Qmz; Thu, 20 Jul 2017 10:22:25 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 84AEB1A62153; Thu, 20 Jul 2017 10:22:25 +0300 (EEST) Received: from vmail.cs.pub.ro (vmail.cs.pub.ro [141.85.227.3]) by vmail.cs.pub.ro (Postfix) with ESMTP id 817C71A6213C; Thu, 20 Jul 2017 10:22:25 +0300 (EEST) Date: Thu, 20 Jul 2017 10:22:23 +0300 (EEST) From: =?utf-8?Q?Drago=C8=99?= Niculescu To: Joe Touch Cc: Vladimir Olteanu , multipathtcp , int-area Message-ID: <1332604938.42424.1500535343962.JavaMail.zimbra@cs.pub.ro> In-Reply-To: <1cf7caa4-22a2-b61a-662f-8927197baf09@isi.edu> References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> <2ff22633-8f12-f4ef-868f-9c6c698ae32f@isi.edu> <5c61bf79-5a8f-65cf-e6b7-02a29db37073@cs.pub.ro> <1cf7caa4-22a2-b61a-662f-8927197baf09@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC59 (Mac)/8.6.0_GA_1194) Thread-Topic: SOCKS 6 Draft Thread-Index: q00KtaTafiwDIx57FOk/wqLMVoGq8A== Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:22:30 -0000 >=20 > I.e., if you're speaking of just an application proxy, then the doc > needs to be very clear of that goal AND use only the required TCP "user" > API -- which does not have any indication of an arriving SYN (it would > only indicate when the connection was established, e.g., after the TWHS > completes). >=20 SOCKSv6 is an application proxy, just as SOCKSv4 and SOCKSv5.=20 This means you can use it with standard TCP API. But it also understands TF= O, and if one client wishes lower RTT, he needs to use TFO API. I think thi= s is pretty clear from the figures in the slides [1], and is the way we are= currently implementing it [2]. I think the discussion here is not different from discussions when TFO was= adopted: everything works as before with standard API, but you need setsoc= kopt and connect with data if you have idempotent data and want lower RTT. = =20 > If you're speaking of something that rewrites TCP segments directly, > then you need to be clear that this is what you intend (and I cannot see > how you can do that and be compliant with TCP). >=20 We are not talking about this in SOCKSv6.=20 >=20 > You can make some *assumptions* about what might happen, and even talk > about ways to configure the outgoing TCP to encourage its putting data > in the SYN (e.g., by writing before connecting). However, if we're > talking about an application layer proxy, you cannot assume availability > of the incoming SYN data unless you also assume TFO - and at best, it's > an assumption (your application would never know). >=20 There are two points here. First, the application NEEDS TO know, because it= needs to decide whether to use TFO API, or classic API(legacy apps will be= classic API, of course). Second, for SOCKS (v4, v5, or v6), there is the r= equest data which can be put in SYN, even if the user uses classic API, but= this is a proxy implementation issue, and our current specification does n= ot preclude or force this. =20 > I.e., if you do everything right, you MIGHT end up looking "LIKE" you > rewrote the TCP SYN as it "passes through", but speaking of that as the > actual mechanism violates TCP. It looks like that IF the client has idempotent data, and IF the client use= s TFO API, and IF the proxy enables TFO as a client and as a server, and IF= the actual server supports TFO. So, there are a lot of IFs to get that kin= d of performance, but as shown in slide 9 of the presentation [1], it does = work with standard API, only twice as slow. =20 --=20 Drago=C8=99 [1] https://www.ietf.org/proceedings/99/slides/slides-99-intarea-socks6-00.= pdf [2] https://github.com/45G/shadowsocks-libev From nobody Thu Jul 20 00:28:55 2017 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 268E1126B72 for ; Thu, 20 Jul 2017 00:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 DrNDGvRbrfQ0 for ; Thu, 20 Jul 2017 00:28:52 -0700 (PDT) Received: from lists.cs.ucr.edu (fenris.cs.ucr.edu [169.235.30.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17FA126557 for ; Thu, 20 Jul 2017 00:28:52 -0700 (PDT) Received: from webmail.cs.ucr.edu (localhost [127.0.0.1]) by lists.cs.ucr.edu (Postfix) with ESMTP id 0E06A2C0592; Thu, 20 Jul 2017 00:28:52 -0700 (PDT) Received: from 66.215.234.244 (SquirrelMail authenticated user zhiyunq) by webmail.cs.ucr.edu with HTTP; Thu, 20 Jul 2017 00:28:52 -0700 Message-ID: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> Date: Thu, 20 Jul 2017 00:28:52 -0700 From: "Zhiyun Qian" To: multipathtcp@ietf.org Cc: "Ali Munir" , "Zubair" , "Alex Liu" , "Franck Le" , "Olivier Bonaventure" User-Agent: SquirrelMail/1.4.22-16.el7 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:28:54 -0000 Dear all, We are a group of researchers (cc:ed on the email) who recently discovered a security flaw in the MP_PRIO messge that allows a man-in-the-middle attacker on a single path to divert all traffic to its own path, effectively hijacking the entire MPTCP connection. Below we describe the problem in brief (more details will be found in our upcoming ICNP paper. We also hope to submit an Internet draft soon). We thank Olivier Bonaventure for his valuable feedback. --------------------------------------------------------------- MPTCP supports using sub-connections as backup i.e., using a sub-connection to send data only if there is no other sub-connection available. Specifically, an MPTCP host can send a request to the other host to set any sub-connection as a backup by using the MPTCP MP_PRIO option. Hosts can request change in the priority to use a subconnection as regular or backup. To set a sub-connection as backup, a host can request a change in the sub-connection priority by sending MPTCP MP_PRIO option to the other host with the corresponding address identifier. The key property of MP_PRIO messages is that they can be sent on any sub-connection. The reason is that if a sub-connection is already congested, it may not be possible to deliver the message to pause itself. After receiving such a control packet, the sender will stop sending data and the corresponding sub-connections throughput will drop to zero. Unfortunately, unlike MP_JOIN, such a MP_PRIO option has no authentication required by the specification whatsoever, allowing an attacker controlling only one path to set any sub-connection as backup and launch traffic divergence and connection hijack attacks. The backup flag vulnerability allows an attacker to divert traffic among MPTCP sub-connections. An attacker can offload traffic from the eavesdropped sub-connection to other MPTCP sub-connections by sending forged packets with the MP_PRIO option to set the eavesdropped sub-connection as a backup. An attacker can also onload traffic from non-eavesdropped sub-connections to the eavesdropped sub-connection by sending forged packets with the MP_PRIO option to set all other sub-connections as backup. This attack is similar to connection hijack attack, where an attacker diverts all the traffic to pass through the sub-connection on the eavesdropped path. Connection Hijack Example: Consider a scenario where two sub-connections of an MPTCP connection pass through paths p1 and p2. An attacker can hijack the non-eavesdropped subconnection on p2 by dynamically changing the priority of a sub-connection and declaring it as backup. To launch this attack an attacker only needs to know the address identifier of the host , which can be obtained by eavesdropping other paths or easily guessed as they are set incrementally in current Linux implementation of MPTCP. Since the identifier has only 8 bits, it can even be brute forced. To set a non-eavesdropped sub-connection as backup between hosts A and B, an attacker can request a change in the sub-connection priority by sending MPTCP MP_PRIO option to host B with the address identifier of host A. Since by design the MP_PRIO messages can be sent on any sub-connection, the attacker eavesdropping on any path capable of sending such a forged backup message can pause any other path. Note that a backup MPTCP sub-connection may still be used for data transmission later, which can be detected by the attacker by observing the overall MPTCP throughput. Effectively, this attack degrades an MPTCP connection to a regular TCP connection as all traffic will be routed through the attacker-controlled path. We argue that this vulnerability makes MPTCP less secure than TCP, because the entire MPTCP connection can be compromised (fully controlled by an attacker) as long as any one of the communication paths is compromised. Unfortunately, MPTCP specification does not include any authentication mechanism whatsoever regarding the MP_PRIO message. We discuss several solutions in a forthcoming paper [ICNP2017], but a simple approach to cope with this attack would be to reconsider the utilisation of the address identifier in the MP_PRIO option. This option allows a host to set/change the priority of all the subflows associated to a given address identifier on another subflow. It could have use cases, such as sending MP_PRIO over a WiFi subflow to put the cellular subflow in backup mode without sending a packet over the cellular interface, but this looks like an edge case. Looking at the attack that we have identified, the working group should evaluate the removal of the address identifier in rfc6824bis. If the MP_PRIO option does not include an address identifier, then it becomes impossible for an attacker who is on-path of a given subflow to change the priority of the other subflows. Best, -Zhiyun From nobody Thu Jul 20 08:00:33 2017 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 41427131891 for ; Thu, 20 Jul 2017 08:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2Bw9e_aqgk8d for ; Thu, 20 Jul 2017 08:00:30 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3405A12EC46 for ; Thu, 20 Jul 2017 08:00:29 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id t3so2869778wme.2 for ; Thu, 20 Jul 2017 08:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yoEWzaGVwg/YVTk+oGB2ZTp33GfE8gNNlqDq9kJkCyE=; b=ETzjx81+q2jgRFzt6QLvR+pKValB6DII9oWoaM2BCkTgz5UgUcQUQQXspy4V+i2eD1 BZiMt7ex+sGnHBD8M3HI7VRaB2/Y0g2f5enSuRIzVJsCGMPih6aAaB2LNA100M7NriP3 f8TYjdI1sObJ9Q//J48Jg4D7UIrZ9LxTSFK6bTxxx9X9MGi1S/yc4ABcq1S+Miqnkwr4 GBUpoyk/qk/mG/8GNbm9JFKsO8V1fY2OQD6iVuKBUzGObs5pT4BdQhFctI6Ya7HvFCkM bbGFCoPFQjiYG7N5K3wGnu3Z0J2BtSSskZxd+jED6pJLM9rhoSrrK1B0VxuMaNoPqX8m 11Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yoEWzaGVwg/YVTk+oGB2ZTp33GfE8gNNlqDq9kJkCyE=; b=ovGzBa+PYfKK7VF5kHxJW3weokUgIppWWjyoCaj9fyc3CglJIbLacNGgqhSbeG1SPp lYv9aMr0mPH1x31iXeoOF/x0auMmT9WZ/HYJ05PlMDExF1m8YGZXkV4LbZ3RLLC/GEXE vYycQm4M/Ws6wHFBv7jDcgNFL6qJuxYPDn9vpNwCVLA6Mbfc0f4s8dfoISuXFTGFGYzT cZVC5PW3mJ+EFu8Ycnrf0dKH7LRTSCcQms7tj4doFemygzApbZRrAt0E5cXDeJvrNqQ+ YHxWqAd+28DNATQRai3ZIE6pzVCaj+FLCY+apdZyFflRF8uuHGAy1RvbLUve/E9DdVxN Hctg== X-Gm-Message-State: AIVw110Fg715teiCO5PXO2A7Fw6aHoz7J2pm/hiF6Wk0tvoRuK/NgvT9 SGsnIGstnvgjcHMKsiE7uA== X-Received: by 10.28.125.195 with SMTP id y186mr2728642wmc.37.1500562827635; Thu, 20 Jul 2017 08:00:27 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:a890:6285:c91d:ca3e? ([2001:67c:370:128:a890:6285:c91d:ca3e]) by smtp.gmail.com with ESMTPSA id i136sm2338850wmf.33.2017.07.20.08.00.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Jul 2017 08:00:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: Alan Ford X-Priority: 3 (Normal) In-Reply-To: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> Date: Thu, 20 Jul 2017 16:00:25 +0100 Cc: multipathtcp@ietf.org, Zubair , Franck Le , Alex Liu , Ali Munir Content-Transfer-Encoding: quoted-printable Message-Id: <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> To: Zhiyun Qian X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:00:32 -0000 Hi Zhiyun, Please bear in mind that the goal of MPTCP with respect to security, as = discussed in the original architectural design in RFC6182, is to provide = a security model no worse than TCP. So whilst this attack would be = possible, it can only be done by an on-path attacker, and if succeeded = would allow the on-path attacker to intercept all traffic. Which would = be the same for a single-path TCP connection on the same path. As a side point, the same kind of attack could be launched via = REMOVE_ADDR messages, but this would not succeed since this is specified = with some protection - ensuring the subflow is really unavailable = through the use of TCP keepalive signals. This same protection cannot be = used against the MP_PRIO since the referenced subflow is not = unavailable. If the WG considered this risk worth addressing, we could look at adding = a nonce + signature to MP_PRIO. Regards, Alan > On 20 Jul 2017, at 08:28, Zhiyun Qian wrote: >=20 > Dear all, >=20 > We are a group of researchers (cc:ed on the email) who recently > discovered a security flaw in the MP_PRIO messge that allows a > man-in-the-middle attacker on a single path to divert all traffic to > its own path, effectively hijacking the entire MPTCP connection. Below > we describe the problem in brief (more details will be found in our > upcoming ICNP paper. We also hope to submit an Internet draft soon). > We thank Olivier Bonaventure for his valuable feedback. >=20 > --------------------------------------------------------------- >=20 > MPTCP supports using sub-connections as backup =96 i.e., using a > sub-connection to send data only if there is no other sub-connection > available. Specifically, an MPTCP host can send a request to the other > host to set any sub-connection as a backup by using the MPTCP MP_PRIO > option. Hosts can request change in the priority to use a > subconnection as regular or backup. To set a sub-connection as > backup, a host can request a change in the sub-connection priority by > sending MPTCP MP_PRIO option to the other host with the corresponding > address identifier. The key property of MP_PRIO messages is that they > can be sent on any sub-connection. The reason is that if a > sub-connection is already congested, it may not be possible to deliver > the message to pause itself. After receiving such a control packet, > the sender will stop sending data and the corresponding > sub-connection=92s throughput will drop to zero. >=20 > Unfortunately, unlike MP_JOIN, such a MP_PRIO option has no > authentication required by the specification whatsoever, allowing an > attacker controlling only one path to set any sub-connection as backup > and launch traffic divergence and connection hijack attacks. The > backup flag vulnerability allows an attacker to divert traffic among > MPTCP sub-connections. An attacker can offload traffic from the > eavesdropped sub-connection to other MPTCP sub-connections by sending > forged packets with the MP_PRIO option to set the eavesdropped > sub-connection as a backup. An attacker can also onload traffic from > non-eavesdropped sub-connections to the eavesdropped sub-connection by > sending forged packets with the MP_PRIO option to set all other > sub-connections as backup. This attack is similar to connection hijack > attack, where an attacker diverts all the traffic to pass through the > sub-connection on the eavesdropped path. >=20 >=20 > Connection Hijack Example: >=20 > Consider a scenario where two sub-connections of an MPTCP connection > pass through paths p1 and p2. An attacker can hijack the > non-eavesdropped subconnection on p2 by dynamically changing the > priority of a sub-connection and declaring it as backup. >=20 > To launch this attack an attacker only needs to know the address > identifier of the host , which can be obtained by eavesdropping other > paths or easily guessed as they are set incrementally in current Linux > implementation of MPTCP. Since the identifier has only 8 bits, it can > even be brute forced. To set a non-eavesdropped sub-connection as > backup between hosts A and B, an attacker can request a change in the > sub-connection priority by sending MPTCP MP_PRIO option to host B with > the address identifier of host A. Since by design the MP_PRIO messages > can be sent on any sub-connection, the attacker eavesdropping on any > path capable of sending such a forged backup message can pause any > other path. Note that a backup MPTCP sub-connection may still be used > for data transmission later, which can be detected by the attacker by > observing the overall MPTCP throughput. >=20 > Effectively, this attack degrades an MPTCP connection to a regular TCP > connection as all traffic will be routed through the > attacker-controlled path. We argue that this vulnerability makes MPTCP > less secure than TCP, because the entire MPTCP connection can be > compromised (fully controlled by an attacker) as long as any one of > the communication paths is compromised. Unfortunately, MPTCP > specification does not include any authentication mechanism whatsoever > regarding the MP_PRIO message. >=20 > We discuss several solutions in a forthcoming paper [ICNP2017], but a > simple approach to cope with this attack would be to reconsider the > utilisation of the address identifier in the MP_PRIO option. This > option allows a host to set/change the priority of all the subflows > associated to a given address identifier on another subflow. It could > have use cases, such as sending MP_PRIO over a WiFi subflow to put the > cellular subflow in backup mode without sending a packet over the > cellular interface, but this looks like an edge case. Looking at the > attack that we have identified, the working group should evaluate the > removal of the address identifier in rfc6824bis. If the MP_PRIO option > does not include an address identifier, then it becomes impossible for > an attacker who is on-path of a given subflow to change the priority > of the other subflows. >=20 > Best, > -Zhiyun >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jul 20 08:05:53 2017 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 3642813146E for ; Thu, 20 Jul 2017 08:05:52 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 YuVJ8YVUGolW for ; Thu, 20 Jul 2017 08:05:50 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9241252BA for ; Thu, 20 Jul 2017 08:05:49 -0700 (PDT) Received: from dhcp-88fc.meeting.ietf.org (dhcp-88fc.meeting.ietf.org [31.133.136.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 36DA167DD8D; Thu, 20 Jul 2017 17:05:41 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 36DA167DD8D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1500563141; bh=ZACnjMSSylXCsgM12iZqxsyb95exJd9K6BtSotyPBPk=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=0ioswxz+XbB6Fk5dDIMvH1n13M1OQg5ltig9q6YgYAVphV3x/wRICZndp3Xhrt++h mMjCGZ2t7H1OrHcWQCd8kCm4g5ERsskV9c7A0Dmne22OyPn9NFNNYjEiso1vUKEAYE H4XH5q2BZCe+4OTFKpZ5bnKwCpb+g8nm9RImhYnM= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2 Reply-To: Olivier.Bonaventure@uclouvain.be To: Alan Ford , Zhiyun Qian Cc: multipathtcp@ietf.org, Ali Munir , Franck Le , Alex Liu , Zubair References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> From: Olivier Bonaventure Message-ID: Date: Thu, 20 Jul 2017 17:05:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 36DA167DD8D.A23C8 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:05:52 -0000 Alan, > > Please bear in mind that the goal of MPTCP with respect to security, as discussed in the original architectural design in RFC6182, is to provide a security model no worse than TCP. So whilst this attack would be possible, it can only be done by an on-path attacker, and if succeeded would allow the on-path attacker to intercept all traffic. Which would be the same for a single-path TCP connection on the same path. > > As a side point, the same kind of attack could be launched via REMOVE_ADDR messages, but this would not succeed since this is specified with some protection - ensuring the subflow is really unavailable through the use of TCP keepalive signals. This same protection cannot be used against the MP_PRIO since the referenced subflow is not unavailable. > > If the WG considered this risk worth addressing, we could look at adding a nonce + signature to MP_PRIO. Since the attacker is on path, this does not help if the attacker is on the first path. > > We discuss several solutions in a forthcoming paper [ICNP2017], but a > simple approach to cope with this attack would be to reconsider the > utilisation of the address identifier in the MP_PRIO option. This > option allows a host to set/change the priority of all the subflows > associated to a given address identifier on another subflow. It could > have use cases, such as sending MP_PRIO over a WiFi subflow to put the > cellular subflow in backup mode without sending a packet over the > cellular interface, but this looks like an edge case. Looking at the > attack that we have identified, the working group should evaluate the > removal of the address identifier in rfc6824bis. If the MP_PRIO option > does not include an address identifier, then it becomes impossible for > an attacker who is on-path of a given subflow to change the priority > of the other subflows. Remove the address identifier from the MP_PRIO seems a safe solution to me. I do not see a benefit in sending MP_PRIO on another subflow than the one that you want to affect. Olivier From nobody Thu Jul 20 08:21:04 2017 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 2F961131C43 for ; Thu, 20 Jul 2017 08:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 pRvZt9rsuB69 for ; Thu, 20 Jul 2017 08:21:01 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in2.euro.apple.com [17.72.148.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8258D1252BA for ; Thu, 20 Jul 2017 08:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500564059; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KVQrIr090vYcfyHdA0T3LAkPpXMBvUXWW/oGiLb0Vfc=; b=WpFnIQ7XmNJLZ7GwuiE2mZoUN3Qh0zCTBBru3lrj+Cr0DUEhXods+sA2Jx0leY3a /R2VuXcMQoC08hmpd3zh/E6BA9N3vNx2RBeFnhqP9GBuIs1oiVO4Jkl24daoK2HK kz2EtNedZDb+CI57Zl9iZ3UwJhp8+WMID55DXN/hChU35pwzZHkrZr1Yf6AaKa0i 5x+k2OwoJdsy66idmtzZR2gghkPQ9Cewwe9ehlIOwIIYLg4tZtd+WY62D4MyLRh4 nCku/yExodWvHd7PkMXuwyvNkQ8SxmTFNqxjRiI3X1FWBqggn6WDWYAs4IWOrk29 9vr8Azi3rpb+Vq05AMd51w==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id 34.9F.06273.B5AC0795; Thu, 20 Jul 2017 16:20:59 +0100 (BST) X-AuditID: 1148940c-d5dff70000001881-dc-5970ca5b33c2 Received: from crk-mmpp-sz03 ( [17.66.12.165]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 1C.E6.07255.B5AC0795; Thu, 20 Jul 2017 16:20:59 +0100 (BST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from localhost ([17.235.220.88]) by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OTE003H2AMYEW00@crk-mmpp-sz03.euro.apple.com>; Thu, 20 Jul 2017 16:20:59 +0100 (IST) Sender: cpaasch@apple.com Date: Thu, 20 Jul 2017 17:20:58 +0200 From: Christoph Paasch To: Olivier Bonaventure Cc: Alan Ford , Zhiyun Qian , multipathtcp@ietf.org, Zubair , Franck Le , Alex Liu , Ali Munir Message-id: <20170720152058.GJ3049@Chimay.local> References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> In-reply-to: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUi6GTOoxt9qiDS4GS/nMXKcyuYLc5sXshi cXH1e2aLz6uvs1ks7DrOZnGj4QeLxYFvbxktXlw8xOzA4dHSM5fR4+jBTnaPnbPusnssWfKT yePZkQiPV8e+s3hMmMrpce5aH3MARxSXTUpqTmZZapG+XQJXxp5tjSwFE4Uqdm+7zdLAuI2v i5GTQ0LARGLGq7OMXYxcHEIC25kktt5dwwSTWLjwGjtEYjWjxJ1Hd9lBErwCghI/Jt9j6WLk 4GAWkJc4eF4WJMwsIC3x6O8MdghbS+L7o1YWiN5uJonHV2eygCSEBSQluu/cYQaxWQRUJR42 3weLswE1vL3dzgpiiwhYSZw6PR1sMbPAPUaJqb2/WSGaPSQeT9vMCHGEgcTkq31gzUICmxkl +ho0QWxOAQeJfXdawGpEBZQl/h6+B3aFhMBnNok/d66yT2AUmYXkiVkIT8xC8sQsJE8sYGRZ xSiem5iZo5uZZ6SXWlqUr5dYUJCTqpecn7uJERSLHlN4djBePGh4iFGAg1GJhzc2zjdSiDWx rLgy9xCjBAezkghv/Y6CSCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8JqXykUIC6YklqdmpqQWp RTBZJg5OqQbGQMeGnWe+fNBbn8poL1u36ufUQzbmdjFix/KZTIuOHp38wzvKbvM6nz6/G3tK Ms+t9d6nH3Xvdk7FLQ2vgraZ+190GCV2/tujJrEyxVpCqpQjw6jGIjZ3Z6JjgJX/SeEX+89N /jyJ7X7CEo1TaQp5No8sJP+6fnuWtumDaYMvoz0/+yX2wq9KLMUZiYZazEXFiQAnrhvxwQIA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42IRdOJZqht9qiDSoOuulMXKcyuYLc5sXshi cXH1e2aLz6uvs1ks7DrOZnGj4QeLxYFvbxktXlw8xOzA4dHSM5fR4+jBTnaPnbPusnssWfKT yePZkQiPV8e+s3hMmMrpce5aH3MARxSXTUpqTmZZapG+XQJXxp5tjSwFE4Uqdm+7zdLAuI2v i5GTQ0LARGLhwmvsXYxcHEICqxkl7jy6yw6S4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBaYlH f2ewQ9haEt8ftbJA9HYzSTy+OpMFJCEsICnRfecOM4jNIqAq8bD5PlicDajh7e12VhBbRMBK 4tTp6WCLmQXuMUpM7f3NCtHsIfF42mZGiCMMJCZf7QNrFhLYzCjR16AJYnMKOEjsu9MCViMq oCzx9/A9lgmMgrOQ3D0L4e5ZSO6eheTuBYwsqxhFi1JzEiuN9FJLi/L1EgsKclL1kvNzNzGC Y8ecZwfjq4OGhxgFOBiVeHgXbiuIFGJNLCuuzD3EKMHBrCTCW78DKMSbklhZlVqUH19UmpNa fIhRmoNFSZy3VhMoJZCeWJKanZpakFoEk2Xi4JRqYDRYo63bflDt67clbDKG564feJn44fVu CfnlKz4dU0r67dnU6y1lreTK2RqZfN5+Ba97Y0Tb3Q7NpBuV+xY1H37IHSA8J+11cu2v7pOT N7B52lvm+0s8kqj7d+6ov5N8qPANxU/8e//tXGZ15SHj6Z88H26YTuI6d2Umg8HUM+wTlj24 fVWwzUaJpTgj0VCLuag4EQBcYJZgmQIAAA== Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:21:03 -0000 On 20/07/17 - 17:05:40, Olivier Bonaventure wrote: > Alan, > > > > Please bear in mind that the goal of MPTCP with respect to security, as discussed in the original architectural design in RFC6182, is to provide a security model no worse than TCP. So whilst this attack would be possible, it can only be done by an on-path attacker, and if succeeded would allow the on-path attacker to intercept all traffic. Which would be the same for a single-path TCP connection on the same path. > > > > As a side point, the same kind of attack could be launched via REMOVE_ADDR messages, but this would not succeed since this is specified with some protection - ensuring the subflow is really unavailable through the use of TCP keepalive signals. This same protection cannot be used against the MP_PRIO since the referenced subflow is not unavailable. > > > > If the WG considered this risk worth addressing, we could look at adding a nonce + signature to MP_PRIO. > > Since the attacker is on path, this does not help if the attacker is on the > first path. > > > > > We discuss several solutions in a forthcoming paper [ICNP2017], but a > > simple approach to cope with this attack would be to reconsider the > > utilisation of the address identifier in the MP_PRIO option. This > > option allows a host to set/change the priority of all the subflows > > associated to a given address identifier on another subflow. It could > > have use cases, such as sending MP_PRIO over a WiFi subflow to put the > > cellular subflow in backup mode without sending a packet over the > > cellular interface, but this looks like an edge case. Looking at the > > attack that we have identified, the working group should evaluate the > > removal of the address identifier in rfc6824bis. If the MP_PRIO option > > does not include an address identifier, then it becomes impossible for > > an attacker who is on-path of a given subflow to change the priority > > of the other subflows. > > Remove the address identifier from the MP_PRIO seems a safe solution to me. > I do not see a benefit in sending MP_PRIO on another subflow than the one > that you want to affect. +1 As far as I know, there is no implementation that relies on the address-ID in the MP_PRIO to signal the priorities. Christoph From nobody Thu Jul 20 08:33:39 2017 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 D5BFF126CB6 for ; Thu, 20 Jul 2017 08:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KFlEf1SCyaDL for ; Thu, 20 Jul 2017 08:33:36 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942DA1252BA for ; Thu, 20 Jul 2017 08:33:35 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id o33so3042032wrb.1 for ; Thu, 20 Jul 2017 08:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=q2kfJRN4k5f8WyNZJf8wgfjBAF7Xj5cBcLfRcLaXS4s=; b=kpfzJwT7hUPfZpD4jzmJMdPdgCi/AFaZUjltNTGzyH1XubDuNwtqnPfnd23PY95odZ McuOXTl05zgkgbzlHUMqUMMpIjhymMOFHt1LHWZ1qPITaM9Tqgj5LSWHU+6HCEIsWJqA I/l5QhyBwZWcyH+66L68Q/YM0vF4Nd1GPHSd4LPPeRsyuszCpgH9zhiLE9ytwbBLKBVw yNVHsR51cyqFuwVulBSWx7vZBa+E6tX1W/cr+W8rbnP3XDJhyGQhGA447/6nJ7TVf9rp DQjAYRFknh3023M/xfZepfsppAviHoVQ5DajRy9vaW5djHabgSjxh1Rtl/p1fTqh0/l4 JUOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=q2kfJRN4k5f8WyNZJf8wgfjBAF7Xj5cBcLfRcLaXS4s=; b=jRnr9afzlf3nQcA6wnEHN0aDTMUVjCPk1+qRExubnJhhZ5xuEsSek8wca7EqD5mmte XJP3EZSn6T7ic7wwqMHbbpBRoEnWvVZPY4jIuDTxnC0T52pSF7GevGpUMGWPzyA+ZGMg +W+bndVDx0E0Vjhv6Q4TMUO6mOM46qrMUxMy2PN0v/TJJZvI5NJ6ElzOP8iFXmdWQgqi YZUS05y3WR+BO5P1z0peT1MH1r0G2f5CBZI2tX7HAO9+GrRHDoGeRSWlqQppfriFMUT9 5vENoe+yPVIWet/HOx0EEePvQNWwlg2Z2RbeNzcRMtqtpKCsPNss13k8c7+P+vRWHZM0 I8EA== X-Gm-Message-State: AIVw111TtupC1cXa4fD7LwyjPGfp2jj2fvw7IxxaWw7ji9ugOC5Frsik H5zn3YKKaOW7ew== X-Received: by 10.223.154.203 with SMTP id a69mr7379412wrc.139.1500564814185; Thu, 20 Jul 2017 08:33:34 -0700 (PDT) Received: from dhcp-8374.meeting.ietf.org (dhcp-8374.meeting.ietf.org. [31.133.131.116]) by smtp.gmail.com with ESMTPSA id g83sm2283739wmf.29.2017.07.20.08.33.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Jul 2017 08:33:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C3EAD0E2-0E02-492F-8096-30381F6C1ABD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <20170720152058.GJ3049@Chimay.local> Date: Thu, 20 Jul 2017 16:33:31 +0100 Cc: Olivier Bonaventure , Zhiyun Qian , multipathtcp@ietf.org, Zubair , Franck Le , Alex Liu , Ali Munir Message-Id: References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> To: Christoph Paasch X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:33:38 -0000 --Apple-Mail=_C3EAD0E2-0E02-492F-8096-30381F6C1ABD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Comments inline... > On 20 Jul 2017, at 16:20, Christoph Paasch wrote: >=20 > On 20/07/17 - 17:05:40, Olivier Bonaventure wrote: >> Alan, >>>=20 >>> Please bear in mind that the goal of MPTCP with respect to security, = as discussed in the original architectural design in RFC6182, is to = provide a security model no worse than TCP. So whilst this attack would = be possible, it can only be done by an on-path attacker, and if = succeeded would allow the on-path attacker to intercept all traffic. = Which would be the same for a single-path TCP connection on the same = path. >>>=20 >>> As a side point, the same kind of attack could be launched via = REMOVE_ADDR messages, but this would not succeed since this is specified = with some protection - ensuring the subflow is really unavailable = through the use of TCP keepalive signals. This same protection cannot be = used against the MP_PRIO since the referenced subflow is not = unavailable. >>>=20 >>> If the WG considered this risk worth addressing, we could look at = adding a nonce + signature to MP_PRIO. >>=20 >> Since the attacker is on path, this does not help if the attacker is = on the >> first path. That scenario has always been out of scope. If an attacker has observed = the initial exchange, all bets are off, and we are only as secure as = single-path TCP. >>> We discuss several solutions in a forthcoming paper [ICNP2017], but = a >>> simple approach to cope with this attack would be to reconsider the >>> utilisation of the address identifier in the MP_PRIO option. This >>> option allows a host to set/change the priority of all the subflows >>> associated to a given address identifier on another subflow. It = could >>> have use cases, such as sending MP_PRIO over a WiFi subflow to put = the >>> cellular subflow in backup mode without sending a packet over the >>> cellular interface, but this looks like an edge case. Looking at the >>> attack that we have identified, the working group should evaluate = the >>> removal of the address identifier in rfc6824bis. If the MP_PRIO = option >>> does not include an address identifier, then it becomes impossible = for >>> an attacker who is on-path of a given subflow to change the priority >>> of the other subflows. >>=20 >> Remove the address identifier from the MP_PRIO seems a safe solution = to me. >> I do not see a benefit in sending MP_PRIO on another subflow than the = one >> that you want to affect. >=20 > +1 >=20 > As far as I know, there is no implementation that relies on the = address-ID > in the MP_PRIO to signal the priorities. So the main reason for this was to permit the signalling of backup for a = subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a = =E2=80=98B=E2=80=99 bit in it, so the priority would be signalled = separately. We could add the prio bit to ADD_ADDR to resolve this issue. However, = this limits extensibility in MP_PRIO e.g. with other signals which have = been suggested in the past ("backup but do not open=E2=80=9D, use for = differing traffic types, etc). Regards, Alan --Apple-Mail=_C3EAD0E2-0E02-492F-8096-30381F6C1ABD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Comments inline...

On = 20 Jul 2017, at 16:20, Christoph Paasch <cpaasch@apple.com> = wrote:

On 20/07/17 - 17:05:40, Olivier Bonaventure = wrote:
Alan,

Please = bear in mind that the goal of MPTCP with respect to security, as = discussed in the original architectural design in RFC6182, is to provide = a security model no worse than TCP. So whilst this attack would be = possible, it can only be done by an on-path attacker, and if succeeded = would allow the on-path attacker to intercept all traffic. Which would = be the same for a single-path TCP connection on the same path.

As a side point, the same kind of attack could = be launched via REMOVE_ADDR messages, but this would not succeed since = this is specified with some protection - ensuring the subflow is really = unavailable through the use of TCP keepalive signals. This same = protection cannot be used against the MP_PRIO since the referenced = subflow is not unavailable.

If the WG = considered this risk worth addressing, we could look at adding a nonce + = signature to MP_PRIO.

Since = the attacker is on path, this does not help if the attacker is on the
first path.

That = scenario has always been out of scope. If an attacker has observed the = initial exchange, all bets are off, and we are only as secure as = single-path TCP.

We discuss several solutions in a forthcoming paper = [ICNP2017], but a
simple approach to cope with this attack = would be to reconsider the
utilisation of the address = identifier in the MP_PRIO option. This
option allows a = host to set/change the priority of all the subflows
associated to a given address identifier on another subflow. = It could
have use cases, such as sending MP_PRIO over a = WiFi subflow to put the
cellular subflow in backup mode = without sending a packet over the
cellular interface, but = this looks like an edge case. Looking at the
attack that = we have identified, the working group should evaluate the
removal of the address identifier in rfc6824bis. If the = MP_PRIO option
does not include an address identifier, = then it becomes impossible for
an attacker who is on-path = of a given subflow to change the priority
of the other = subflows.

Remove the address = identifier from the MP_PRIO seems a safe solution to me.
I = do not see a benefit in sending MP_PRIO on another subflow than the = one
that you want to affect.

+1

As far as I know, there is no = implementation that relies on the address-ID
in the MP_PRIO to = signal the priorities.

So the main reason for this was to permit the signalling of = backup for a subflow which was also signalled via ADD_ADDR. ADD_ADDR = does not have a =E2=80=98B=E2=80=99 bit in it, so the priority would be = signalled separately.

We could add the prio bit to ADD_ADDR to resolve this issue. = However, this limits extensibility in MP_PRIO e.g. with other signals = which have been suggested in the past ("backup but do not open=E2=80=9D, = use for differing traffic types, etc).

Regards,
Alan


= --Apple-Mail=_C3EAD0E2-0E02-492F-8096-30381F6C1ABD-- From nobody Thu Jul 20 08:53:16 2017 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 5870A1252BA for ; Thu, 20 Jul 2017 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PUE5pk-6qLNP for ; Thu, 20 Jul 2017 08:53:13 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28EC12F268 for ; Thu, 20 Jul 2017 08:53:12 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 80so26394530uas.0 for ; Thu, 20 Jul 2017 08:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=XV/a+LcZVy4lVITbzgZlK2/jm8OsYFjnBDf90BdSjio=; b=ROlS2YEFoA3JSNIf/rCTrk2pZuVN3oxHiHkY+0Ee8Qdsw1Vn/AJorwQlhIqAYH7pgj Eo/RSZF0RDbZ2B3KKINTnrZaJ81AIhU61xUTG4I8eZuw8ej0c3wLTkJN1NJAzkc2QqSi Pch/uBtwGfxt/RJuFQRT2ZvhZiZ0KssLs3fWYZ/SlcIXY4C7c+BFS/m9gGSp+3UsQLZC dxkRfska/yXKuZ8fmGF/LDjyeGFZFFC5bbFncU4mH5fS/Brl77enZzCQ2O7/NZzEhZFY 0TQ5PJzkk49vTBWq72EoDDdEvDzE1nMKxrE2Nu19FFIu7QDfSLich7N9JxBf+7R5mLdp QV7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=XV/a+LcZVy4lVITbzgZlK2/jm8OsYFjnBDf90BdSjio=; b=dAgeVjOhRg4QpQVppl6ZgBsmtdpNM2fURMRUV7Zj03Wi0SE+1/LGm3uaT/niS2qoTb VyCsJqtX+TqCwD+IEDogqt2AIsCEImpeGZxmqFABtMzfsOyPnGarOgxo4czI/Y8qPixl ShZ7W3G+Mf1tdkiEZ5TnyMEOSpTg8qcw9ghHXTVCP+Rku/vkEhamNDamYersl9Tfv40E RVwrPD8/UYjytRXp3c7H7S2Hkj+j71zzhh9bw9xBJCI12HesLy4++Xa/qkqN/qXot9L1 nReokaA2AnTtyKLD5j4g9Ff6IWkTwtB7xG8OiH5hr+g2ln3oDlonKkKnyabn7m+CO84j KLZg== X-Gm-Message-State: AIVw112HnJ3KJzjp84XxSlgvCNyDSkVFryOHgSNqpqZnIYWh7HYxBdqy t/e8H4YWKH9A9wED1alK34ATU4BmRA== X-Received: by 10.31.159.201 with SMTP id i192mr2128227vke.116.1500565991611; Thu, 20 Jul 2017 08:53:11 -0700 (PDT) MIME-Version: 1.0 Sender: qzy888@gmail.com Received: by 10.103.149.65 with HTTP; Thu, 20 Jul 2017 08:53:10 -0700 (PDT) In-Reply-To: <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> From: Zhiyun Qian Date: Thu, 20 Jul 2017 08:53:10 -0700 X-Google-Sender-Auth: ZQ1UGRocIxMLbijhaOmuRoXnAlo Message-ID: To: Alan Ford Cc: multipathtcp@ietf.org, Zubair , Franck Le , Alex Liu , Ali Munir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:53:14 -0000 Hi Alan, I'd argue this vulnerability does make MPTCP worse than TCP in the sense of increased risk or attack surface: The key problem is that this vulnerability allows an attacker on *any* path to direct all traffic in other paths to the path it sits on. In contrast, for TCP the attacker has to sit on *a specific* path to be able to observe and control all traffic. -Zhiyun On Thu, Jul 20, 2017 at 8:00 AM, Alan Ford wrote: > Hi Zhiyun, > > Please bear in mind that the goal of MPTCP with respect to security, as d= iscussed in the original architectural design in RFC6182, is to provide a s= ecurity model no worse than TCP. So whilst this attack would be possible, i= t can only be done by an on-path attacker, and if succeeded would allow the= on-path attacker to intercept all traffic. Which would be the same for a s= ingle-path TCP connection on the same path. > > As a side point, the same kind of attack could be launched via REMOVE_ADD= R messages, but this would not succeed since this is specified with some pr= otection - ensuring the subflow is really unavailable through the use of TC= P keepalive signals. This same protection cannot be used against the MP_PRI= O since the referenced subflow is not unavailable. > > If the WG considered this risk worth addressing, we could look at adding = a nonce + signature to MP_PRIO. > > Regards, > Alan > >> On 20 Jul 2017, at 08:28, Zhiyun Qian wrote: >> >> Dear all, >> >> We are a group of researchers (cc:ed on the email) who recently >> discovered a security flaw in the MP_PRIO messge that allows a >> man-in-the-middle attacker on a single path to divert all traffic to >> its own path, effectively hijacking the entire MPTCP connection. Below >> we describe the problem in brief (more details will be found in our >> upcoming ICNP paper. We also hope to submit an Internet draft soon). >> We thank Olivier Bonaventure for his valuable feedback. >> >> --------------------------------------------------------------- >> >> MPTCP supports using sub-connections as backup =E2=80=93 i.e., using a >> sub-connection to send data only if there is no other sub-connection >> available. Specifically, an MPTCP host can send a request to the other >> host to set any sub-connection as a backup by using the MPTCP MP_PRIO >> option. Hosts can request change in the priority to use a >> subconnection as regular or backup. To set a sub-connection as >> backup, a host can request a change in the sub-connection priority by >> sending MPTCP MP_PRIO option to the other host with the corresponding >> address identifier. The key property of MP_PRIO messages is that they >> can be sent on any sub-connection. The reason is that if a >> sub-connection is already congested, it may not be possible to deliver >> the message to pause itself. After receiving such a control packet, >> the sender will stop sending data and the corresponding >> sub-connection=E2=80=99s throughput will drop to zero. >> >> Unfortunately, unlike MP_JOIN, such a MP_PRIO option has no >> authentication required by the specification whatsoever, allowing an >> attacker controlling only one path to set any sub-connection as backup >> and launch traffic divergence and connection hijack attacks. The >> backup flag vulnerability allows an attacker to divert traffic among >> MPTCP sub-connections. An attacker can offload traffic from the >> eavesdropped sub-connection to other MPTCP sub-connections by sending >> forged packets with the MP_PRIO option to set the eavesdropped >> sub-connection as a backup. An attacker can also onload traffic from >> non-eavesdropped sub-connections to the eavesdropped sub-connection by >> sending forged packets with the MP_PRIO option to set all other >> sub-connections as backup. This attack is similar to connection hijack >> attack, where an attacker diverts all the traffic to pass through the >> sub-connection on the eavesdropped path. >> >> >> Connection Hijack Example: >> >> Consider a scenario where two sub-connections of an MPTCP connection >> pass through paths p1 and p2. An attacker can hijack the >> non-eavesdropped subconnection on p2 by dynamically changing the >> priority of a sub-connection and declaring it as backup. >> >> To launch this attack an attacker only needs to know the address >> identifier of the host , which can be obtained by eavesdropping other >> paths or easily guessed as they are set incrementally in current Linux >> implementation of MPTCP. Since the identifier has only 8 bits, it can >> even be brute forced. To set a non-eavesdropped sub-connection as >> backup between hosts A and B, an attacker can request a change in the >> sub-connection priority by sending MPTCP MP_PRIO option to host B with >> the address identifier of host A. Since by design the MP_PRIO messages >> can be sent on any sub-connection, the attacker eavesdropping on any >> path capable of sending such a forged backup message can pause any >> other path. Note that a backup MPTCP sub-connection may still be used >> for data transmission later, which can be detected by the attacker by >> observing the overall MPTCP throughput. >> >> Effectively, this attack degrades an MPTCP connection to a regular TCP >> connection as all traffic will be routed through the >> attacker-controlled path. We argue that this vulnerability makes MPTCP >> less secure than TCP, because the entire MPTCP connection can be >> compromised (fully controlled by an attacker) as long as any one of >> the communication paths is compromised. Unfortunately, MPTCP >> specification does not include any authentication mechanism whatsoever >> regarding the MP_PRIO message. >> >> We discuss several solutions in a forthcoming paper [ICNP2017], but a >> simple approach to cope with this attack would be to reconsider the >> utilisation of the address identifier in the MP_PRIO option. This >> option allows a host to set/change the priority of all the subflows >> associated to a given address identifier on another subflow. It could >> have use cases, such as sending MP_PRIO over a WiFi subflow to put the >> cellular subflow in backup mode without sending a packet over the >> cellular interface, but this looks like an edge case. Looking at the >> attack that we have identified, the working group should evaluate the >> removal of the address identifier in rfc6824bis. If the MP_PRIO option >> does not include an address identifier, then it becomes impossible for >> an attacker who is on-path of a given subflow to change the priority >> of the other subflows. >> >> Best, >> -Zhiyun >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From nobody Thu Jul 20 08:55:01 2017 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 185AC12EC32 for ; Thu, 20 Jul 2017 08:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oE_pY9tp3_8A for ; Thu, 20 Jul 2017 08:54:58 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACF512F268 for ; Thu, 20 Jul 2017 08:54:56 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 80so26432125uas.0 for ; Thu, 20 Jul 2017 08:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=FH382q/Fjnq1MSB8b24nINcZqQVZQYDbIz6UYibn2dE=; b=omY+PAvuNQRQlSIPCdOpTTvaU6H6QtP6ZRaff6ew2/V5VXSSaMfI4ZQuTN6FqXfitF 6B4H2hisKfQtUkTHP3ambNQXLALUrFgO2UrrUivuulsvX7gFPmOP/pePzTRXOTV+fol7 IDl02e1r4lGWwOhttdgBf88SjIqAzzLbXTzJOl5QhdqQG6Z2eQXrlWdupWfAGzzmZ1yM Fxp+epz4vC+5zw+UNDnXoXc0C7lTr37YeO0TSVKmLUKeKJ7aNcQnkSITdIwHqm5IkGxS Ytz7yhULasCKQr4cCmYydGmZurSBy5Fjem1Z2u9arbLgrdDZ5iM1W1RjKx3FrPMiVJW/ az6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=FH382q/Fjnq1MSB8b24nINcZqQVZQYDbIz6UYibn2dE=; b=Pg6pbucv1MjdNsLHD2toq5jgTvBTdEeXceLG2eU40X/e9YDZdUVm3Qb0DqLLviORXY eASMv1LXIrjXR7azdq0UiKvia1XSFethdfCOhYT4V3x9yH30GpxgPOJnpRog7uqvlX4R 8go8FQc1EP19scnYK8bQdylm2ghCZyt0EjVCIAU+KCJQnwWQbCqlRYT+xPJAyHPdgf8e RivIzOom6aAsJYxCO+fayDX+apuaqSgD8HyrhQKxjlFtbfErCpgjbI8gjGPF1AtHo3Lj IQZ9Hl2V1DTGPfqJeThukfgr95VhEET/fRrK5o9htUxX7M9o0lZouc/7yzeTMwPnc7JR ybFQ== X-Gm-Message-State: AIVw110zg1oI6elVhRNYYvRadDm5w9bhv8cZF9x6Gnv7G7FIDRzhJc4K v2zxjun9+vSXsEHM2jH0/cyx6VMxbw== X-Received: by 10.31.150.143 with SMTP id y137mr2397291vkd.154.1500566095512; Thu, 20 Jul 2017 08:54:55 -0700 (PDT) MIME-Version: 1.0 Sender: qzy888@gmail.com Received: by 10.103.149.65 with HTTP; Thu, 20 Jul 2017 08:54:54 -0700 (PDT) In-Reply-To: References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> From: Zhiyun Qian Date: Thu, 20 Jul 2017 08:54:54 -0700 X-Google-Sender-Auth: 4EKRB7RdBrlwy8ojlF8VkvdYNwU Message-ID: To: Alan Ford Cc: Christoph Paasch , Olivier Bonaventure , multipathtcp@ietf.org, Zubair , Franck Le , Alex Liu , Ali Munir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:55:00 -0000 I thought MP_PRIO message may theoretically be useful if subflow A is congested already so it needs to use subflow B to signal the fact that subflow A will become a backup. Best, -Zhiyun On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford wrote: > Comments inline... > > On 20 Jul 2017, at 16:20, Christoph Paasch wrote: > > On 20/07/17 - 17:05:40, Olivier Bonaventure wrote: > > Alan, > > > Please bear in mind that the goal of MPTCP with respect to security, as > discussed in the original architectural design in RFC6182, is to provide = a > security model no worse than TCP. So whilst this attack would be possible= , > it can only be done by an on-path attacker, and if succeeded would allow = the > on-path attacker to intercept all traffic. Which would be the same for a > single-path TCP connection on the same path. > > As a side point, the same kind of attack could be launched via REMOVE_ADD= R > messages, but this would not succeed since this is specified with some > protection - ensuring the subflow is really unavailable through the use o= f > TCP keepalive signals. This same protection cannot be used against the > MP_PRIO since the referenced subflow is not unavailable. > > If the WG considered this risk worth addressing, we could look at adding = a > nonce + signature to MP_PRIO. > > > Since the attacker is on path, this does not help if the attacker is on t= he > first path. > > > That scenario has always been out of scope. If an attacker has observed t= he > initial exchange, all bets are off, and we are only as secure as single-p= ath > TCP. > > We discuss several solutions in a forthcoming paper [ICNP2017], but a > simple approach to cope with this attack would be to reconsider the > utilisation of the address identifier in the MP_PRIO option. This > option allows a host to set/change the priority of all the subflows > associated to a given address identifier on another subflow. It could > have use cases, such as sending MP_PRIO over a WiFi subflow to put the > cellular subflow in backup mode without sending a packet over the > cellular interface, but this looks like an edge case. Looking at the > attack that we have identified, the working group should evaluate the > removal of the address identifier in rfc6824bis. If the MP_PRIO option > does not include an address identifier, then it becomes impossible for > an attacker who is on-path of a given subflow to change the priority > of the other subflows. > > > Remove the address identifier from the MP_PRIO seems a safe solution to m= e. > I do not see a benefit in sending MP_PRIO on another subflow than the one > that you want to affect. > > > +1 > > As far as I know, there is no implementation that relies on the address-I= D > in the MP_PRIO to signal the priorities. > > > So the main reason for this was to permit the signalling of backup for a > subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a = =E2=80=98B=E2=80=99 > bit in it, so the priority would be signalled separately. > > We could add the prio bit to ADD_ADDR to resolve this issue. However, thi= s > limits extensibility in MP_PRIO e.g. with other signals which have been > suggested in the past ("backup but do not open=E2=80=9D, use for differin= g traffic > types, etc). > > Regards, > Alan > > From nobody Thu Jul 20 09:25:39 2017 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 E1E1E131A93 for ; Thu, 20 Jul 2017 09:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 HxzPoSYz6tFD for ; Thu, 20 Jul 2017 09:25:33 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in2.euro.apple.com [17.72.148.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0C6131945 for ; Thu, 20 Jul 2017 09:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500567931; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xw1/Tm95yneg2yb3zLMIWaKsrkJe0gxpDi+nYWIXHCE=; b=EJjmpD1nNZf0kcO881LZ5RsHrleJ30myC3samiv1jnzK4L+a6X2KTOd/pjIPRrJw aczBJP1ZNkR8JjjR6YTxBamqzJ1mBga/sM+nLvktNcG5zG/R/LsdqZ6KKAP44fG/ G8q1A4SnCB11OCArrvsRNMO9SR/T7+4U7783JPOnHwh3wqLS6+Cu7ZSo99z5KkLL sEYL/0+G14svawW6AX+yHq3pz3b+f/RNE4eVZw/riYnkWcji/Uf+LNIllKJSFUfA JCgh1ss3Td2oKa6Ko2+PrXIS6RaKSAmPxSGP8zYAQc8RY27PKUqaNPf9ZIp6lJ9U fFU7LLAGaO7rCVuwqEIClQ==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id 0A.70.06273.B79D0795; Thu, 20 Jul 2017 17:25:31 +0100 (BST) X-AuditID: 1148940c-d5dff70000001881-29-5970d97bd773 Received: from crk-mmpp-sz03 ( [17.66.12.165]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 35.FA.07255.B79D0795; Thu, 20 Jul 2017 17:25:31 +0100 (BST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from localhost ([17.235.220.88]) by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OTE003G0DMIAKA0@crk-mmpp-sz03.euro.apple.com>; Thu, 20 Jul 2017 17:25:31 +0100 (IST) Sender: cpaasch@apple.com Date: Thu, 20 Jul 2017 18:25:31 +0200 From: Christoph Paasch To: Alan Ford Cc: Olivier Bonaventure , Zhiyun Qian , multipathtcp@ietf.org, Zubair , Franck Le , Alex Liu , Ali Munir Message-id: <20170720162531.GL3049@Chimay.local> References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> In-reply-to: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUi6GTOo1t9syDS4OMcMYuV51YwW5zZvJDF 4uLq98wWn1dfZ7NY2HWczeJGww8WiwPf3jJavLh4iNmBw6OlZy6jx9GDneweO2fdZfdYsuQn k8ezIxEer459Z/GYMJXT49y1PuYAjigum5TUnMyy1CJ9uwSujP9HVrAVNEpVzH7yi6mB8ZZI FyMHh4SAicTB+apdjFwcQgLbmSTmH9/J3MXICRa//7OJCSKxmlGi6+4OdpAEr4CgxI/J91hA mpkF5CWOXMoGCTMLSEs8+juDHSKsLjFlSi5EazeTxMLHbUwgNcICkhLdd+6AzWcRUJV48+kM WJxNQEvi7e12VpBeEQFlieWzWCFGfmWUWHI0HqLVQ+LxtM2MEBcYSLzo6mCDmN/LJPF3zU6w 0zgFbCWaXs4Es0WB5vw9DHImF9Avr9kkJqy4xjaBUWQWkhdmIbwwC8kLsxBeWMDIsopRPDcx M0c3M89IL7W0KF8vsaAgJ1UvOT93EyMoBj2m8OxgvHjQ8BCjAAejEg9vbJxvpBBrYllxZe4h RgkOZiUR3vodBZFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeU1K5SOFBNITS1KzU1MLUotgskwc nFINjP5rtvncObPXVu1D/4Qn0j+EZA7Lf/uVING09Vr/C06j9ReMpFKlG9+dufeW3//gLy5Z p/i3Mu2OTNfv8x+KWVPuPOfTHf9NkltdHhydH1q2Odyy9v0G1lM1sSFFDCfqDJy2Nx9dbHXH WvVfPvuKg3ZcDdovLO/26DWZHTqzZt0s1ZbDSSlqykosxRmJhlrMRcWJAOkgZ6+9AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42IRdOJZqlt9syDSYMk7IYuV51YwW5zZvJDF 4uLq98wWn1dfZ7NY2HWczeJGww8WiwPf3jJavLh4iNmBw6OlZy6jx9GDneweO2fdZfdYsuQn k8ezIxEer459Z/GYMJXT49y1PuYAjigum5TUnMyy1CJ9uwSujP9HVrAVNEpVzH7yi6mB8ZZI FyMnh4SAicT9n01MXYxcHEICqxkluu7uYAdJ8AoISvyYfI+li5GDg1lAXuLIpWyQMLOAtMSj vzPYIcLqElOm5EK0djNJLHzcxgRSIywgKdF95w4ziM0ioCrx5tMZsDibgJbE29vtrCC9IgLK EstnsUKM/MooseRoPESrh8TjaZsZIS4wkHjR1cEGMb+XSeLvmp1gp3EK2Eo0vZwJZosCzfl7 +B7LBEbBWUiunoVw9SwkV89CuHoBI8sqRtGi1JzESiO91NKifL3EgoKcVL3k/NxNjOCoMefZ wfjqoOEhRgEORiUe3oXbCiKFWBPLiitzDzFKcDArifDW7wAK8aYkVlalFuXHF5XmpBYfYpTm YFES563VBEoJpCeWpGanphakFsFkmTg4pRoY2/kOL41407VX84Vg8KFYr5DFW+ZfEmVlOtnP Y6fO/Ix/1vOD3t5NMw6lBqW0KwixVP2JNNl+YUZqy+1mV+kc0ZC5/Itn/qyZ4340y2d3Tsy/ R8+n55yxUpbyeC510Gqnr7xb/uR0DZOMpDtOLxZZxb6OOx/ZtPudYelL9T/Xvp3kn8Sy395C iaU4I9FQi7moOBEA51mE4ZYCAAA= Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:25:35 -0000 Hello Alan, On 20/07/17 - 16:33:31, Alan Ford wrote: > Comments inline... > > > On 20 Jul 2017, at 16:20, Christoph Paasch wrote: > > > > On 20/07/17 - 17:05:40, Olivier Bonaventure wrote: > >> Alan, > >>> > >>> Please bear in mind that the goal of MPTCP with respect to security, as discussed in the original architectural design in RFC6182, is to provide a security model no worse than TCP. So whilst this attack would be possible, it can only be done by an on-path attacker, and if succeeded would allow the on-path attacker to intercept all traffic. Which would be the same for a single-path TCP connection on the same path. > >>> > >>> As a side point, the same kind of attack could be launched via REMOVE_ADDR messages, but this would not succeed since this is specified with some protection - ensuring the subflow is really unavailable through the use of TCP keepalive signals. This same protection cannot be used against the MP_PRIO since the referenced subflow is not unavailable. > >>> > >>> If the WG considered this risk worth addressing, we could look at adding a nonce + signature to MP_PRIO. > >> > >> Since the attacker is on path, this does not help if the attacker is on the > >> first path. > > That scenario has always been out of scope. If an attacker has observed the initial exchange, all bets are off, and we are only as secure as single-path TCP. > > >>> We discuss several solutions in a forthcoming paper [ICNP2017], but a > >>> simple approach to cope with this attack would be to reconsider the > >>> utilisation of the address identifier in the MP_PRIO option. This > >>> option allows a host to set/change the priority of all the subflows > >>> associated to a given address identifier on another subflow. It could > >>> have use cases, such as sending MP_PRIO over a WiFi subflow to put the > >>> cellular subflow in backup mode without sending a packet over the > >>> cellular interface, but this looks like an edge case. Looking at the > >>> attack that we have identified, the working group should evaluate the > >>> removal of the address identifier in rfc6824bis. If the MP_PRIO option > >>> does not include an address identifier, then it becomes impossible for > >>> an attacker who is on-path of a given subflow to change the priority > >>> of the other subflows. > >> > >> Remove the address identifier from the MP_PRIO seems a safe solution to me. > >> I do not see a benefit in sending MP_PRIO on another subflow than the one > >> that you want to affect. > > > > +1 > > > > As far as I know, there is no implementation that relies on the address-ID > > in the MP_PRIO to signal the priorities. > > So the main reason for this was to permit the signalling of backup for a subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a ‘B’ bit in it, so the priority would be signalled separately. > > We could add the prio bit to ADD_ADDR to resolve this issue. However, this limits extensibility in MP_PRIO e.g. with other signals which have been suggested in the past ("backup but do not open”, use for differing traffic types, etc). I think it's ok to add the prio-bit to the ADD_ADDR. I'm not sure though to what extend it would limit the extensibility of MP_PRIO. Christoph From nobody Thu Jul 20 10:31:59 2017 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 AC47F131D15; Thu, 20 Jul 2017 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 oJjf33BqaWX3; Thu, 20 Jul 2017 10:31:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244D2131D16; Thu, 20 Jul 2017 10:31:42 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v6KHVCYr012125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 10:31:12 -0700 (PDT) To: =?UTF-8?Q?Drago=c8=99_Niculescu?= Cc: Vladimir Olteanu , multipathtcp , int-area References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro> <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> <2ff22633-8f12-f4ef-868f-9c6c698ae32f@isi.edu> <5c61bf79-5a8f-65cf-e6b7-02a29db37073@cs.pub.ro> <1cf7caa4-22a2-b61a-662f-8927197baf09@isi.edu> <1332604938.42424.1500535343962.JavaMail.zimbra@cs.pub.ro> From: Joe Touch Message-ID: Date: Thu, 20 Jul 2017 10:31:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1332604938.42424.1500535343962.JavaMail.zimbra@cs.pub.ro> Content-Type: multipart/alternative; boundary="------------96D6D3F36809CF0D970177F4" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:31:51 -0000 This is a multi-part message in MIME format. --------------96D6D3F36809CF0D970177F4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/20/2017 12:22 AM, Dragoș Niculescu wrote: >> I.e., if you do everything right, you MIGHT end up looking "LIKE" you >> rewrote the TCP SYN as it "passes through", but speaking of that as the >> actual mechanism violates TCP. > It looks like that IF the client has idempotent data, and IF the client uses TFO API, and IF the proxy enables TFO as a client and as a server, and IF the actual server supports TFO. So, there are a lot of IFs to get that kind of performance, but as shown in slide 9 of the presentation [1], it does work with standard API, only twice as slow. Agreed, but the text could be much more clear that this is the goal and expected outcome. Joe --------------96D6D3F36809CF0D970177F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 7/20/2017 12:22 AM, Dragoș Niculescu wrote:
I.e., if you do everything right, you MIGHT end up looking "LIKE" you
rewrote the TCP SYN as it "passes through", but speaking of that as the
actual mechanism violates TCP.

It looks like that IF the client has idempotent data, and IF the client uses TFO API, and IF the proxy enables TFO as a client and as a server, and IF the actual server supports TFO. So, there are a lot of IFs to get that kind of performance, but as shown in slide 9 of the presentation [1], it does work with standard API, only twice as slow.
Agreed, but the text could be much more clear that this is the goal and expected outcome.

Joe
--------------96D6D3F36809CF0D970177F4-- From nobody Thu Jul 20 14:22:51 2017 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 0A8B51201F2 for ; Thu, 20 Jul 2017 14:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 CsYDYSpHyo9b for ; Thu, 20 Jul 2017 14:22:41 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977AA129482 for ; Thu, 20 Jul 2017 14:22:41 -0700 (PDT) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B352B27844A for ; Fri, 21 Jul 2017 06:22:39 +0900 (JST) Received: by mail-it0-f50.google.com with SMTP id h199so22609830ith.0 for ; Thu, 20 Jul 2017 14:22:39 -0700 (PDT) X-Gm-Message-State: AIVw1123gZ+VZbLB6aRopXoGWI8cseKegE0DM2Vqpz1cLCdjFbaW3S7T SJyvnLNyk9thROFYIPvhD0Uy2+e/FQ== X-Received: by 10.36.200.66 with SMTP id w63mr4551446itf.13.1500585758464; Thu, 20 Jul 2017 14:22:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.19 with HTTP; Thu, 20 Jul 2017 14:22:37 -0700 (PDT) In-Reply-To: References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> From: Yoshifumi Nishida Date: Thu, 20 Jul 2017 14:22:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Cc: Christoph Paasch , Ali Munir , multipathtcp , Franck Le , Alex Liu , Zubair Content-Type: multipart/alternative; boundary="94eb2c05a5dc16a2370554c6590b" Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 21:22:43 -0000 --94eb2c05a5dc16a2370554c6590b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan, On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford wrote: > > > So the main reason for this was to permit the signalling of backup for a > subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a = =E2=80=98B=E2=80=99 > bit in it, so the priority would be signalled separately. > I think adding 'B' bit in ADD_ADDR has been proposed to be added in the bis draft. I have seen a few supports while haven't seen any oppositions. Do we need more discussions on this? -- Yoshi --94eb2c05a5dc16a2370554c6590b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan,

On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford &l= t;alan.ford@gmail.= com> wrote:

So the main reason for this was to per= mit the signalling of backup for a subflow which was also signalled via ADD= _ADDR. ADD_ADDR does not have a =E2=80=98B=E2=80=99 bit in it, so the prior= ity would be signalled separately.

<= div>I think adding 'B' bit in ADD_ADDR has been proposed to be adde= d in the bis draft.=C2=A0
I have seen a few supports while haven&= #39;t seen any oppositions.=C2=A0
Do we need more discussions on = this?
--
Yoshi

--94eb2c05a5dc16a2370554c6590b-- From nobody Fri Jul 21 00:45:09 2017 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 DD56312714F for ; Fri, 21 Jul 2017 00:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ySLhVCg8txZI for ; Fri, 21 Jul 2017 00:45:07 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CAF124217 for ; Fri, 21 Jul 2017 00:45:07 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id f21so22597511wrf.5 for ; Fri, 21 Jul 2017 00:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=BU0Y/AQBb+n3M8564odzFF0wTg5rsv4e4NMd6HcBkr8=; b=YAEQqcfb3WjuKMirtFIXTjd19LljwsebjgQaNYFIbJFinELRSNzjehl9gqv6qpgffq sODUK/EMkszgiQddCnPGI+QxITI7tqz9zIM0uZGmhyMS0qqFwd5ux3/kZ9YDDljew7bC E+u6FNTxo0SriktnIWtoYLYlPF98xk/Uu067fR/6R/WHACkzMDrzqpPzxkIbEWDQkZSS zxWkyc8liUdJH3mI0P+GbBjqLLR3y5kYQPWWz3DUxhU406prNubOqIHyxzThhST6MF42 OSO8qT0ryIKWvHFWypmbga7hOAt2OhUfW63nrb8xR0yKpMYpBWZIvUvmlAhAnFfnTlxF myFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BU0Y/AQBb+n3M8564odzFF0wTg5rsv4e4NMd6HcBkr8=; b=q962WWabvLy9dBQXzriW3fRIzlyqEx0mKssHu/Jl0hyESWksx0UhNSyMHhoAX3ujFl kRiFM7u2gXesNW+YISylEDJ155U8A4wSqZ4AOx+xDk88NSfCOhyhWSpDGOpvsjQlkR6D jhCfSy6TXI/U3Jr8SZzzLRWrqLp8vK8Ma/65pwz//f6Az/7siiVGafHvTZytKjaxKE7e Z5aPJ+uxoOH0ZRpaYRQZILaU8gRo63U531Oabc62Rfl0eRHTzYBkhQGM8ctXlnSVLT91 yLZwr5+9SFBoi1Q1Z838ZxYrcLbDoeyv8cLtVcR62cbCJcyTLg2U/cGyB7rQpCMnuhP7 xvJw== X-Gm-Message-State: AIVw112j9/PZRhwfwzD8PJSNOu0fNgRDh5Jt1yjXBoZwRTcCQRCs/BQa 7bvVoNo4GZO2CA== X-Received: by 10.223.176.164 with SMTP id i33mr5383271wra.221.1500623105616; Fri, 21 Jul 2017 00:45:05 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:3d2a:5e4a:b918:5c02? ([2001:67c:370:128:3d2a:5e4a:b918:5c02]) by smtp.gmail.com with ESMTPSA id l46sm8853681wrl.15.2017.07.21.00.45.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 21 Jul 2017 00:45:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5A1BA00F-2C67-4C39-A2F9-7208801997BB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Fri, 21 Jul 2017 08:45:03 +0100 Cc: Christoph Paasch , Ali Munir , multipathtcp , Franck Le , Alex Liu , Zubair Message-Id: References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:45:09 -0000 --Apple-Mail=_5A1BA00F-2C67-4C39-A2F9-7208801997BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoshi, > On 20 Jul 2017, at 22:22, Yoshifumi Nishida = wrote: >=20 > On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford > wrote: >=20 > So the main reason for this was to permit the signalling of backup for = a subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have = a =E2=80=98B=E2=80=99 bit in it, so the priority would be signalled = separately. >=20 > I think adding 'B' bit in ADD_ADDR has been proposed to be added in = the bis draft.=20 > I have seen a few supports while haven't seen any oppositions.=20 > Do we need more discussions on this? Actually on further reflection (i.e. Christoph and Olivier reminding me = offline), this would be unnecessary, since MP_JOIN has a =E2=80=98B=E2=80=99= bit so it is not required in ADD_ADDR. Given this I can see no reason to have the Address ID in MP_PRIO and = feel we can remove it. (The proposal for a bit in ADD_ADDR was, I believe, as a =E2=80=9Cdo not = even attempt to establish to this address unless all other subflows fail = - which is different to the =E2=80=98B=E2=80=99 semantics in MP_PRIO and = MP_JOIN) Regards, Alan --Apple-Mail=_5A1BA00F-2C67-4C39-A2F9-7208801997BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Yoshi,

On 20 Jul 2017, at 22:22, = Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

On Thu, = Jul 20, 2017 at 8:33 AM, Alan Ford <alan.ford@gmail.com> wrote:

So the = main reason for this was to permit the signalling of backup for a = subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a = =E2=80=98B=E2=80=99 bit in it, so the priority would be signalled = separately.

I think adding 'B' bit in ADD_ADDR has = been proposed to be added in the bis draft. 
I = have seen a few supports while haven't seen any = oppositions. 
Do we need more discussions on = this?

Actually on further reflection (i.e. Christoph and = Olivier reminding me offline), this would be unnecessary, since MP_JOIN = has a =E2=80=98B=E2=80=99 bit so it is not required in = ADD_ADDR.

Given this I can see = no reason to have the Address ID in MP_PRIO and feel we can remove = it.

(The proposal for a bit in = ADD_ADDR was, I believe, as a =E2=80=9Cdo not even attempt to establish = to this address unless all other subflows fail - which is different to = the =E2=80=98B=E2=80=99 semantics in MP_PRIO and MP_JOIN)

Regards,
Alan

= --Apple-Mail=_5A1BA00F-2C67-4C39-A2F9-7208801997BB-- From nobody Fri Jul 21 13:37:54 2017 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 EFC34129B61 for ; Fri, 21 Jul 2017 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Yu7F5GHsWXGC for ; Fri, 21 Jul 2017 13:37:51 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223EA129AD2 for ; Fri, 21 Jul 2017 13:37:50 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5A05C2784AE for ; Sat, 22 Jul 2017 05:37:48 +0900 (JST) Received: by mail-io0-f172.google.com with SMTP id l7so26634652iof.1 for ; Fri, 21 Jul 2017 13:37:48 -0700 (PDT) X-Gm-Message-State: AIVw110V0JYfO04wOsNONaFIaT5GVqbgCBPE7DsVIv+2oAqACRgCR3MR 78G2sO7hprV1n9WGROdL4IoW3T91vA== X-Received: by 10.107.36.136 with SMTP id k130mr8303470iok.7.1500669466957; Fri, 21 Jul 2017 13:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.19 with HTTP; Fri, 21 Jul 2017 13:37:46 -0700 (PDT) In-Reply-To: References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> From: Yoshifumi Nishida Date: Fri, 21 Jul 2017 13:37:46 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Cc: Yoshifumi Nishida , Christoph Paasch , Ali Munir , multipathtcp , Franck Le , Alex Liu , Zubair Content-Type: multipart/alternative; boundary="001a1140e33080e0450554d9d629" Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 20:37:53 -0000 --001a1140e33080e0450554d9d629 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan, On Fri, Jul 21, 2017 at 12:45 AM, Alan Ford wrote: > Hi Yoshi, > > On 20 Jul 2017, at 22:22, Yoshifumi Nishida > wrote: > > On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford wrote: >> >> >> So the main reason for this was to permit the signalling of backup for a >> subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a = =E2=80=98B=E2=80=99 >> bit in it, so the priority would be signalled separately. >> > > I think adding 'B' bit in ADD_ADDR has been proposed to be added in the > bis draft. > I have seen a few supports while haven't seen any oppositions. > Do we need more discussions on this? > > > Actually on further reflection (i.e. Christoph and Olivier reminding me > offline), this would be unnecessary, since MP_JOIN has a =E2=80=98B=E2=80= =99 bit so it is > not required in ADD_ADDR. > > Given this I can see no reason to have the Address ID in MP_PRIO and feel > we can remove it. > > (The proposal for a bit in ADD_ADDR was, I believe, as a =E2=80=9Cdo not = even > attempt to establish to this address unless all other subflows fail - whi= ch > is different to the =E2=80=98B=E2=80=99 semantics in MP_PRIO and MP_JOIN) > Yes, I thought it's a valid use case. If we remove addr id from MP_PRIO, I think we will always need to establish a subflow to make it backup. -- Yoshi --001a1140e33080e0450554d9d629 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan,

On Fri, Jul 21, 2017 at 12:45 AM, Alan Ford &= lt;alan.ford@gmail= .com> wrote:
Hi Yoshi,

On 20 Jul 2017, at 22:22, Yoshifumi Nishida <nishida@sfc.wide.ad.jp= > wrote:

On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford <alan.ford@gmail.com<= /a>> wrote:

So the main reason for this was to permit = the signalling of backup for a subflow which was also signalled via ADD_ADD= R. ADD_ADDR does not have a =E2=80=98B=E2=80=99 bit in it, so the priority = would be signalled separately.

= I think adding 'B' bit in ADD_ADDR has been proposed to be added in= the bis draft.=C2=A0
I have seen a few supports while haven'= t seen any oppositions.=C2=A0
Do we need more discussions on this= ?

Actually = on further reflection (i.e. Christoph and Olivier reminding me offline), th= is would be unnecessary, since MP_JOIN has a =E2=80=98B=E2=80=99 bit so it = is not required in ADD_ADDR.

Given this I ca= n see no reason to have the Address ID in MP_PRIO and feel we can remove it= .

(The proposal for a bit in ADD_ADDR was, I belie= ve, as a =E2=80=9Cdo not even attempt to establish to this address unless a= ll other subflows fail - which is different to the =E2=80=98B=E2=80=99 sema= ntics in MP_PRIO and MP_JOIN)
=C2=A0
Yes, I thought it's a valid use case.
If we remove addr id from MP_PRIO, I think we will always need to establis= h a subflow to make it backup.
--
Yoshi
--001a1140e33080e0450554d9d629-- From nobody Sun Jul 23 06:04:24 2017 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 96C31129AA8 for ; Sun, 23 Jul 2017 06:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 283VYc8knrwv for ; Sun, 23 Jul 2017 06:04:22 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421031270B4 for ; Sun, 23 Jul 2017 06:04:22 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id g131so7782537oic.3 for ; Sun, 23 Jul 2017 06:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R1oQP37YoCljUPWHBr4bfXACol5pTSQiDzgWzbT3spk=; b=B9ifDBOcq6wTjSixYtAJxrhwIj+E3KVTROEF1aZZlstFNKQt02DM9MurTGuZCVa+IH y/YaYzeeUWzIebJ8Gdk2aMOz+Gp8Wkq9mL8fSgHNzmHh78tuY++AIPdC9TGW173z9W/F kA1CsSOmXVrvcbWu7ShaJMB3ZMAiyoBSK3DYKGnwxh98JisQiqZtaubUpOvhcumyotYF XH6A5+w6UugGL55UlaitILjjkIABIxr/LaNA5s05FnFY6MDV0aQNF+mFHu/KtU/uDp1A vLWe2OR36bj/3vPc1b/R1g5QBEcLc/1crnSkDICLcr9rRBN1Hs9kVaAkaU/VN+9bLopS O8ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R1oQP37YoCljUPWHBr4bfXACol5pTSQiDzgWzbT3spk=; b=Vgf9Rm6ngW2dEW2KkwyPl9j+FPTqISSSS0CAoJGefEyPC/XxxrZgBU85gCHFmKfL35 cSKk2j+TXVahwUKFFAnjKIgZIgC0De5qbKA6RxO1WFf3kpberDG0G2JmL/r1W4Du0Q9M 0oSUoMEFKO/1BwGGylfabyiHFkybAq5+JiMScmLwpKyuHlNZ5sZFo8ObXWXZdJCmhbWx ohXU8WKzUVBcwVizYE5j1ZNTSh4nEdZfG2git7oohm/36ccStdH8UCR/94AQJ5UbfrAb GEtnSuLdv9OByAWhlMBdsnVl6OZbG6IeqmPIAJJX7AuXj9u9xz57EX7YsDID/kp9ptlU N2kg== X-Gm-Message-State: AIVw111M/DUnSFJempbPHE+OJV0i6lUPcqC260ohI1PF70mTdxVtbIrH sKP2E3kFAhNxdbdoefGiXdVcwB7Paw== X-Received: by 10.202.61.195 with SMTP id k186mr4997004oia.19.1500815061647; Sun, 23 Jul 2017 06:04:21 -0700 (PDT) MIME-Version: 1.0 References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> In-Reply-To: From: Alan Ford Date: Sun, 23 Jul 2017 13:04:11 +0000 Message-ID: To: Yoshifumi Nishida Cc: Alex Liu , Ali Munir , Christoph Paasch , Franck Le , Zubair , multipathtcp Content-Type: multipart/alternative; boundary="001a113dd1209f87ad0554fbbc36" Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 13:04:24 -0000 --001a113dd1209f87ad0554fbbc36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yoshi, On Fri, 21 Jul 2017 at 22:37, Yoshifumi Nishida wrote: > Hi Alan, > > On Fri, Jul 21, 2017 at 12:45 AM, Alan Ford wrote: > >> Hi Yoshi, >> >> On 20 Jul 2017, at 22:22, Yoshifumi Nishida >> wrote: >> >> On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford wrote: >>> >>> >>> So the main reason for this was to permit the signalling of backup for = a >>> subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a= =E2=80=98B=E2=80=99 >>> bit in it, so the priority would be signalled separately. >>> >> >> I think adding 'B' bit in ADD_ADDR has been proposed to be added in the >> bis draft. >> I have seen a few supports while haven't seen any oppositions. >> Do we need more discussions on this? >> >> >> Actually on further reflection (i.e. Christoph and Olivier reminding me >> offline), this would be unnecessary, since MP_JOIN has a =E2=80=98B=E2= =80=99 bit so it is >> not required in ADD_ADDR. >> >> Given this I can see no reason to have the Address ID in MP_PRIO and fee= l >> we can remove it. >> >> (The proposal for a bit in ADD_ADDR was, I believe, as a =E2=80=9Cdo not= even >> attempt to establish to this address unless all other subflows fail - wh= ich >> is different to the =E2=80=98B=E2=80=99 semantics in MP_PRIO and MP_JOIN= ) >> > > Yes, I thought it's a valid use case. > If we remove addr id from MP_PRIO, I think we will always need to > establish a subflow to make it backup. > That has always been the case - MP_PRIO only affects running subflows. With Address ID it could have affected policy on subflows that were later established, but would not affect subflow establishment policy. The proposal to signal a break-before-make backup flag has been suggested but has not received sufficient traction to be adopted. Regards, Alan --001a113dd1209f87ad0554fbbc36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yoshi,

On Fri, 21 Jul 2017 at 22:37, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi Alan,

On Fri, Jul 21, 2017 at 12:45 AM, Alan Ford <alan.ford@gmail.com> w= rote:
Hi Yoshi,

On 20 Jul 2017= , at 22:22, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

=
On Thu, Jul 20, = 2017 at 8:33 AM, Alan Ford <alan.ford@gmail.com> wrote:

So = the main reason for this was to permit the signalling of backup for a subfl= ow which was also signalled via ADD_ADDR. ADD_ADDR does not have a =E2=80= =98B=E2=80=99 bit in it, so the priority would be signalled separately.

I think adding 'B' bit in = ADD_ADDR has been proposed to be added in the bis draft.=C2=A0
I = have seen a few supports while haven't seen any oppositions.=C2=A0
Do we need more discussions on this?

Actually on further reflection (i.e. Christ= oph and Olivier reminding me offline), this would be unnecessary, since MP_= JOIN has a =E2=80=98B=E2=80=99 bit so it is not required in ADD_ADDR.
=

Given this I can see no reason to have the Addres= s ID in MP_PRIO and feel we can remove it.

(The pr= oposal for a bit in ADD_ADDR was, I believe, as a =E2=80=9Cdo not even atte= mpt to establish to this address unless all other subflows fail - which is = different to the =E2=80=98B=E2=80=99 semantics in MP_PRIO and MP_JOIN)
=C2=A0
Yes, I thought it's a valid use case.
If we remove addr id from MP_PRIO, I think we will always need t= o establish a subflow to make it backup.

That has always been the case - MP_PR= IO only affects running subflows. With Address ID it could have affected po= licy on subflows that were later established, but would not affect subflow = establishment policy.

Th= e proposal to signal a break-before-make backup flag has been suggested but= has not received sufficient traction to be adopted.

Regards,
Alan

--001a113dd1209f87ad0554fbbc36-- From nobody Sun Jul 23 23:29:39 2017 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 547D112EC55 for ; Sun, 23 Jul 2017 23:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 BXQJAnc38iKK for ; Sun, 23 Jul 2017 23:29:36 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3601512EC30 for ; Sun, 23 Jul 2017 23:29:35 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 994C0278406 for ; Mon, 24 Jul 2017 15:29:33 +0900 (JST) Received: by mail-io0-f169.google.com with SMTP id j32so18764183iod.0 for ; Sun, 23 Jul 2017 23:29:33 -0700 (PDT) X-Gm-Message-State: AIVw113A38vV3SGxFjDrwaVnv8IwxI2CQhTMBfzmpbaQ+JfA20N7mtCC 3cwFAQSXE3WRTqD4VQBHIXtvaIZSdw== X-Received: by 10.107.36.136 with SMTP id k130mr14059379iok.7.1500877772315; Sun, 23 Jul 2017 23:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.19 with HTTP; Sun, 23 Jul 2017 23:29:31 -0700 (PDT) In-Reply-To: References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> From: Yoshifumi Nishida Date: Sun, 23 Jul 2017 23:29:31 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Cc: Yoshifumi Nishida , Alex Liu , Ali Munir , Christoph Paasch , Franck Le , Zubair , multipathtcp Content-Type: multipart/alternative; boundary="001a1140e33078610f05550a5602" Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 06:29:38 -0000 --001a1140e33078610f05550a5602 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan, On Sun, Jul 23, 2017 at 6:04 AM, Alan Ford wrote: > Hi Yoshi, > > On Fri, 21 Jul 2017 at 22:37, Yoshifumi Nishida > wrote: > >> Hi Alan, >> >> On Fri, Jul 21, 2017 at 12:45 AM, Alan Ford wrote: >> >>> Hi Yoshi, >>> >>> On 20 Jul 2017, at 22:22, Yoshifumi Nishida >>> wrote: >>> >>> On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford wrote: >>>> >>>> >>>> So the main reason for this was to permit the signalling of backup for >>>> a subflow which was also signalled via ADD_ADDR. ADD_ADDR does not hav= e a >>>> =E2=80=98B=E2=80=99 bit in it, so the priority would be signalled sepa= rately. >>>> >>> >>> I think adding 'B' bit in ADD_ADDR has been proposed to be added in the >>> bis draft. >>> I have seen a few supports while haven't seen any oppositions. >>> Do we need more discussions on this? >>> >>> >>> Actually on further reflection (i.e. Christoph and Olivier reminding me >>> offline), this would be unnecessary, since MP_JOIN has a =E2=80=98B=E2= =80=99 bit so it is >>> not required in ADD_ADDR. >>> >>> Given this I can see no reason to have the Address ID in MP_PRIO and >>> feel we can remove it. >>> >>> (The proposal for a bit in ADD_ADDR was, I believe, as a =E2=80=9Cdo no= t even >>> attempt to establish to this address unless all other subflows fail - w= hich >>> is different to the =E2=80=98B=E2=80=99 semantics in MP_PRIO and MP_JOI= N) >>> >> >> Yes, I thought it's a valid use case. >> If we remove addr id from MP_PRIO, I think we will always need to >> establish a subflow to make it backup. >> > > That has always been the case - MP_PRIO only affects running subflows. > With Address ID it could have affected policy on subflows that were later > established, but would not affect subflow establishment policy. > > The proposal to signal a break-before-make backup flag has been suggested > but has not received sufficient traction to be adopted. > Right. But, I am wondering if we might want to think about it again just in case. Let's say a server has two address S1, S2 while the client is behind FW. As the client is behind firewall, the server uses ADD_ADDR to send the info for S2, but it want it to be used as a backup. In this case, if MP_PRIO has addr id field, the server is able to set the addr as a backup. But, if MP_PRIO doesn't have addr id, all the server can do is to wait until the client establishes the connection with S2. -- Yoshi --001a1140e33078610f05550a5602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan,

On Sun, Jul 23, 2017 at 6:04 AM, Alan Ford &l= t;alan.ford@gmail.= com> wrote:
Hi Yoshi,

On Fri, 21 Jul 2017 at 22:37, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wr= ote:
Hi Alan,

On Fri, Jul 21, 2017 at 12:45 AM, Alan Ford <alan.ford@gmail.com&g= t; wrote:
Hi Yoshi,

On = 20 Jul 2017, at 22:22, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
On Thu, Jul 20, 2017 at 8:33 AM, Ala= n Ford <a= lan.ford@gmail.com> wrote:

So the main reason for = this was to permit the signalling of backup for a subflow which was also si= gnalled via ADD_ADDR. ADD_ADDR does not have a =E2=80=98B=E2=80=99 bit in i= t, so the priority would be signalled separately.
<= div>
I think adding 'B' bit in ADD_ADDR has been prop= osed to be added in the bis draft.=C2=A0
I have seen a few suppor= ts while haven't seen any oppositions.=C2=A0
Do we need more = discussions on this?

Actually on further reflection (i.e. Christoph and Olivier remind= ing me offline), this would be unnecessary, since MP_JOIN has a =E2=80=98B= =E2=80=99 bit so it is not required in ADD_ADDR.

=
Given this I can see no reason to have the Address ID in MP_PRIO and f= eel we can remove it.

(The proposal for a bit in A= DD_ADDR was, I believe, as a =E2=80=9Cdo not even attempt to establish to t= his address unless all other subflows fail - which is different to the =E2= =80=98B=E2=80=99 semantics in MP_PRIO and MP_JOIN)
=
=C2=A0
Yes, I t= hought it's a valid use case.
If we rem= ove addr id from MP_PRIO, I think we will always need to establish a subflo= w to make it backup.

That has always been the case - MP_PRIO only affects= running subflows. With Address ID it could have affected policy on subflow= s that were later established, but would not affect subflow establishment p= olicy.

The proposal to s= ignal a break-before-make backup flag has been suggested but has not receiv= ed sufficient traction to be adopted.
Right. But, I am wondering if we might want to think about it = again just in case.=C2=A0

Let's say a server h= as two address S1, S2 while the client is behind FW. As the client is behin= d firewall, the server uses ADD_ADDR to send the info for S2, but it want i= t to be used as a backup.=C2=A0

In this case, if M= P_PRIO has addr id field, the server is able to set the addr as a backup.
But, if MP_PRIO doesn't have addr id, all the server can do is= to wait until the client establishes the connection with S2.=C2=A0
--
Yoshi

=C2=A0

--001a1140e33078610f05550a5602-- From nobody Mon Jul 24 00:37:02 2017 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 4CF7E131C20 for ; Mon, 24 Jul 2017 00:37:01 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 5-kp3AKLLbx0 for ; Mon, 24 Jul 2017 00:36:59 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0FD126C22 for ; Mon, 24 Jul 2017 00:36:59 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.241.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 20CA567DBC4; Mon, 24 Jul 2017 09:36:44 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 20CA567DBC4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1500881804; bh=Ol9LwvY8LbmvqAKkQXO3rjOKINcUKdrD+YYD3FclbkM=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=BLjnuoeayXXPu6+xYKt7PWPD5S2M1dorSbBnTRoCTllMCsY7wULQLuYCTIMo3Ded+ 0RSBlNIiT2gVL/IgmNwLyE1WU+3WIhn/t0j/RmurOOB45s8dG6Zqwgi4UZrr/9W60t fPE2naGmVnNm6WTo0yWkq5vEfwjn2yqishe152s4= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Reply-To: Olivier.Bonaventure@uclouvain.be To: Yoshifumi Nishida , Alan Ford Cc: Ali Munir , multipathtcp , Franck Le , Alex Liu , Zubair References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> From: Olivier Bonaventure Message-ID: Date: Mon, 24 Jul 2017 09:36:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 8bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 20CA567DBC4.A382C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 07:37:01 -0000 Hello, >> So the main reason for this was to permit the >> signalling of backup for a subflow which was also >> signalled via ADD_ADDR. ADD_ADDR does not have a ‘B’ >> bit in it, so the priority would be signalled separately. >> >> >> I think adding 'B' bit in ADD_ADDR has been proposed to be >> added in the bis draft. >> I have seen a few supports while haven't seen any >> oppositions. >> Do we need more discussions on this? > > Actually on further reflection (i.e. Christoph and Olivier > reminding me offline), this would be unnecessary, since > MP_JOIN has a ‘B’ bit so it is not required in ADD_ADDR. > > Given this I can see no reason to have the Address ID in > MP_PRIO and feel we can remove it. > > (The proposal for a bit in ADD_ADDR was, I believe, as a “do > not even attempt to establish to this address unless all > other subflows fail - which is different to the ‘B’ > semantics in MP_PRIO and MP_JOIN) > > Yes, I thought it's a valid use case. > If we remove addr id from MP_PRIO, I think we will always need > to establish a subflow to make it backup. > > > That has always been the case - MP_PRIO only affects running > subflows. With Address ID it could have affected policy on subflows > that were later established, but would not affect subflow > establishment policy. > > The proposal to signal a break-before-make backup flag has been > suggested but has not received sufficient traction to be adopted. > > > Right. But, I am wondering if we might want to think about it again just > in case. > > Let's say a server has two address S1, S2 while the client is behind FW. > As the client is behind firewall, the server uses ADD_ADDR to send the > info for S2, but it want it to be used as a backup. > > In this case, if MP_PRIO has addr id field, the server is able to set > the addr as a backup. > But, if MP_PRIO doesn't have addr id, all the server can do is to wait > until the client establishes the connection with S2. If we want to associate a backup status to an address, which could have valid use cases, then I'd suggest to use one of the spare bits of the ADD_ADDR option for this. As mentioned earlier, the semantics of the backup bit in the ADD_ADDR differs from the semantics of the backup bit in MP_JOIN/MP_PRIO. In MP_JOIN, it means "don't use this subflow is non-backup subflows are active". In ADD_ADDR, it would mean "don't use this address to establish a subflow if subflows to non-backup addresses are still active" Having both could make sense Olivier From nobody Mon Jul 24 01:40:13 2017 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 66B0112EC30 for ; Mon, 24 Jul 2017 01:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 kMztUztE8up3 for ; Mon, 24 Jul 2017 01:40:10 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684A5129ACD for ; Mon, 24 Jul 2017 01:40:10 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 6B6CEA0431; Mon, 24 Jul 2017 10:40:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 0B2B41A06D8; Mon, 24 Jul 2017 10:40:08 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0352.000; Mon, 24 Jul 2017 10:40:07 +0200 From: To: "quentin.deconinck@uclouvain.be" CC: multipathtcp Thread-Topic: Multipath TCP with NAT64 Networks Thread-Index: AdMEWHPC9BK15jrHSiyLh2Aws25FVQ== Date: Mon, 24 Jul 2017 08:40:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A012377@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A012377OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Multipath TCP with NAT64 Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 08:40:12 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A012377OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Quentin, As mentioned in the mic during the MPTCP session, the problem you described= is a real one, but applies to all applications making use of referrals. Be= low a list of specifications that address the generic problem together with= the solutions in that space: * RFC7050 : Discovery of the IPv6 Prefix Used for IPv6 Address Synt= hesis * RFC7051 : Analysis of Solution Proposals for Hosts to Learn NAT64= Prefix * RFC7225 : Discovering NAT64 IPv6 Prefixes Using the Port Control = Protocol * RFC6877 : 464XLAT * RFC 6535 : BIH * draft-boucadair-pcp-nat64-experiments: To illustrate how local ad= dress synthesis can be implemented in the host for the particular case of S= IP/SDP. Some of these features are part the IPv6 mobile device profile requested by= many operators: * RFC7849 : An IPv6 Profile for 3GPP Mobile Devices See in particular, this recommendation: C_REC#7: In order to ensure IPv4 service continuity in an IPv6-only deployment context, the cellular host should support a method to learn PREFIX64(s). In the context of NAT64, IPv6-enabled applications relying on address referrals will fail because an IPv6-only client will not be able to make use of an IPv4 address received in a referral. This feature allows for solving the referral problem (because an IPv6-enabled application can construct IPv4-embedded IPv6 addresses [RFC6052]) and, also, = for distinguishing between IPv4-converted IPv6 addresses and native IPv6 addresses. In other words, this feature contributes to offload both the CLAT module and NAT64 devices. Refer to Section 3 of [RFC7051]= for an inventory of the issues related to the discovery of PREFIX64(s). Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A012377OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Quentin,

 

As mentioned in the mic during the MPTCP se= ssion, the problem you described is a real one, but applies to all applicat= ions making use of referrals. Below a list of specifications that address the generic problem together with the solutions in that space= :

 

·     &= nbsp;   RFC7050 : Discovery of the IPv= 6 Prefix Used for IPv6 Address Synthesis

·     &= nbsp;   RFC7051 : Analysis of Solution Prop= osals for Hosts to Learn NAT64 Prefix

·     &= nbsp;   RFC7225 : Discovering NAT64 IPv6 Pr= efixes Using the Port Control Protocol

·     &= nbsp;   RFC6877 : 464XLAT=

·     &= nbsp;   RFC 6535 : BIH

·     &= nbsp;   draft-boucadair-pcp-nat64-experimen= ts: To illustrate how local address synthesis can be implemented in the hos= t for the particular case of SIP/SDP.

 

Some of these features are part the IPv6 mo= bile device profile requested by many operators:

·     &= nbsp;   RFC7849 : An IPv6 Profile for 3GPP = Mobile Devices

 

See in particular, this recommendation:

 

   C_REC#7:  In order to ensure IP=
v4 service continuity in an IPv6-only
        &=
nbsp;    deployment context, the cellular host should suppor=
t a
        &=
nbsp;    method to learn PREFIX64(s).

 


        &=
nbsp;       In the context of NAT64, IPv6-ena=
bled applications


        &=
nbsp;       relying on address referrals will=
 fail because an


        &=
nbsp;       IPv6-only client will not be able=
 to make use of an IPv4


        &=
nbsp;       address received in a referral.&n=
bsp; This feature allows for


        &=
nbsp;       solving the referral problem (bec=
ause an IPv6-enabled


        &=
nbsp;       application can construct IPv4-em=
bedded IPv6 addresses


        &=
nbsp;       [RFC6052]) a=
nd, also, for distinguishing between


        &=
nbsp;       IPv4-converted IPv6 addresses and=
 native IPv6 addresses.


 


        &=
nbsp;       In other words, this feature cont=
ributes to offload both


        &=
nbsp;       the CLAT module and NAT64 devices=
.  Refer to Section 3


       =
         of [RFC7051] for an inventory of the issues related to


        &=
nbsp;       the discovery of PREFIX64(s).


 


Cheers,


Med
--_000_787AE7BB302AE849A7480A190F8B93300A012377OPEXCLILMA3corp_-- From nobody Wed Jul 26 00:51:32 2017 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 31B0E131545 for ; Wed, 26 Jul 2017 00:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 LwXBKDjQyMA6 for ; Wed, 26 Jul 2017 00:51:28 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68E51200FC for ; Wed, 26 Jul 2017 00:51:27 -0700 (PDT) Received: from EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 26 Jul 2017 08:51:22 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Jul 2017 08:51:24 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Jul 2017 08:51:24 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Wed, 26 Jul 2017 08:51:24 +0100 From: To: Thread-Topic: Changes to RFC6824bis Thread-Index: AdMF4tNWzyK6qEchQXuzuihLvNQscw== Date: Wed, 26 Jul 2017 07:51:23 +0000 Message-ID: <6ad50c5f057742c096fdd1f9088e551d@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: multipart/alternative; boundary="_000_6ad50c5f057742c096fdd1f9088e551drew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Changes to RFC6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 07:51:31 -0000 --_000_6ad50c5f057742c096fdd1f9088e551drew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, During the discussions in Prague, we had good agreement about the following= change to the bis. This is a change to the wire protocol. Please say as so= on as possible if you disagree with this change, otherwise we'll go ahead a= nd make this change:- Remove address identifier from MP-PRIO, as it can be used as an attack. Explanation at https://mailarchive.ietf.org/arch/msg/multipathtcp/WWWaQ3AKW= EMgsBSPKc_R9Ct_YoI and follow up emails. The issue was briefly summarised d= uring the Friday meeting in Prague - eg see the etherpad for a summary http= ://etherpad.tools.ietf.org:9000/p/notes-ietf-99-mptcp?useMonospaceFont=3Dtr= ue Alan - are you ok to make this change please? -- In addition, we agreed in principle to the following (informational) change= s to the bis - exact text to be proposed. 2. Guidance about MPTCP & TFP interactions, based on https://www.ietf= .org/proceedings/99/slides/slides-99-mptcp-sessb-mptcp-tfo-00.pdf - Christo= ph & Olivier, please propose text. 3. There was a suggestion, arising from the hackathon, to discuss on = the list whether clarifications or extra 'reason codes' would be useful in = the context of reset option. Quentin (& others), please make a proposal. Best wishes, Phil & Yoshi --_000_6ad50c5f057742c096fdd1f9088e551drew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

During the discussions in Prague, we had good agreement about the = following change to the bis. This is a change to the wire protocol. Please = say as soon as possible if you disagree with this change, otherwise we’ll go ahead and make this change:-

Remove= address identifier from MP-PRIO, as it can be used as an attack.

Explan= ation at https://mailarchive.ietf.org/arch/msg/multipathtcp/WWWaQ3AKWEMgsBSPKc_R9Ct_= YoI and follow up emails. The issue was briefly summarised during the F= riday meeting in Prague – eg see the etherpad for a summary http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-mptcp?useMonospaceFont= =3Dtrue

Alan &= #8211; are you ok to make this change please?

--

In add= ition, we agreed in principle to the following (informational) changes to t= he bis – exact text to be proposed.

2.    &nbs= p;  Guidance about MPTCP & TFP interactio= ns, based on https://www.ietf.org/proceedings/99/slides/slides-99-mptcp-sessb-mptcp-tfo-= 00.pdf - Christoph & Olivier, please propose text.

3.    &nbs= p;  There was a suggestion, arising from the hackathon= , to discuss on the list whether clarifications or extra ‘reason code= s’ would be useful in the context of reset option. Quentin (& oth= ers), please make a proposal.

Best wishes,

Phil & Yoshi

 

--_000_6ad50c5f057742c096fdd1f9088e551drew09926dag03bdomain1sy_-- From nobody Fri Jul 28 03:25:22 2017 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62335131947; Fri, 28 Jul 2017 03:25:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: multipathtcp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150123751435.25267.16302588399165140300@ietfa.amsl.com> Date: Fri, 28 Jul 2017 03:25:14 -0700 Archived-At: Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-09.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 10:25:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP WG of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Addresses Authors : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Christoph Paasch Filename : draft-ietf-mptcp-rfc6824bis-09.txt Pages : 73 Date : 2017-07-28 Abstract: TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824 [RFC6824] through clarifications and modifications primarily driven by deployment experience. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-rfc6824bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 28 03:27:30 2017 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 0F9591322B8 for ; Fri, 28 Jul 2017 03:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CLQ-nxzfxR08 for ; Fri, 28 Jul 2017 03:27:27 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E97D1322B7 for ; Fri, 28 Jul 2017 03:27:26 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id v105so123144195wrb.0 for ; Fri, 28 Jul 2017 03:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=g4rTSnfjkaJOswgcy12hdxyLgK+kRoJ+Y290KaVYKV8=; b=Imkzvy+uMizj5Nu/xBsGdEiq0yzjejKFsw6cb9xcsIUbv6Jce0t3T68+P0Fp2yCdra AzJKjsJtaty7I2yuCCMCSuFD5/WtTHwDqj3yebwT9QCIrHtwj+YhtWxdbNYk5Db5bIH8 JI5d74ZgKG13XxulZmH3W54n+w4115oAf3yoHoUdUxlnHPEJpoLgzY7dz4tDJp531A9o bOVRrc73N1MX0snZ+96OYnhNvUGPxT3LDr8y8yiDNPAEKfnt7hhg0db59xeo0Joct7+j /i/0tkTuv4xoZRadH1fP/RWbqXBX6QbdlzmByP/fz7xZRV2RxkSivhgWW9o+DVLZaSP4 yINg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=g4rTSnfjkaJOswgcy12hdxyLgK+kRoJ+Y290KaVYKV8=; b=eFyeIffr8mjMHZZsRYW36lP05X2HkpfZx+X2NREjauWVddIRGQGjItRJ4MolzwtFzM cZdoM7LGeip8IssbxcCAkfr+b1CF44F+e3henxL/E1t20z5YyCh6Dg1PPaUYk9M4AeDj +zDJNdeKp0+xd1hg481/RjFon4heSKsaDqNTIo9exP7i+z8tHxplLaAsGYvlpcJuoh7Y GMQo0C8CyEMCej1pFd/69iBHx/hjDiZi8e1mm4g84sL0eNFn0B0J1u9ecdzBZQfM/Nwg cAsoCOfnunpwcqVMOTrJDLi/LME3qgFPhp7G/7i7r6n9MWazSfJ1AqervBkIaLbEmOqU VYJQ== X-Gm-Message-State: AIVw1113P+0D0kmfj69H3GYXBZwQ8kPMN7KB7jOMkhBZRAwKVbAvFKVn wGhKLuy4YMJI4PuZoww= X-Received: by 10.223.139.3 with SMTP id n3mr5792487wra.249.1501237644335; Fri, 28 Jul 2017 03:27:24 -0700 (PDT) Received: from [10.44.30.233] (host81-143-209-108.in-addr.btopenworld.com. [81.143.209.108]) by smtp.gmail.com with ESMTPSA id r199sm4096482wmd.11.2017.07.28.03.27.23 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Jul 2017 03:27:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <150123751435.25267.16302588399165140300@ietfa.amsl.com> Date: Fri, 28 Jul 2017 11:27:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3E65B2D7-18BB-4175-A38E-A7385F807F5A@gmail.com> References: <150123751435.25267.16302588399165140300@ietfa.amsl.com> To: multipathtcp X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-09.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 10:27:29 -0000 Hi all, This removes the Address ID from MP_PRIO as per the WG consensus. It = also fixes a few typos. Regards, Alan > On 28 Jul 2017, at 11:25, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Multipath TCP WG of the IETF. >=20 > Title : TCP Extensions for Multipath Operation with = Multiple Addresses > Authors : Alan Ford > Costin Raiciu > Mark Handley > Olivier Bonaventure > Christoph Paasch > Filename : draft-ietf-mptcp-rfc6824bis-09.txt > Pages : 73 > Date : 2017-07-28 >=20 > Abstract: > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network and, thus, improve user > experience through higher throughput and improved resilience to > network failure. >=20 > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e., reliable > bytestream), and it provides the components necessary to establish > and use multiple TCP flows across potentially disjoint paths. >=20 > This document specifies v1 of Multipath TCP, obsoleting v0 as > specified in RFC6824 [RFC6824] through clarifications and > modifications primarily driven by deployment experience. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-09 > https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-rfc6824bis-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Fri Jul 28 18:20:49 2017 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 4190E131EA4 for ; Fri, 28 Jul 2017 18:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 n26vOlv8Q3le for ; Fri, 28 Jul 2017 18:20:45 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE005131E63 for ; Fri, 28 Jul 2017 18:20:44 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0D625278598 for ; Sat, 29 Jul 2017 10:20:42 +0900 (JST) Received: by mail-io0-f182.google.com with SMTP id c74so95362883iod.4 for ; Fri, 28 Jul 2017 18:20:41 -0700 (PDT) X-Gm-Message-State: AIVw1113QWvV2fYByNbNlx+9gRFXaAbev+f8M2GAlECmkLgfL0JUGf4a +llQUMO0Y2M7RZY5hz6W41bN6NW7RQ== X-Received: by 10.107.167.137 with SMTP id q131mr11491383ioe.66.1501291240931; Fri, 28 Jul 2017 18:20:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.19 with HTTP; Fri, 28 Jul 2017 18:20:40 -0700 (PDT) In-Reply-To: References: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu> <742E211F-F754-4149-88E2-3BE51645F49D@gmail.com> <20170720152058.GJ3049@Chimay.local> From: Yoshifumi Nishida Date: Fri, 28 Jul 2017 18:20:40 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Olivier.Bonaventure@uclouvain.be" Cc: Yoshifumi Nishida , Alan Ford , multipathtcp Content-Type: multipart/alternative; boundary="001a113f6b921ec84005556a9b64" Archived-At: Subject: Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 01:20:47 -0000 --001a113f6b921ec84005556a9b64 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 24, 2017 at 12:36 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > > >> The proposal to signal a break-before-make backup flag has been >> suggested but has not received sufficient traction to be adopted. >> >> >> Right. But, I am wondering if we might want to think about it again just >> in case. >> >> Let's say a server has two address S1, S2 while the client is behind FW. >> As the client is behind firewall, the server uses ADD_ADDR to send the info >> for S2, but it want it to be used as a backup. >> >> In this case, if MP_PRIO has addr id field, the server is able to set the >> addr as a backup. >> But, if MP_PRIO doesn't have addr id, all the server can do is to wait >> until the client establishes the connection with S2. >> > > If we want to associate a backup status to an address, which could have > valid use cases, then I'd suggest to use one of the spare bits of the > ADD_ADDR option for this. > > As mentioned earlier, the semantics of the backup bit in the ADD_ADDR > differs from the semantics of the backup bit in MP_JOIN/MP_PRIO. > > In MP_JOIN, it means "don't use this subflow is non-backup subflows are > active". > > In ADD_ADDR, it would mean "don't use this address to establish a subflow > if subflows to non-backup addresses are still active" > > Having both could make sense It makes sense to me. I personally think supporting only one semantic looks unbalanced design unless we are not very interested in setting backup status.. -- Yoshi --001a113f6b921ec84005556a9b64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 24, 2017 at 12:36 AM, Olivier Bonaventure <Olivier.= Bonaventure@uclouvain.be> wrote:

=C2=A0 =C2=A0 The proposal to signal a break-before-make backup flag has be= en
=C2=A0 =C2=A0 suggested but has not received sufficient traction to be adop= ted.


Right. But, I am wondering if we might want to think about it again just in= case.

Let's say a server has two address S1, S2 while the client is behind FW= . As the client is behind firewall, the server uses ADD_ADDR to send the in= fo for S2, but it want it to be used as a backup.

In this case, if MP_PRIO has addr id field, the server is able to set the a= ddr as a backup.
But, if MP_PRIO doesn't have addr id, all the server can do is to wait = until the client establishes the connection with S2.

If we want to associate a backup status to an address, which could have val= id use cases, then I'd suggest to use one of the spare bits of the ADD_= ADDR option for this.

As mentioned earlier, the semantics of the backup bit in the ADD_ADDR diffe= rs from the semantics of the backup bit in MP_JOIN/MP_PRIO.

In MP_JOIN, it means "don't use this subflow is non-backup subflow= s are active".

In ADD_ADDR, it would mean "don't use this address to establish a = subflow if subflows to non-backup addresses are still active"

Having both could make sense

It makes sense= to me. I personally think supporting only one semantic looks unbalanced de= sign unless we are not very interested in setting backup status..
--
Yoshi


=C2=A0
--001a113f6b921ec84005556a9b64--