From nobody Tue Jul 4 02:09:42 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916BE131C54 for ; Tue, 4 Jul 2017 02:09:41 -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 1V4ZsNQxDAkw for ; Tue, 4 Jul 2017 02:09:40 -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 CB0AE131C59 for ; Tue, 4 Jul 2017 02:09:39 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 35D231805D1; Tue, 4 Jul 2017 11:09:38 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id F12E71A0067; Tue, 4 Jul 2017 11:09:37 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0352.000; Tue, 4 Jul 2017 11:09:37 +0200 From: To: Vladimir Olteanu , David Schinazi CC: "Int-area@ietf.org" Thread-Topic: [Int-area] SOCKS 6 Draft Thread-Index: AQHS8cv1K2O61xXmpEylWB6CUh3tcaI9zO8AgAWW5eA= Date: Tue, 4 Jul 2017 09:09:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A000764@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> In-Reply-To: <3f975b41-78b0-9f50-6c46-cc8e30007f34@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.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A000764OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 09:09:41 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A000764OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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_787AE7BB302AE849A7480A190F8B93300A000764OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Vladimir, all,

 

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

 

I do fully agree that shortenin= g 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-network-as= sisted-mptcp-03.pdf which allows to achieve 0-RTT proxying.

 

Thank you.

 

Cheers,

Med

 

De&nb= sp;: Int-area [mailt= o: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 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_787AE7BB302AE849A7480A190F8B93300A000764OPEXCLILMA3corp_-- From nobody Tue Jul 4 16:35:32 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:22 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:01 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:59:57 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:59:55 -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 Wed Jul 5 12:21:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6B131479 for ; Wed, 5 Jul 2017 12:21:24 -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 5R2TVUVzOl85 for ; Wed, 5 Jul 2017 12:21:22 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 8CAB51319E5 for ; Wed, 5 Jul 2017 12:21:22 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 88E5625CA26D for ; Wed, 5 Jul 2017 19:21:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.rozanak.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urk4XyE3Z7_x for ; Wed, 5 Jul 2017 21:21:19 +0200 (CEST) Received: from localhost.localdomain (dslb-188-096-178-184.188.096.pools.vodafone-ip.de [188.96.178.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 3B19D25CA086 for ; Wed, 5 Jul 2017 21:21:19 +0200 (CEST) To: Int-area@ietf.org From: Hosnieh Rafiee Message-ID: Date: Wed, 5 Jul 2017 21:21:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0DACF82A35E7621B5B033D44" Archived-At: Subject: [Int-area] Review> SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 19:21:24 -0000 This is a multi-part message in MIME format. --------------0DACF82A35E7621B5B033D44 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I quickly reviewed Socks6 document as I was waiting for any initiation to improve socks 5. I found it a good document, however, unfortunately the security is still weak and this document also did not address that but made it worse. I am looking for new methods of authentication as what is available in socks5 is just plain text and cannot protect against active attacker and also passive attacker if and if there is a fixed value used as a username and password. Further, DDoS attack mentioned also in the draft cannot be addressed as easily as explained, IMHO. since the proxy server supposed to receive higher size messages and the attacker client can only overwhelm the socks server easier by less messages from different IP address that sounds to be a new client. Further, for constrained devices, there is a limitation in size of the message, therefore, dissimilar to socks5 that could be used also for such devices, socks 6 cannot be used otherwise there will be limit in the information supposed to be sent in one message= =2E https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html But in general, that is a good effort, keep going on! Best, Hosnieh --------------0DACF82A35E7621B5B033D44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,


I quickly reviewed Socks6 document as I was waiting for any initiation to improve socks 5. I found it a good document, however, unfortunately the security is still weak and this document also did not address that but made it worse. I am looking for new methods of authentication as what is available in socks5 is just plain text and cannot protect against active attacker and also passive attacker if and if there is a fixed value used as a username and password.

Further, DDoS attack mentioned also in the draft cannot be addressed as easily as explained, IMHO. since the proxy server supposed to receive higher size messages and the attacker client can only overwhelm the socks server easier by less messages from different IP address that sounds to be a new client.  Further, for constrained devices, there is a limitation in size of the message, therefore, dissimilar to socks5 that could be used also for such devices, socks 6 cannot be used otherwise there will be limit in the information supposed to be sent in one message.

https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html

But in general, that is a good effort, keep going on!

Best,

Hosnieh


--------------0DACF82A35E7621B5B033D44-- From nobody Thu Jul 6 01:41:23 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 05:56:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:44 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 Thu Jul 6 06:08:12 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B6313163C for ; Thu, 6 Jul 2017 06:08:10 -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 YjVWdUa0AEQd for ; Thu, 6 Jul 2017 06:08:09 -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 A5A06129B40 for ; Thu, 6 Jul 2017 06:08:08 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 28DA4C0709; Thu, 6 Jul 2017 15:08:07 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id F17B512007C; Thu, 6 Jul 2017 15:08:06 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 15:08:06 +0200 From: To: Hosnieh Rafiee , "Int-area@ietf.org" Thread-Topic: [Int-area] Review> SOCKS 6 Draft Thread-Index: AQHS9cPxBf6Pj01IvUa1NcnfPsDAYqJGxVHg Date: Thu, 6 Jul 2017 13:08:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A001A49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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_787AE7BB302AE849A7480A190F8B93300A001A49OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Review> SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 13:08:10 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A001A49OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSG9zbmllaCwNCg0KSnVzdCBvdXQgb2YgY3VyaW9zaXR5LCBpcyB0aGVyZSBhbnkgcGFydGlj dWxhciByZWFzb24geW91IHdhbnQgdG8gdXNlIFNPQ0tTPyBEaWQgeW91IGNvbnNpZGVyIG90aGVy IHByb3RvY29scyBzdWNoIGFzOg0KDQrCtyAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM2ODg3DQoNCsK3ICAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc2NTINCg0KVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBJbnQtYXJlYSBbbWFp bHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSG9zbmllaCBSYWZp ZWUNCkVudm95w6kgOiBtZXJjcmVkaSA1IGp1aWxsZXQgMjAxNyAyMToyMQ0Kw4AgOiBJbnQtYXJl YUBpZXRmLm9yZw0KT2JqZXQgOiBbSW50LWFyZWFdIFJldmlldz4gU09DS1MgNiBEcmFmdA0KDQoN CkhlbGxvLA0KDQpJIHF1aWNrbHkgcmV2aWV3ZWQgU29ja3M2IGRvY3VtZW50IGFzIEkgd2FzIHdh aXRpbmcgZm9yIGFueSBpbml0aWF0aW9uIHRvIGltcHJvdmUgc29ja3MgNS4gSSBmb3VuZCBpdCBh IGdvb2QgZG9jdW1lbnQsIGhvd2V2ZXIsIHVuZm9ydHVuYXRlbHkgdGhlIHNlY3VyaXR5IGlzIHN0 aWxsIHdlYWsgYW5kIHRoaXMgZG9jdW1lbnQgYWxzbyBkaWQgbm90IGFkZHJlc3MgdGhhdCBidXQg bWFkZSBpdCB3b3JzZS4gSSBhbSBsb29raW5nIGZvciBuZXcgbWV0aG9kcyBvZiBhdXRoZW50aWNh dGlvbiBhcyB3aGF0IGlzIGF2YWlsYWJsZSBpbiBzb2NrczUgaXMganVzdCBwbGFpbiB0ZXh0IGFu ZCBjYW5ub3QgcHJvdGVjdCBhZ2FpbnN0IGFjdGl2ZSBhdHRhY2tlciBhbmQgYWxzbyBwYXNzaXZl IGF0dGFja2VyIGlmIGFuZCBpZiB0aGVyZSBpcyBhIGZpeGVkIHZhbHVlIHVzZWQgYXMgYSB1c2Vy bmFtZSBhbmQgcGFzc3dvcmQuDQoNCkZ1cnRoZXIsIEREb1MgYXR0YWNrIG1lbnRpb25lZCBhbHNv IGluIHRoZSBkcmFmdCBjYW5ub3QgYmUgYWRkcmVzc2VkIGFzIGVhc2lseSBhcyBleHBsYWluZWQs IElNSE8uIHNpbmNlIHRoZSBwcm94eSBzZXJ2ZXIgc3VwcG9zZWQgdG8gcmVjZWl2ZSBoaWdoZXIg c2l6ZSBtZXNzYWdlcyBhbmQgdGhlIGF0dGFja2VyIGNsaWVudCBjYW4gb25seSBvdmVyd2hlbG0g dGhlIHNvY2tzIHNlcnZlciBlYXNpZXIgYnkgbGVzcyBtZXNzYWdlcyBmcm9tIGRpZmZlcmVudCBJ UCBhZGRyZXNzIHRoYXQgc291bmRzIHRvIGJlIGEgbmV3IGNsaWVudC4gIEZ1cnRoZXIsIGZvciBj b25zdHJhaW5lZCBkZXZpY2VzLCB0aGVyZSBpcyBhIGxpbWl0YXRpb24gaW4gc2l6ZSBvZiB0aGUg bWVzc2FnZSwgdGhlcmVmb3JlLCBkaXNzaW1pbGFyIHRvIHNvY2tzNSB0aGF0IGNvdWxkIGJlIHVz ZWQgYWxzbyBmb3Igc3VjaCBkZXZpY2VzLCBzb2NrcyA2IGNhbm5vdCBiZSB1c2VkIG90aGVyd2lz ZSB0aGVyZSB3aWxsIGJlIGxpbWl0IGluIHRoZSBpbmZvcm1hdGlvbiBzdXBwb3NlZCB0byBiZSBz ZW50IGluIG9uZSBtZXNzYWdlLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aW50YXJlYS1vbHRlYW51LXNvY2tzLTYtMDAuaHRtbA0KDQpCdXQgaW4gZ2VuZXJhbCwgdGhhdCBp cyBhIGdvb2QgZWZmb3J0LCBrZWVwIGdvaW5nIG9uIQ0KDQpCZXN0LA0KDQpIb3NuaWVoDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B93300A001A49OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyIsInNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z dHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MDgzMzM4MTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5MTI0NTM0MzggLTU0NDczMDUwMCA2 Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5 NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjU7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciLCJzZXJpZiI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkhpIEhvc25pZWgsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5KdXN0IG91dCBv Zg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Y3VyaW9zaXR5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+LCBpcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24geW91IHdh bnQgdG8gdXNlIFNPQ0tTPw0KIERpZCB5b3UgY29uc2lkZXIgb3RoZXIgcHJvdG9jb2xzIHN1Y2gg YXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODg3Ij48 c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4ODc8L3Nw YW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NTIiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjUyPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRlJm5i c3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxh IHBhcnQgZGU8L2I+IEhvc25pZWggUmFmaWVlPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1l cmNyZWRpIDUganVpbGxldCAyMDE3IDIxOjIxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBJbnQtYXJl YUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0ludC1hcmVhXSBSZXZpZXcmZ3Q7 IFNPQ0tTIDYgRHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCkkgcXVpY2tseSByZXZpZXdlZCBTb2NrczYg ZG9jdW1lbnQgYXMgSSB3YXMgd2FpdGluZyBmb3IgYW55IGluaXRpYXRpb24gdG8gaW1wcm92ZSBz b2NrcyA1LiBJIGZvdW5kIGl0IGEgZ29vZCBkb2N1bWVudCwgaG93ZXZlciwgdW5mb3J0dW5hdGVs eSB0aGUgc2VjdXJpdHkgaXMgc3RpbGwgd2VhayBhbmQgdGhpcyBkb2N1bWVudCBhbHNvIGRpZCBu b3QgYWRkcmVzcyB0aGF0IGJ1dCBtYWRlIGl0IHdvcnNlLiBJIGFtIGxvb2tpbmcgZm9yIG5ldyBt ZXRob2RzDQogb2YgYXV0aGVudGljYXRpb24gYXMgd2hhdCBpcyBhdmFpbGFibGUgaW4gc29ja3M1 IGlzIGp1c3QgcGxhaW4gdGV4dCBhbmQgY2Fubm90IHByb3RlY3QgYWdhaW5zdCBhY3RpdmUgYXR0 YWNrZXIgYW5kIGFsc28gcGFzc2l2ZSBhdHRhY2tlciBpZiBhbmQgaWYgdGhlcmUgaXMgYSBmaXhl ZCB2YWx1ZSB1c2VkIGFzIGEgdXNlcm5hbWUgYW5kIHBhc3N3b3JkLg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkZ1cnRoZXIsIEREb1Mg YXR0YWNrIG1lbnRpb25lZCBhbHNvIGluIHRoZSBkcmFmdCBjYW5ub3QgYmUgYWRkcmVzc2VkIGFz IGVhc2lseSBhcyBleHBsYWluZWQsIElNSE8uIHNpbmNlIHRoZSBwcm94eSBzZXJ2ZXIgc3VwcG9z ZWQgdG8gcmVjZWl2ZSBoaWdoZXIgc2l6ZSBtZXNzYWdlcyBhbmQgdGhlIGF0dGFja2VyIGNsaWVu dCBjYW4gb25seSBvdmVyd2hlbG0gdGhlIHNvY2tzIHNlcnZlcg0KIGVhc2llciBieSBsZXNzIG1l c3NhZ2VzIGZyb20gZGlmZmVyZW50IElQIGFkZHJlc3MgdGhhdCBzb3VuZHMgdG8gYmUgYSBuZXcg Y2xpZW50LiZuYnNwOyBGdXJ0aGVyLCBmb3IgY29uc3RyYWluZWQgZGV2aWNlcywgdGhlcmUgaXMg YSBsaW1pdGF0aW9uIGluIHNpemUgb2YgdGhlIG1lc3NhZ2UsIHRoZXJlZm9yZSwgZGlzc2ltaWxh ciB0byBzb2NrczUgdGhhdCBjb3VsZCBiZSB1c2VkIGFsc28gZm9yIHN1Y2ggZGV2aWNlcywgc29j a3MgNiBjYW5ub3QgYmUgdXNlZA0KIG90aGVyd2lzZSB0aGVyZSB3aWxsIGJlIGxpbWl0IGluIHRo ZSBpbmZvcm1hdGlvbiBzdXBwb3NlZCB0byBiZSBzZW50IGluIG9uZSBtZXNzYWdlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaW50YXJlYS1vbHRlYW51LXNvY2tz LTYtMDAuaHRtbCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWludGFyZWEtb2x0 ZWFudS1zb2Nrcy02LTAwLmh0bWw8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJ1dCBpbiBnZW5lcmFsLCB0aGF0IGlzIGEgZ29vZCBl ZmZvcnQsIGtlZXAgZ29pbmcgb24hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkhvc25pZWg8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93300A001A49OPEXCLILMA3corp_-- From nobody Thu Jul 6 11:08:54 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0F13146D for ; Thu, 6 Jul 2017 11:08:53 -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 Qpt6llu_wvNA for ; Thu, 6 Jul 2017 11:08:50 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 99E8713188A for ; Thu, 6 Jul 2017 11:08:50 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 9017B25CA26D; Thu, 6 Jul 2017 18:08:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.rozanak.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwKsJIoHhymr; Thu, 6 Jul 2017 20:08:46 +0200 (CEST) Received: from localhost.localdomain (dslb-178-003-030-230.178.003.pools.vodafone-ip.de [178.3.30.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id BB39325CA086; Thu, 6 Jul 2017 20:08:45 +0200 (CEST) To: mohamed.boucadair@orange.com, "Int-area@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A001A49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Hosnieh Rafiee Message-ID: <4f0f909f-8848-11f4-22b7-56664eee9bfd@rozanak.com> Date: Thu, 6 Jul 2017 20:08:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A001A49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------8C5D3C66A507B9899D042934" Archived-At: Subject: Re: [Int-area] Review> SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 18:08:53 -0000 This is a multi-part message in MIME format. --------------8C5D3C66A507B9899D042934 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mohamed, Thanks for your email. I had two reasons: 1- I was not aware of these two documents.. I guess two less activities at IETF. right?! 2- I just skimmed the documents you have referred to . They talk about mechanisms for IP translation and authentication and making the NAT easier. But what I do not know exactly or at least with very quick review could not find, is that socks proxy also works closely with firewall and open the ports if the client socks wants to communicate to any service outside of the network and in general cases the firewall has all its port close unless otherwise the client ask to open a port. I know that NAT has a settings to also work closely with firewall but do not know which one has a better performance. Further the default assumption in those document is that the NAT service is there. that means I do not only need to consider the implementation of NAT but also these documents. While for Socks, only socks standard is enough which works closely with Selinux for firewalling. Now the question is which process is heavier from computation perspective, NAT + this approach or a socks proxy alone that do the replacement of IP? I haven't done any experiment or comparison yet.. One more important point is that, how NAT will handle TCP connections when we have non reliable internet connection that breaks frequently but we cannot establish the TLS every single time where the connection breaks? What I liked about Socks 6 that was not in socks5 is that they handled the unreliable connection, either by purpose or accidentally, very well since they referred to a document such as TCP FAST OPEN. Further, Socks proxy is layer 5 protocol and can handle TLS communication better than NAT. I am of course not talking about the case to use socks as a MITM for my TLS connection. That is not the purpose at all here. But NAT is layer 3 or maximum with some configuration layer 4 which has no flexibility to session layer. Best, Hosnieh this is of course what I also need or expect to use from Socks as a kind of NATing but at the same time the most important thing is its interaction with firewall On 07/06/2017 03:08 PM, mohamed.boucadair@orange.com wrote: > > Hi Hosnieh, > > =20 > > Just out of curiosity, is there any particular reason you want to use > SOCKS? Did you consider other protocols such as: > > =C2=B7 https://tools.ietf.org/html/rfc6887 > > =C2=B7 https://tools.ietf.org/html/rfc7652 > > =20 > > Thank you. > > =20 > > Cheers, > > Med > > =20 > > *De :*Int-area [mailto:int-area-bounces@ietf.org] *De la part de* > Hosnieh Rafiee > *Envoy=C3=A9 :* mercredi 5 juillet 2017 21:21 > *=C3=80 :* Int-area@ietf.org > *Objet :* [Int-area] Review> SOCKS 6 Draft > > =20 > > Hello, > > > I quickly reviewed Socks6 document as I was waiting for any initiation > to improve socks 5. I found it a good document, however, unfortunately > the security is still weak and this document also did not address that > but made it worse. I am looking for new methods of authentication as > what is available in socks5 is just plain text and cannot protect > against active attacker and also passive attacker if and if there is a > fixed value used as a username and password. > > Further, DDoS attack mentioned also in the draft cannot be addressed > as easily as explained, IMHO. since the proxy server supposed to > receive higher size messages and the attacker client can only > overwhelm the socks server easier by less messages from different IP > address that sounds to be a new client. Further, for constrained > devices, there is a limitation in size of the message, therefore, > dissimilar to socks5 that could be used also for such devices, socks 6 > cannot be used otherwise there will be limit in the information > supposed to be sent in one message. > > https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html > > But in general, that is a good effort, keep going on! > > Best, > > Hosnieh > > =20 > --------------8C5D3C66A507B9899D042934 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Mohamed,

Thanks for your email. I had two reasons:

1- I was not aware of these two documents.. I guess two less activities at IETF. right?!

2- I just skimmed the documents you have referred to . They talk about mechanisms for IP translation   and authentication and making the NAT easier. But what I do not know exactly or at least with very quick review could not find,  is that socks proxy also works closely with firewall and open the ports if the client socks wants to communicate to any service outside of the network and in general cases the firewall has all its port close unless otherwise the client ask to open a port. I know that NAT has a settings to also work closely with firewall but do not know which one has a better performance. Further the default assumption in those document is that the NAT service is there. that means I do not only need to consider the implementation of NAT but also these documents. While for Socks, only socks standard is enough which works closely with Selinux for firewalling.

Now the question is which process is heavier from computation perspective, NAT + this approach or a socks proxy alone that do the replacement of IP? I haven't done any experiment or comparison yet..

One more important point is that, how NAT will handle TCP connections when we have non reliable internet connection that breaks frequently but we cannot establish the TLS every single time where the connection breaks?   What I liked about Socks 6 that was not in socks5 is that they handled the unreliable connection, either by purpose or accidentally, very well since they referred to a document such as TCP FAST OPEN.

Further, Socks proxy is  layer 5 protocol and can handle TLS communication better than NAT. I am of course not talking about the case to use socks as a MITM for my TLS connection. That is not the purpose at all here. But NAT is layer 3 or maximum with some configuration layer 4 which has no flexibility to session layer.

Best,

Hosnieh




this is of course what I also need or expect to use from Socks as a kind of NATing but at the same time the most important thing is its interaction with firewall
On 07/06/2017 03:08 PM, mohamed.boucadair@orange.com wrote:

Hi Hosnieh,

 

Just out of curiosity, is there any particular reason you want to use SOCKS? Did you consider other protocols such as:

·         https://tools.ietf.org/html/rfc6887

·         https://tools.ietf.org/html/rfc7652

 

Thank you.

 

Cheers,

Med

 

De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Hosnieh Rafiee
Envoyé : mercredi 5 juillet 2017 21:21
À : Int-area@ietf.org
Objet : [Int-area] Review> SOCKS 6 Draft

 

Hello,


I quickly reviewed Socks6 document as I was waiting for any initiation to improve socks 5. I found it a good document, however, unfortunately the security is still weak and this document also did not address that but made it worse. I am looking for new methods of authentication as what is available in socks5 is just plain text and cannot protect against active attacker and also passive attacker if and if there is a fixed value used as a username and password.

Further, DDoS attack mentioned also in the draft cannot be addressed as easily as explained, IMHO. since the proxy server supposed to receive higher size messages and the attacker client can only overwhelm the socks server easier by less messages from different IP address that sounds to be a new client.  Further, for constrained devices, there is a limitation in size of the message, therefore, dissimilar to socks5 that could be used also for such devices, socks 6 cannot be used otherwise there will be limit in the information supposed to be sent in one message.

https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html

But in general, that is a good effort, keep going on!

Best,

Hosnieh

 


--------------8C5D3C66A507B9899D042934-- From nobody Fri Jul 7 00:19:08 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:06 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 01:28:02 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828513187B for ; Fri, 7 Jul 2017 01:28:01 -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 1eV4NXKbBA4K for ; Fri, 7 Jul 2017 01:27:59 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303F41200C5 for ; Fri, 7 Jul 2017 01:27:59 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id A896B12044F; Fri, 7 Jul 2017 10:27:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id E719B60078; Fri, 7 Jul 2017 10:27:56 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0352.000; Fri, 7 Jul 2017 10:27:56 +0200 From: To: Hosnieh Rafiee , "Int-area@ietf.org" Thread-Topic: [Int-area] Review> SOCKS 6 Draft Thread-Index: AQHS9oLryspVkN1E30awCtkvLxLHs6JIBhEQ Date: Fri, 7 Jul 2017 08:27:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0020A9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A001A49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4f0f909f-8848-11f4-22b7-56664eee9bfd@rozanak.com> In-Reply-To: <4f0f909f-8848-11f4-22b7-56664eee9bfd@rozanak.com> 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_787AE7BB302AE849A7480A190F8B93300A0020A9OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Review> SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 08:28:01 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0020A9OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSG9zbmllaCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IEhvc25pZWggUmFmaWVlIFttYWlsdG86aWV0ZkByb3phbmFrLmNvbV0NCkVudm95w6kgOiBqZXVk aSA2IGp1aWxsZXQgMjAxNyAyMDowOQ0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBJ bnQtYXJlYUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW0ludC1hcmVhXSBSZXZpZXc+IFNPQ0tTIDYg RHJhZnQNCg0KDQpIaSBNb2hhbWVkLA0KDQpUaGFua3MgZm9yIHlvdXIgZW1haWwuIEkgaGFkIHR3 byByZWFzb25zOg0KDQoxLSBJIHdhcyBub3QgYXdhcmUgb2YgdGhlc2UgdHdvIGRvY3VtZW50cy4u IEkgZ3Vlc3MgdHdvIGxlc3MgYWN0aXZpdGllcyBhdCBJRVRGLiByaWdodD8hDQoNCjItIEkganVz dCBza2ltbWVkIHRoZSBkb2N1bWVudHMgeW91IGhhdmUgcmVmZXJyZWQgdG8gLiBUaGV5IHRhbGsg YWJvdXQgbWVjaGFuaXNtcyBmb3IgSVAgdHJhbnNsYXRpb24gICBhbmQgYXV0aGVudGljYXRpb24g YW5kIG1ha2luZyB0aGUgTkFUIGVhc2llci4NCg0KW01lZF0gQWN0dWFsbHksIGJvdGggTkFUIGFu ZCBmaXJld2FsbCBhcmUgYWRkcmVzc2VkIGJ5IFBDUC4gVGhlcmUgaXMgbm8gYXNzdW1wdGlvbiB0 aGF0IGEgTkFUIG11c3QgYmUgb3V0IHRoZXJlLg0KICAgVGhlIFBvcnQgQ29udHJvbCBQcm90b2Nv bCAoUENQKSBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBjb250cm9sIGhvdw0KICAgaW5jb21pbmcg cGFja2V0cyBhcmUgZm9yd2FyZGVkIGJ5IHVwc3RyZWFtIGRldmljZXMgc3VjaCBhcyBOZXR3b3Jr DQogICBBZGRyZXNzIFRyYW5zbGF0b3IgSVB2Ni9JUHY0IChOQVQ2NCksIE5ldHdvcmsgQWRkcmVz cyBUcmFuc2xhdG9yDQogICBJUHY0L0lQdjQgKE5BVDQ0KSwgYW5kIElQdjYgYW5kIElQdjQgZmly ZXdhbGwgZGV2aWNlcywgYW5kIGENCiAgIG1lY2hhbmlzbSB0byByZWR1Y2UgYXBwbGljYXRpb24g a2VlcGFsaXZlIHRyYWZmaWMuDQoNCkJ1dCB3aGF0IEkgZG8gbm90IGtub3cgZXhhY3RseSBvciBh dCBsZWFzdCB3aXRoIHZlcnkgcXVpY2sgcmV2aWV3IGNvdWxkIG5vdCBmaW5kLCAgaXMgdGhhdCBz b2NrcyBwcm94eSBhbHNvIHdvcmtzIGNsb3NlbHkgd2l0aCBmaXJld2FsbCBhbmQgb3BlbiB0aGUg cG9ydHMgaWYgdGhlIGNsaWVudCBzb2NrcyB3YW50cyB0byBjb21tdW5pY2F0ZSB0byBhbnkgc2Vy dmljZSBvdXRzaWRlIG9mIHRoZSBuZXR3b3JrIGFuZCBpbiBnZW5lcmFsIGNhc2VzIHRoZSBmaXJl d2FsbCBoYXMgYWxsIGl0cyBwb3J0IGNsb3NlIHVubGVzcyBvdGhlcndpc2UgdGhlIGNsaWVudCBh c2sgdG8gb3BlbiBhIHBvcnQuDQoNCltNZWRdIENhbiBiZSBkb25lIHVzaW5nIFBDUCwgYXMgd2Vs bC4NCg0KIEkga25vdyB0aGF0IE5BVCBoYXMgYSBzZXR0aW5ncyB0byBhbHNvIHdvcmsgY2xvc2Vs eSB3aXRoIGZpcmV3YWxsIGJ1dCBkbyBub3Qga25vdyB3aGljaCBvbmUgaGFzIGEgYmV0dGVyIHBl cmZvcm1hbmNlLiBGdXJ0aGVyIHRoZSBkZWZhdWx0IGFzc3VtcHRpb24gaW4gdGhvc2UgZG9jdW1l bnQgaXMgdGhhdCB0aGUgTkFUIHNlcnZpY2UgaXMgdGhlcmUuDQoNCltNZWRdIE5vLiBSRkM2ODg3 IGRlZmluZXMgUENQLWNvbnRyb2xsZWQgZGV2aWNlIGFzIGZvbGxvd3M6DQoNCj09PQ0KDQogICBQ Q1AtQ29udHJvbGxlZCBEZXZpY2U6DQoNCiAgICAgIEEgTkFUIG9yIGZpcmV3YWxsIHRoYXQgY29u dHJvbHMgb3IgcmV3cml0ZXMgcGFja2V0IGZsb3dzIGJldHdlZW4NCg0KICAgICAgaW50ZXJuYWwg aG9zdHMgYW5kIHJlbW90ZSBwZWVyIGhvc3RzLiAgUENQIG1hbmFnZXMgdGhlIG1hcHBpbmdzIG9u DQoNCiAgICAgIHRoaXMgZGV2aWNlLg0KDQo9PT0NCg0KdGhhdCBtZWFucyBJIGRvIG5vdCBvbmx5 IG5lZWQgdG8gY29uc2lkZXIgdGhlIGltcGxlbWVudGF0aW9uIG9mIE5BVCBidXQgYWxzbyB0aGVz ZSBkb2N1bWVudHMuIFdoaWxlIGZvciBTb2Nrcywgb25seSBzb2NrcyBzdGFuZGFyZCBpcyBlbm91 Z2ggd2hpY2ggd29ya3MgY2xvc2VseSB3aXRoIFNlbGludXggZm9yIGZpcmV3YWxsaW5nLg0KDQpO b3cgdGhlIHF1ZXN0aW9uIGlzIHdoaWNoIHByb2Nlc3MgaXMgaGVhdmllciBmcm9tIGNvbXB1dGF0 aW9uIHBlcnNwZWN0aXZlLCBOQVQgKyB0aGlzIGFwcHJvYWNoIG9yIGEgc29ja3MgcHJveHkgYWxv bmUgdGhhdCBkbyB0aGUgcmVwbGFjZW1lbnQgb2YgSVA/IEkgaGF2ZW4ndCBkb25lIGFueSBleHBl cmltZW50IG9yIGNvbXBhcmlzb24geWV0Li4NCg0KW01lZF0gUGxlYXNlIHNlZSBhYm92ZS4gVGhl IE5BVCBwYXJ0IGlzIG5vdCByZXF1aXJlZC4gQWN0dWFsbHksIFJGQzc2NTIgcHJvdmlkZXMgdGhl IGZvbGxvd2luZzoNCg0KPT0NCg0KICAgVGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudCBtZWV0cyB0aGUgc2VjdXJpdHkNCg0KICAgcmVxdWlyZW1lbnRzIHRvIGFkZHJlc3Mg dGhlIEFkdmFuY2VkIFRocmVhdCBNb2RlbCBkZXNjcmliZWQgaW4gdGhlDQoNCiAgIGJhc2UgUENQ IHNwZWNpZmljYXRpb24gW1JGQzY4ODc8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4 ODc+XS4gIFRoaXMgbWVjaGFuaXNtIGNhbiBiZSB1c2VkIHRvDQoNCiAgIHNlY3VyZSBQQ1AgaW4g dGhlIGZvbGxvd2luZyBzaXR1YXRpb25zOg0KDQoNCg0KICAgbyAgT24gc2VjdXJpdHkgaW5mcmFz dHJ1Y3R1cmUgZXF1aXBtZW50LCBzdWNoIGFzIGNvcnBvcmF0ZSBmaXJld2FsbHMsDQoNCiAgICAg IHRoYXQgZG9lcyBub3QgY3JlYXRlIGltcGxpY2l0IG1hcHBpbmdzIGZvciBzcGVjaWZpYyB0cmFm ZmljLg0KDQo9PQ0KDQpPbmUgbW9yZSBpbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCwgaG93IE5BVCB3 aWxsIGhhbmRsZSBUQ1AgY29ubmVjdGlvbnMgd2hlbiB3ZSBoYXZlIG5vbiByZWxpYWJsZSBpbnRl cm5ldCBjb25uZWN0aW9uIHRoYXQgYnJlYWtzIGZyZXF1ZW50bHkgYnV0IHdlIGNhbm5vdCBlc3Rh Ymxpc2ggdGhlIFRMUyBldmVyeSBzaW5nbGUgdGltZSB3aGVyZSB0aGUgY29ubmVjdGlvbiBicmVh a3M/ICAgV2hhdCBJIGxpa2VkIGFib3V0IFNvY2tzIDYgdGhhdCB3YXMgbm90IGluIHNvY2tzNSBp cyB0aGF0IHRoZXkgaGFuZGxlZCB0aGUgdW5yZWxpYWJsZSBjb25uZWN0aW9uLCBlaXRoZXIgYnkg cHVycG9zZSBvciBhY2NpZGVudGFsbHksIHZlcnkgd2VsbCBzaW5jZSB0aGV5IHJlZmVycmVkIHRv IGEgZG9jdW1lbnQgc3VjaCBhcyBUQ1AgRkFTVCBPUEVOLg0KDQpGdXJ0aGVyLCBTb2NrcyBwcm94 eSBpcyAgbGF5ZXIgNSBwcm90b2NvbCBhbmQgY2FuIGhhbmRsZSBUTFMgY29tbXVuaWNhdGlvbiBi ZXR0ZXIgdGhhbiBOQVQuIEkgYW0gb2YgY291cnNlIG5vdCB0YWxraW5nIGFib3V0IHRoZSBjYXNl IHRvIHVzZSBzb2NrcyBhcyBhIE1JVE0gZm9yIG15IFRMUyBjb25uZWN0aW9uLiBUaGF0IGlzIG5v dCB0aGUgcHVycG9zZSBhdCBhbGwgaGVyZS4gQnV0IE5BVCBpcyBsYXllciAzIG9yIG1heGltdW0g d2l0aCBzb21lIGNvbmZpZ3VyYXRpb24gbGF5ZXIgNCB3aGljaCBoYXMgbm8gZmxleGliaWxpdHkg dG8gc2Vzc2lvbiBsYXllci4NCg0KW01lZF0gSeKAmW0gbm90IHN1cmUgdG8gZ2V0IHlvdXIgbGFz dCB0d28gcG9pbnRzLg0KDQpCZXN0LA0KDQpIb3NuaWVoDQoNCg0KDQoNCg0KDQp0aGlzIGlzIG9m IGNvdXJzZSB3aGF0IEkgYWxzbyBuZWVkIG9yIGV4cGVjdCB0byB1c2UgZnJvbSBTb2NrcyBhcyBh IGtpbmQgb2YgTkFUaW5nIGJ1dCBhdCB0aGUgc2FtZSB0aW1lIHRoZSBtb3N0IGltcG9ydGFudCB0 aGluZyBpcyBpdHMgaW50ZXJhY3Rpb24gd2l0aCBmaXJld2FsbA0KT24gMDcvMDYvMjAxNyAwMzow OCBQTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4gd3JvdGU6DQpIaSBIb3NuaWVoLA0KDQpKdXN0IG91dCBvZiBjdXJpb3Np dHksIGlzIHRoZXJlIGFueSBwYXJ0aWN1bGFyIHJlYXNvbiB5b3Ugd2FudCB0byB1c2UgU09DS1M/ IERpZCB5b3UgY29uc2lkZXIgb3RoZXIgcHJvdG9jb2xzIHN1Y2ggYXM6DQoNCsK3ICAgICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4ODcNCg0KwrcgICAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY1Mg0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywNCk1l ZA0KDQpEZSA6IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBIb3NuaWVoIFJhZmllZQ0KRW52b3nDqSA6IG1lcmNyZWRpIDUganVpbGxldCAy MDE3IDIxOjIxDQrDgCA6IEludC1hcmVhQGlldGYub3JnPG1haWx0bzpJbnQtYXJlYUBpZXRmLm9y Zz4NCk9iamV0IDogW0ludC1hcmVhXSBSZXZpZXc+IFNPQ0tTIDYgRHJhZnQNCg0KDQpIZWxsbywN Cg0KSSBxdWlja2x5IHJldmlld2VkIFNvY2tzNiBkb2N1bWVudCBhcyBJIHdhcyB3YWl0aW5nIGZv ciBhbnkgaW5pdGlhdGlvbiB0byBpbXByb3ZlIHNvY2tzIDUuIEkgZm91bmQgaXQgYSBnb29kIGRv Y3VtZW50LCBob3dldmVyLCB1bmZvcnR1bmF0ZWx5IHRoZSBzZWN1cml0eSBpcyBzdGlsbCB3ZWFr IGFuZCB0aGlzIGRvY3VtZW50IGFsc28gZGlkIG5vdCBhZGRyZXNzIHRoYXQgYnV0IG1hZGUgaXQg d29yc2UuIEkgYW0gbG9va2luZyBmb3IgbmV3IG1ldGhvZHMgb2YgYXV0aGVudGljYXRpb24gYXMg d2hhdCBpcyBhdmFpbGFibGUgaW4gc29ja3M1IGlzIGp1c3QgcGxhaW4gdGV4dCBhbmQgY2Fubm90 IHByb3RlY3QgYWdhaW5zdCBhY3RpdmUgYXR0YWNrZXIgYW5kIGFsc28gcGFzc2l2ZSBhdHRhY2tl ciBpZiBhbmQgaWYgdGhlcmUgaXMgYSBmaXhlZCB2YWx1ZSB1c2VkIGFzIGEgdXNlcm5hbWUgYW5k IHBhc3N3b3JkLg0KDQpGdXJ0aGVyLCBERG9TIGF0dGFjayBtZW50aW9uZWQgYWxzbyBpbiB0aGUg ZHJhZnQgY2Fubm90IGJlIGFkZHJlc3NlZCBhcyBlYXNpbHkgYXMgZXhwbGFpbmVkLCBJTUhPLiBz aW5jZSB0aGUgcHJveHkgc2VydmVyIHN1cHBvc2VkIHRvIHJlY2VpdmUgaGlnaGVyIHNpemUgbWVz c2FnZXMgYW5kIHRoZSBhdHRhY2tlciBjbGllbnQgY2FuIG9ubHkgb3ZlcndoZWxtIHRoZSBzb2Nr cyBzZXJ2ZXIgZWFzaWVyIGJ5IGxlc3MgbWVzc2FnZXMgZnJvbSBkaWZmZXJlbnQgSVAgYWRkcmVz cyB0aGF0IHNvdW5kcyB0byBiZSBhIG5ldyBjbGllbnQuICBGdXJ0aGVyLCBmb3IgY29uc3RyYWlu ZWQgZGV2aWNlcywgdGhlcmUgaXMgYSBsaW1pdGF0aW9uIGluIHNpemUgb2YgdGhlIG1lc3NhZ2Us IHRoZXJlZm9yZSwgZGlzc2ltaWxhciB0byBzb2NrczUgdGhhdCBjb3VsZCBiZSB1c2VkIGFsc28g Zm9yIHN1Y2ggZGV2aWNlcywgc29ja3MgNiBjYW5ub3QgYmUgdXNlZCBvdGhlcndpc2UgdGhlcmUg d2lsbCBiZSBsaW1pdCBpbiB0aGUgaW5mb3JtYXRpb24gc3VwcG9zZWQgdG8gYmUgc2VudCBpbiBv bmUgbWVzc2FnZS4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWludGFyZWEt b2x0ZWFudS1zb2Nrcy02LTAwLmh0bWwNCg0KQnV0IGluIGdlbmVyYWwsIHRoYXQgaXMgYSBnb29k IGVmZm9ydCwga2VlcCBnb2luZyBvbiENCg0KQmVzdCwNCg0KSG9zbmllaA0KDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B93300A0020A9OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVs bGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0 ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQt d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlByZm9ybWF0SFRNTENh cg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSG9zbmllaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPlBsZWFzZSBzZWUgaW5saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+IEhvc25pZWggUmFmaWVlIFttYWlsdG86aWV0ZkByb3phbmFrLmNv bV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSA2IGp1aWxsZXQgMjAxNyAyMDow OTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSW50LWFy ZWFAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbSW50LWFyZWFdIFJldmll dyZndDsgU09DS1MgNiBEcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5IaSBNb2hhbWVkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGFua3MgZm9yIHlvdXIgZW1haWwu IEkgaGFkIHR3byByZWFzb25zOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4xLSBJIHdhcyBub3QgYXdhcmUgb2YgdGhlc2UgdHdvIGRvY3Vt ZW50cy4uIEkgZ3Vlc3MgdHdvIGxlc3MgYWN0aXZpdGllcyBhdCBJRVRGLiByaWdodD8hPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjItIEkg anVzdCBza2ltbWVkIHRoZSBkb2N1bWVudHMgeW91IGhhdmUgcmVmZXJyZWQgdG8gLiBUaGV5IHRh bGsgYWJvdXQgbWVjaGFuaXNtcyBmb3IgSVAgdHJhbnNsYXRpb24mbmJzcDsmbmJzcDsgYW5kIGF1 dGhlbnRpY2F0aW9uIGFuZCBtYWtpbmcgdGhlIE5BVCBlYXNpZXIuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEFjdHVhbGx5LCBib3Ro IE5BVCBhbmQgZmlyZXdhbGwgYXJlIGFkZHJlc3NlZCBieSBQQ1AuIFRoZXJlIGlzIG5vIGFzc3Vt cHRpb24gdGhhdCBhIE5BVCBtdXN0IGJlIG91dCB0aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+Jm5ic3A7Jm5ic3A7IFRoZSBQb3J0IENvbnRyb2wgUHJvdG9jb2wgKFBDUCkgcHJvdmlk ZXMgYSBtZWNoYW5pc20gdG8gY29udHJvbCBob3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ Jm5ic3A7Jm5ic3A7IGluY29taW5nIHBhY2tldHMgYXJlIGZvcndhcmRlZCBieSB1cHN0cmVhbSBk ZXZpY2VzIHN1Y2ggYXMgTmV0d29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsm bmJzcDsgQWRkcmVzcyBUcmFuc2xhdG9yIElQdjYvSVB2NCAoTkFUNjQpLCBOZXR3b3JrIEFkZHJl c3MgVHJhbnNsYXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsgSVB2 NC9JUHY0IChOQVQ0NCksIGFuZCBJUHY2IGFuZCBJUHY0IGZpcmV3YWxsIGRldmljZXMsIGFuZCBh PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBtZWNoYW5pc20gdG8gcmVk dWNlIGFwcGxpY2F0aW9uIGtlZXBhbGl2ZSB0cmFmZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QnV0IHdoYXQg SSBkbyBub3Qga25vdyBleGFjdGx5IG9yIGF0IGxlYXN0IHdpdGggdmVyeSBxdWljayByZXZpZXcg Y291bGQgbm90IGZpbmQsJm5ic3A7IGlzIHRoYXQgc29ja3MgcHJveHkgYWxzbyB3b3JrcyBjbG9z ZWx5IHdpdGggZmlyZXdhbGwgYW5kIG9wZW4gdGhlIHBvcnRzIGlmIHRoZSBjbGllbnQgc29ja3Mg d2FudHMgdG8gY29tbXVuaWNhdGUgdG8gYW55IHNlcnZpY2UNCiBvdXRzaWRlIG9mIHRoZSBuZXR3 b3JrIGFuZCBpbiBnZW5lcmFsIGNhc2VzIHRoZSBmaXJld2FsbCBoYXMgYWxsIGl0cyBwb3J0IGNs b3NlIHVubGVzcyBvdGhlcndpc2UgdGhlIGNsaWVudCBhc2sgdG8gb3BlbiBhIHBvcnQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5bTWVkXSBDYW4gYmUgZG9uZSB1c2luZyBQQ1AsIGFzIHdlbGwuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZuYnNwO0kga25vdyB0aGF0IE5BVCBoYXMgYSBzZXR0aW5ncyB0byBhbHNvIHdvcmsgY2xvc2Vs eSB3aXRoIGZpcmV3YWxsIGJ1dCBkbyBub3Qga25vdyB3aGljaCBvbmUgaGFzIGEgYmV0dGVyIHBl cmZvcm1hbmNlLiBGdXJ0aGVyIHRoZSBkZWZhdWx0IGFzc3VtcHRpb24gaW4gdGhvc2UgZG9jdW1l bnQgaXMgdGhhdCB0aGUgTkFUIHNlcnZpY2UgaXMgdGhlcmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBOby4g UkZDNjg4NyBkZWZpbmVzIFBDUC1jb250cm9sbGVkIGRldmljZSBhcyBmb2xsb3dzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7IFBDUC1Db250cm9sbGVkIERldmljZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIE5BVCBv ciBmaXJld2FsbCB0aGF0IGNvbnRyb2xzIG9yIHJld3JpdGVzIHBhY2tldCBmbG93cyBiZXR3ZWVu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJuYWwgaG9zdHMgYW5kIHJlbW90ZSBwZWVyIGhv c3RzLiZuYnNwOyBQQ1AgbWFuYWdlcyB0aGUgbWFwcGluZ3Mgb248bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0aGlzIGRldmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij50aGF0IG1lYW5zIEkgZG8g bm90IG9ubHkgbmVlZCB0byBjb25zaWRlciB0aGUgaW1wbGVtZW50YXRpb24gb2YgTkFUIGJ1dCBh bHNvIHRoZXNlIGRvY3VtZW50cy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+V2hpbGUgZm9yIFNvY2tzLCBvbmx5IHNvY2tzIHN0YW5kYXJkIGlzIGVub3VnaCB3aGljaCB3 b3JrcyBjbG9zZWx5IHdpdGggU2VsaW51eCBmb3IgZmlyZXdhbGxpbmcuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk5vdyB0aGUgcXVlc3Rp b24gaXMgd2hpY2ggcHJvY2VzcyBpcyBoZWF2aWVyIGZyb20gY29tcHV0YXRpb24gcGVyc3BlY3Rp dmUsIE5BVCAmIzQzOyB0aGlzIGFwcHJvYWNoIG9yIGEgc29ja3MgcHJveHkgYWxvbmUgdGhhdCBk byB0aGUgcmVwbGFjZW1lbnQgb2YgSVA/IEkgaGF2ZW4ndCBkb25lIGFueSBleHBlcmltZW50IG9y IGNvbXBhcmlzb24geWV0Li48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFBsZWFzZSBzZWUgYWJvdmUuIFRoZSBOQVQgcGFy dCBpcyBub3QgcmVxdWlyZWQuIEFjdHVhbGx5LCBSRkM3NjUyIHByb3ZpZGVzIHRoZSBmb2xsb3dp bmc6ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsgVGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1 bWVudCBtZWV0cyB0aGUgc2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyByZXF1aXJlbWVudHMgdG8gYWRkcmVzcyB0aGUg QWR2YW5jZWQgVGhyZWF0IE1vZGVsIGRlc2NyaWJlZCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBiYXNlIFBDUCBzcGVj aWZpY2F0aW9uIFs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY4ODciIHRpdGxlPSImcXVvdDtQb3J0IENvbnRyb2wgUHJvdG9jb2wgKFBDUCkmcXVvdDsiPjxz cGFuIGxhbmc9IkVOLVVTIj5SRkM2ODg3PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XS4g Jm5ic3A7VGhpcyBtZWNoYW5pc20gY2FuIGJlIHVzZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBzZWN1cmUgUENQIGluIHRo ZSBmb2xsb3dpbmcgc2l0dWF0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgT24gc2VjdXJpdHkgaW5mcmFzdHJ1 Y3R1cmUgZXF1aXBtZW50LCBzdWNoIGFzIGNvcnBvcmF0ZSBmaXJld2FsbHMsPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhhdCBkb2VzIG5vdCBjcmVhdGUgaW1wbGljaXQgbWFwcGluZ3MgZm9yIHNw ZWNpZmljIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPj09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5PbmUgbW9yZSBpbXBvcnRhbnQg cG9pbnQgaXMgdGhhdCwgaG93IE5BVCB3aWxsIGhhbmRsZSBUQ1AgY29ubmVjdGlvbnMgd2hlbiB3 ZSBoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5hdmUgbm9uIHJlbGlhYmxl IGludGVybmV0IGNvbm5lY3Rpb24gdGhhdCBicmVha3MgZnJlcXVlbnRseSBidXQgd2UgY2Fubm90 IGVzdGFibGlzaCB0aGUgVExTIGV2ZXJ5DQogc2luZ2xlIHRpbWUgd2hlcmUgdGhlIGNvbm5lY3Rp b24gYnJlYWtzPyZuYnNwOyZuYnNwOyBXaGF0IEkgbGlrZWQgYWJvdXQgU29ja3MgNiB0aGF0IHdh cyBub3QgaW4gc29ja3M1IGlzIHRoYXQgdGhleSBoYW5kbGVkIHRoZSB1bnJlbGlhYmxlIGNvbm5l Y3Rpb24sIGVpdGhlciBieSBwdXJwb3NlIG9yIGFjY2lkZW50YWxseSwgdmVyeSB3ZWxsIHNpbmNl IHRoZXkgcmVmZXJyZWQgdG8gYSBkb2N1bWVudCBzdWNoIGFzIFRDUCBGQVNUIE9QRU4uDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPkZ1cnRoZXIsIFNvY2tzIHByb3h5IGlzJm5ic3A7IGxheWVyIDUgcHJvdG9jb2wg YW5kIGNhbiBoYW5kbGUgVExTIGNvbW11bmljYXRpb24gYmV0dGVyIHRoYW4gTkFULg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JIGFtIG9mIGNvdXJzZSBub3QgdGFsa2lu ZyBhYm91dCB0aGUgY2FzZSB0byB1c2Ugc29ja3MgYXMgYSBNSVRNIGZvciBteSBUTFMgY29ubmVj dGlvbi4gVGhhdCBpcyBub3QgdGhlIHB1cnBvc2UgYXQgYWxsIGhlcmUuIEJ1dCBOQVQgaXMgbGF5 ZXIgMyBvciBtYXhpbXVtIHdpdGggc29tZSBjb25maWd1cmF0aW9uIGxheWVyIDQgd2hpY2ggaGFz IG5vIGZsZXhpYmlsaXR5IHRvIHNlc3Npb24NCiBsYXllci4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJ4oCZbSBub3Qg c3VyZSB0byBnZXQgeW91ciBsYXN0IHR3byBwb2ludHMuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5CZXN0LDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Ib3NuaWVoPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnRoaXMgaXMgb2YgY291cnNlIHdo YXQgSSBhbHNvIG5lZWQgb3IgZXhwZWN0IHRvIHVzZSBmcm9tIFNvY2tzIGFzIGEga2luZCBvZiBO QVRpbmcgYnV0IGF0IHRoZSBzYW1lIHRpbWUgdGhlIG1vc3QgaW1wb3J0YW50IHRoaW5nIGlzIGl0 cyBpbnRlcmFjdGlvbiB3aXRoIGZpcmV3YWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA3LzA2LzIwMTcgMDM6MDggUE0sIDxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhpIEhvc25pZWgsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5KdXN0IG91dCBvZg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj5jdXJpb3NpdHk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiwgaXMgdGhlcmUgYW55IHBh cnRpY3VsYXIgcmVhc29uIHlvdSB3YW50IHRvIHVzZSBTT0NLUz8gRGlkIHlvdSBjb25zaWRlciBv dGhlciBwcm90b2NvbHMgc3VjaCBhczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiPsK3Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjg4NyI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODg3PC9zcGFuPjwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPsK3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NjUyIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjUyPC9hPiA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWVkPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5EZSZuYnNw Ozo8L2I+IEludC1hcmVhIFs8YSBocmVmPSJtYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBk ZTwvYj4gSG9zbmllaCBSYWZpZWU8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkg NSBqdWlsbGV0IDIwMTcgMjE6MjE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0 bzpJbnQtYXJlYUBpZXRmLm9yZyI+SW50LWFyZWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQm bmJzcDs6PC9iPiBbSW50LWFyZWFdIFJldmlldyZndDsgU09DS1MgNiBEcmFmdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwPjxicj4NCkkgcXVpY2tseSBy ZXZpZXdlZCBTb2NrczYgZG9jdW1lbnQgYXMgSSB3YXMgd2FpdGluZyBmb3IgYW55IGluaXRpYXRp b24gdG8gaW1wcm92ZSBzb2NrcyA1LiBJIGZvdW5kIGl0IGEgZ29vZCBkb2N1bWVudCwgaG93ZXZl ciwgdW5mb3J0dW5hdGVseSB0aGUgc2VjdXJpdHkgaXMgc3RpbGwgd2VhayBhbmQgdGhpcyBkb2N1 bWVudCBhbHNvIGRpZCBub3QgYWRkcmVzcyB0aGF0IGJ1dCBtYWRlIGl0IHdvcnNlLiBJIGFtIGxv b2tpbmcgZm9yIG5ldyBtZXRob2RzDQogb2YgYXV0aGVudGljYXRpb24gYXMgd2hhdCBpcyBhdmFp bGFibGUgaW4gc29ja3M1IGlzIGp1c3QgcGxhaW4gdGV4dCBhbmQgY2Fubm90IHByb3RlY3QgYWdh aW5zdCBhY3RpdmUgYXR0YWNrZXIgYW5kIGFsc28gcGFzc2l2ZSBhdHRhY2tlciBpZiBhbmQgaWYg dGhlcmUgaXMgYSBmaXhlZCB2YWx1ZSB1c2VkIGFzIGEgdXNlcm5hbWUgYW5kIHBhc3N3b3JkLg0K PG86cD48L286cD48L3A+DQo8cD5GdXJ0aGVyLCBERG9TIGF0dGFjayBtZW50aW9uZWQgYWxzbyBp biB0aGUgZHJhZnQgY2Fubm90IGJlIGFkZHJlc3NlZCBhcyBlYXNpbHkgYXMgZXhwbGFpbmVkLCBJ TUhPLiBzaW5jZSB0aGUgcHJveHkgc2VydmVyIHN1cHBvc2VkIHRvIHJlY2VpdmUgaGlnaGVyIHNp emUgbWVzc2FnZXMgYW5kIHRoZSBhdHRhY2tlciBjbGllbnQgY2FuIG9ubHkgb3ZlcndoZWxtIHRo ZSBzb2NrcyBzZXJ2ZXIgZWFzaWVyIGJ5IGxlc3MgbWVzc2FnZXMgZnJvbSBkaWZmZXJlbnQNCiBJ UCBhZGRyZXNzIHRoYXQgc291bmRzIHRvIGJlIGEgbmV3IGNsaWVudC4mbmJzcDsgRnVydGhlciwg Zm9yIGNvbnN0cmFpbmVkIGRldmljZXMsIHRoZXJlIGlzIGEgbGltaXRhdGlvbiBpbiBzaXplIG9m IHRoZSBtZXNzYWdlLCB0aGVyZWZvcmUsIGRpc3NpbWlsYXIgdG8gc29ja3M1IHRoYXQgY291bGQg YmUgdXNlZCBhbHNvIGZvciBzdWNoIGRldmljZXMsIHNvY2tzIDYgY2Fubm90IGJlIHVzZWQgb3Ro ZXJ3aXNlIHRoZXJlIHdpbGwgYmUgbGltaXQgaW4gdGhlDQogaW5mb3JtYXRpb24gc3VwcG9zZWQg dG8gYmUgc2VudCBpbiBvbmUgbWVzc2FnZS48bzpwPjwvbzpwPjwvcD4NCjxwPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pbnRhcmVhLW9sdGVhbnUtc29ja3MtNi0w MC5odG1sIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaW50YXJlYS1vbHRlYW51 LXNvY2tzLTYtMDAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPkJ1dCBpbiBnZW5lcmFsLCB0 aGF0IGlzIGEgZ29vZCBlZmZvcnQsIGtlZXAgZ29pbmcgb24hPG86cD48L286cD48L3A+DQo8cD5C ZXN0LDxvOnA+PC9vOnA+PC9wPg0KPHA+SG9zbmllaDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300A0020A9OPEXCLILMA3corp_-- From nobody Fri Jul 7 04:24:04 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 Mon Jul 10 12:14:44 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC111315FF; Mon, 10 Jul 2017 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cvhQPwy2VNGN; Mon, 10 Jul 2017 12:14:41 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53342131861; Mon, 10 Jul 2017 12:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15020; q=dns/txt; s=iport; t=1499714081; x=1500923681; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OL+Q3wMc49skOczSg0hlkaMhIW9pCaVr8rEFV6iNVj8=; b=kndAqqNSp7LMr9TVN1GLRgqjYdsthyASWI6QwhcWphxSe6E9N6zviq1a /ybWqNFcQTB7Hcy3OzDTqq19u7VR0G9ATNR0sjeK0Eg9JMOtyfvkq7R1j WL30/FIm+b2W24c8SYfQnWioN2gFiRD5dxBz3cULYk1PhK0ZPT2PP3UZN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAAC90WNZ/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHg2mKGaJDhSyCESEBCoVwAhqDDT8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRkCAQMBASFLCxACAQg/AwICAiULFBECBA4FiUtkEKpPfoImiz0BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgyiDTIFhK4J5hSiCVTCCMQWXNYdpAodGjEKCDFeEdIp?= =?us-ascii?q?LlT8BHziBCnUVHyoSAYcDdodZgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,342,1496102400"; d="scan'208,217";a="452605646" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2017 19:14:40 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6AJEeAa017792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Jul 2017 19:14:40 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Jul 2017 15:14:39 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 10 Jul 2017 15:14:39 -0400 From: "Carlos Pignataro (cpignata)" To: "draft-ietf-intarea-probe@ietf.org" CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Thread-Index: AQHS7Fq+wBy1N2KBokeZQghbwQWdeaJNy+QA Date: Mon, 10 Jul 2017 19:14:39 +0000 Message-ID: <22A03980-31C0-4B74-B2F6-01813E0841D1@cisco.com> References: <149824773063.17383.492358539882882073@ietfa.amsl.com> In-Reply-To: <149824773063.17383.492358539882882073@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.132] Content-Type: multipart/alternative; boundary="_000_22A0398031C04B74B2F601813E0841D1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 19:14:43 -0000 --_000_22A0398031C04B74B2F601813E0841D1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFJvbiwgQXV0aG9ycywNCg0KQXMgSSB3YXMgcmVhZGluZyBvdmVyIGRyYWZ0LWlldGYtaW50 YXJlYS1wcm9iZS0wMCwgYW5kIHdhbnRlZCB0byBzaGFyZSBhIGNvdXBsZSBvZiBvYnNlcnZhdGlv bnMgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4NCg0KDQogICogICBIYXZlIHlvdSBjb25zaWRlcmVk IHRoZSB0cmFkZW9mZiBvZiBkZWZpbmluZyBuZXcgSUNNUCBUeXBlcyB2ZXJzdXMgZXh0ZW5kaW5n IGV4aXN0aW5nIElDTVAgVHlwZXM/IElmIHVzaW5nIGV4aXN0aW5nIElDTVB2NiBFY2hvIFJlcXVl c3QvUmVwbHkgYW5kIGV4dGVuZGluZyB0aGVtIGluc3RlYWQgb2YgZGVmaW5pbmcgYnJhbmQgbmV3 IHR5cGVzLCB0aGUgYmFja3dhcmRzIGludGVyb3BlcmFiaWxpdHkgYWNoaWV2ZWQgaXMgaGlnaGVy DQogICogICBIYXZlIHlvdSBjb25zaWRlcmVkIHVzaW5nIG90aGVyIHByb3RvY29scyBhcyB3ZWxs IGluIGFkZGl0aW9uIHRvIElDTVAgZm9yIHRoZSBQUk9CRSBtZXNzYWdlLCB3aGljaCBjYW4gZWxp Y2l0IElDTVAgZXJyb3JzIG9yIHJlc3BvbnNlcyB3aXRoIGFwcHJvcHJpYXRlIGV4dGVuc2lvbnM/ IEluIHBhcnRpY3VsYXIgVURQIGlzIGEgcHJvdG9jb2wgbXVjaCB1c2VkIGFuZCBkZXNpcmVkIGZv ciBwcm9iZXMuDQoNClRoZXNlIHR3byBwb2ludHMgYWN0dWFsbHkgcmVtaW5kZWQgbWUgb2YgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoZW4tdHJhY2Vyb3V0ZS1waW5nLWV4dC0w NCAoYW5kIHRoZSBJQ01QLW9ubHkgcHJlZGVjZXNzb3IgZHJhZnQtc2hlbi11ZHAtdHJhY2Vyb3V0 ZS1leHQtMDEpIHRoYXQgZGVmaW5lcyBhIHByb2JlIGV4dGVuc2lvbiBhcHBsaWVkIHRvIElDTVAg RWNobyBSZXF1ZXN0IGFuZCBVRFAsIGFuZCBSRkMgNDg4NCBleHRlbnNpb25zIHRvIHJlc3BvbnNl cy4gVGhhdCBhcHByb2FjaCBzZWVtcyBzb21ld2hhdCBtb3JlIGdlbmVyaWMuDQoNCkFkZGl0aW9u YWxseSwgSSB3YXMgYWxzbyByZW1pbmRlZCBvZiB0aGUgSUNNUCBBVVAgYXQgUkZDIDcyNzksIGl0 IHdvdWxkIGJlIHVzZWZ1bCB0byBtYXAgYWdhaW5zdCB0aGF0IGRvYyB0byBzaG93IGhvdyB0aGlz IGlzIChhcyBpdCBpcyB0aGUgY2FzZSkgYSByZWFsbHkgZ29vZCB1c2Ugb2YgSUNNUC4NCg0KVGhh bmtzIQ0KDQrigJQgQ2FybG9zLg0KDQoNCk9uIEp1biAyMywgMjAxNywgYXQgMzo1NSBQTSwgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdy b3RlOg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIEludGVybmV0IEFyZWEgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAg ICAgIFRpdGxlICAgICAgICAgICA6IFBST0JFOiBBIFV0aWxpdHkgRm9yIFByb2JpbmcgSW50ZXJm YWNlcw0KICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJvbiBCb25pY2ENCiAgICAgICAgICAgICAg ICAgICAgICAgICBSZWppIFRob21hcw0KICAgICAgICAgICAgICAgICAgICAgICAgIEplbiBMaW5r b3ZhDQogICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXMgTGVuYXJ0DQogICAgICAgICAgICAg ICAgICAgICAgICAgTW9oYW1lZCBCb3VjYWRhaXINCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtaW50YXJlYS1wcm9iZS0wMC50eHQNClBhZ2VzICAgICAgICAgICA6IDE3DQpEYXRlICAgICAg ICAgICAgOiAyMDE3LTA2LTIzDQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBhIG5ldHdvcmsgZGlhZ25vc3RpYyB0b29sIGNhbGxlZCBQUk9CRS4NCiAgUFJPQkUgaXMgc2lt aWxhciB0byBQSU5HLCBpbiB0aGF0IGl0IGNhbiBiZSB1c2VkIHRvIHRlc3QgdGhlIHN0YXR1cw0K ICBvZiBhIHByb2JlZCBpbnRlcmZhY2UuICBJdCBkaWZmZXJzIGZyb20gUElORyBpbiB0aGF0IGl0 IGRvZXMgbm90DQogIHJlcXVpcmUgYmlkaXJlY3Rpb25hbCBjb25uZWN0aXZpdHkgYmV0d2VlbiB0 aGUgcHJvYmluZyBhbmQgcHJvYmVkDQogIGludGVyZmFjZXMuICBBbHRlcm5hdGl2ZWx5LCBQUk9C RSByZXF1aXJlcyBiaWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eQ0KICBiZXR3ZWVuIHRoZSBwcm9i aW5nIGludGVyZmFjZSBhbmQgYSBwcm94eSBpbnRlcmZhY2UuICBUaGUgcHJveHkNCiAgaW50ZXJm YWNlIGNhbiByZXNpZGUgb24gdGhlIHNhbWUgbm9kZSBhcyB0aGUgcHJvYmVkIGludGVyZmFjZSBv ciBpdA0KICBjYW4gcmVzaWRlIG9uIGEgbm9kZSB0byB3aGljaCB0aGUgcHJvYmVkIGludGVyZmFj ZSBpcyBkaXJlY3RseQ0KICBjb25uZWN0ZWQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWludGFyZWEtcHJvYmUvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWludGFyZWEtcHJvYmUtMDANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAwDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkludC1hcmVh IG1haWxpbmcgbGlzdA0KSW50LWFyZWFAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaW50LWFyZWENCg0K4oCUDQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NA Y2lzY28uY29tPG1haWx0bzpjYXJsb3NAY2lzY28uY29tPg0KDQrigJxTb21ldGltZXMgSSB1c2Ug YmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYg c291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4iDQoNCg== --_000_22A0398031C04B74B2F601813E0841D1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksIFJvbiwgQXV0aG9ycywNCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFzIEkgd2Fz IHJlYWRpbmcgb3ZlciZuYnNwO2RyYWZ0LWlldGYtaW50YXJlYS1wcm9iZS0wMCwgYW5kIHdhbnRl ZCB0byBzaGFyZSBhIGNvdXBsZSBvZiBvYnNlcnZhdGlvbnMgZm9yIHlvdXIgY29uc2lkZXJhdGlv bi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPHVsIGNsYXNzPSJNYWlsT3V0bGluZSI+DQo8bGkgY2xhc3M9IiI+SGF2ZSB5b3UgY29u c2lkZXJlZCB0aGUgdHJhZGVvZmYgb2YgZGVmaW5pbmcgbmV3IElDTVAgVHlwZXMgdmVyc3VzIGV4 dGVuZGluZyBleGlzdGluZyBJQ01QIFR5cGVzPyBJZiB1c2luZyBleGlzdGluZyBJQ01QdjYgRWNo byBSZXF1ZXN0L1JlcGx5IGFuZCBleHRlbmRpbmcgdGhlbSBpbnN0ZWFkIG9mIGRlZmluaW5nIGJy YW5kIG5ldyB0eXBlcywgdGhlIGJhY2t3YXJkcyBpbnRlcm9wZXJhYmlsaXR5IGFjaGlldmVkIGlz IGhpZ2hlcjwvbGk+PGxpIGNsYXNzPSIiPkhhdmUgeW91IGNvbnNpZGVyZWQgdXNpbmcgb3RoZXIg cHJvdG9jb2xzIGFzIHdlbGwgaW4gYWRkaXRpb24gdG8gSUNNUCBmb3IgdGhlIFBST0JFIG1lc3Nh Z2UsIHdoaWNoIGNhbiBlbGljaXQgSUNNUCBlcnJvcnMgb3IgcmVzcG9uc2VzIHdpdGggYXBwcm9w cmlhdGUgZXh0ZW5zaW9ucz8gSW4gcGFydGljdWxhciBVRFAgaXMgYSBwcm90b2NvbCBtdWNoIHVz ZWQgYW5kIGRlc2lyZWQgZm9yIHByb2Jlcy48L2xpPjwvdWw+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVzZSB0d28gcG9pbnRzIGFjdHVhbGx5 IHJlbWluZGVkIG1lIG9mJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNoZW4tdHJhY2Vyb3V0ZS1waW5nLWV4dC0wNCIgY2xhc3M9IiI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoZW4tdHJhY2Vyb3V0ZS1waW5nLWV4dC0wNDwvYT4mbmJz cDsoYW5kIHRoZSBJQ01QLW9ubHkgcHJlZGVjZXNzb3ImbmJzcDtkcmFmdC1zaGVuLXVkcC10cmFj ZXJvdXRlLWV4dC0wMSkmbmJzcDt0aGF0DQogZGVmaW5lcyBhIHByb2JlIGV4dGVuc2lvbiBhcHBs aWVkIHRvIElDTVAgRWNobyBSZXF1ZXN0IGFuZCBVRFAsIGFuZCBSRkMgNDg4NCBleHRlbnNpb25z IHRvIHJlc3BvbnNlcy4gVGhhdCBhcHByb2FjaCBzZWVtcyBzb21ld2hhdCBtb3JlIGdlbmVyaWMu PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkFkZGl0aW9uYWxseSwgSSB3YXMgYWxzbyByZW1pbmRlZCBvZiB0aGUgSUNNUCBB VVAgYXQgUkZDJm5ic3A7NzI3OSwgaXQgd291bGQgYmUgdXNlZnVsIHRvIG1hcCBhZ2FpbnN0IHRo YXQgZG9jIHRvIHNob3cgaG93IHRoaXMgaXMgKGFzIGl0IGlzIHRoZSBjYXNlKSBhIHJlYWxseSBn b29kIHVzZSBvZiBJQ01QLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxk aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24g SnVuIDIzLCAyMDE3LCBhdCAzOjU1IFBNLCA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIiBjbGFzcz0iIj4NCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz LjxiciBjbGFzcz0iIj4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVybmV0 IEFyZWEgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaXRsZSAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6 IFBST0JFOiBBIFV0aWxpdHkgRm9yIFByb2JpbmcgSW50ZXJmYWNlczxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvcnMgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBSb24gQm9uaWNhPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UmVqaSBUaG9tYXM8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtKZW4gTGlu a292YTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0No cmlzIExlbmFydDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO01vaGFtZWQgQm91Y2FkYWlyPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RmlsZW5hbWUgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBkcmFmdC1pZXRmLWludGFyZWEtcHJv YmUtMDAudHh0PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHls ZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+UGFnZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAxNzxiciBjbGFzcz0iIj4NCjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu PkRhdGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiAyMDE3LTA2LTIzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K QWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSBuZXR3b3JrIGRpYWdub3N0aWMgdG9vbCBjYWxsZWQgUFJPQkUuPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7UFJPQkUgaXMgc2ltaWxhciB0byBQSU5HLCBpbiB0aGF0IGl0IGNhbiBiZSB1 c2VkIHRvIHRlc3QgdGhlIHN0YXR1czxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO29mIGEgcHJv YmVkIGludGVyZmFjZS4gJm5ic3A7SXQgZGlmZmVycyBmcm9tIFBJTkcgaW4gdGhhdCBpdCBkb2Vz IG5vdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3JlcXVpcmUgYmlkaXJlY3Rpb25hbCBjb25u ZWN0aXZpdHkgYmV0d2VlbiB0aGUgcHJvYmluZyBhbmQgcHJvYmVkPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7aW50ZXJmYWNlcy4gJm5ic3A7QWx0ZXJuYXRpdmVseSwgUFJPQkUgcmVxdWlyZXMg YmlkaXJlY3Rpb25hbCBjb25uZWN0aXZpdHk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtiZXR3 ZWVuIHRoZSBwcm9iaW5nIGludGVyZmFjZSBhbmQgYSBwcm94eSBpbnRlcmZhY2UuICZuYnNwO1Ro ZSBwcm94eTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2ludGVyZmFjZSBjYW4gcmVzaWRlIG9u IHRoZSBzYW1lIG5vZGUgYXMgdGhlIHByb2JlZCBpbnRlcmZhY2Ugb3IgaXQ8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDtjYW4gcmVzaWRlIG9uIGEgbm9kZSB0byB3aGljaCB0aGUgcHJvYmVkIGlu dGVyZmFjZSBpcyBkaXJlY3RseTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2Nvbm5lY3RlZC48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWludGFyZWEt cHJvYmUvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWludGFyZWEtcHJvYmUvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZXJl IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXBy b2JlLTAwIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p bnRhcmVhLXByb2JlLTAwPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAwPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFz cz0iIj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxiciBjbGFzcz0i Ij4NCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnIgY2xhc3M9IiI+DQpJbnQtYXJlYSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpJbnQt YXJlYUBpZXRmLm9yZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaW50LWFyZWE8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K4oCUPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCkNhcmxvcyBQaWduYXRhcm8sJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNhcmxv c0BjaXNjby5jb20iIGNsYXNzPSIiPmNhcmxvc0BjaXNjby5jb208L2E+PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGkgY2xhc3M9IiI+4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0 aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUm bmJzcDtwaG90b3N5bnRoZXNpcy4mcXVvdDs8L2k+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_22A0398031C04B74B2F601813E0841D1ciscocom_-- From nobody Tue Jul 11 11:35:45 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0D131795 for ; Tue, 11 Jul 2017 11:35:43 -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 m8FOqjS-P0jD for ; Tue, 11 Jul 2017 11:35:41 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 E4E5513178C for ; Tue, 11 Jul 2017 11:35:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id D991C25CA271; Tue, 11 Jul 2017 18:35:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.rozanak.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZARKCgkc37sY; Tue, 11 Jul 2017 20:35:37 +0200 (CEST) Received: from localhost.localdomain (unknown [85.195.104.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id CB56825CA257; Tue, 11 Jul 2017 20:35:36 +0200 (CEST) To: mohamed.boucadair@orange.com, "Int-area@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A001A49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4f0f909f-8848-11f4-22b7-56664eee9bfd@rozanak.com> <787AE7BB302AE849A7480A190F8B93300A0020A9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Hosnieh Rafiee Message-ID: <1cd4f46b-6fe5-1205-5688-42a07ce5c807@rozanak.com> Date: Tue, 11 Jul 2017 20:35:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0020A9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------7D4F95C22B09D9685D63089C" Archived-At: Subject: Re: [Int-area] Review> SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 18:35:43 -0000 This is a multi-part message in MIME format. --------------7D4F95C22B09D9685D63089C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mohamed, Thanks for your response. That is interesting! just the last question is that, whether or not similar to TCP FAST OPEN, can we also have it together with this solution so that we can handle any unreliable internet connection by avoiding the break in TCP layer. Thanks, Best, Hosnieh =3D=3D > > One more important point is that, how NAT will handle TCP connections > when we have non reliable internet connection that breaks frequently > but we cannot establish the TLS every single time where the connection > breaks? What I liked about Socks 6 that was not in socks5 is that > they handled the unreliable connection, either by purpose or > accidentally, very well since they referred to a document such as TCP > FAST OPEN. > > Further, Socks proxy is layer 5 protocol and can handle TLS > communication better than NAT. I am of course not talking about the > case to use socks as a MITM for my TLS connection. That is not the > purpose at all here. But NAT is layer 3 or maximum with some > configuration layer 4 which has no flexibility to session layer. > > [Med] I=E2=80=99m not sure to get your last two points. =20 > > Best, > > Hosnieh > > =20 > > =20 > > =20 > > this is of course what I also need or expect to use from Socks as a > kind of NATing but at the same time the most important thing is its > interaction with firewall > > On 07/06/2017 03:08 PM, mohamed.boucadair@orange.com > wrote: > > Hi Hosnieh, > > =20 > > Just out of curiosity, is there any particular reason you want to > use SOCKS? Did you consider other protocols such as: > > =C2=B7 https://tools.ietf.org/html/rfc6887 > > =C2=B7 https://tools.ietf.org/html/rfc7652 > > > =20 > > Thank you. > > =20 > > Cheers, > > Med > > =20 > > *De :* Int-area [mailto:int-area-bounces@ietf.org] *De la part de* > Hosnieh Rafiee > *Envoy=C3=A9 :* mercredi 5 juillet 2017 21:21 > *=C3=80 :* Int-area@ietf.org > *Objet :* [Int-area] Review> SOCKS 6 Draft > > =20 > > Hello, > > > I quickly reviewed Socks6 document as I was waiting for any > initiation to improve socks 5. I found it a good document, > however, unfortunately the security is still weak and this > document also did not address that but made it worse. I am looking > for new methods of authentication as what is available in socks5 > is just plain text and cannot protect against active attacker and > also passive attacker if and if there is a fixed value used as a > username and password. > > Further, DDoS attack mentioned also in the draft cannot be > addressed as easily as explained, IMHO. since the proxy server > supposed to receive higher size messages and the attacker client > can only overwhelm the socks server easier by less messages from > different IP address that sounds to be a new client. Further, for > constrained devices, there is a limitation in size of the message, > therefore, dissimilar to socks5 that could be used also for such > devices, socks 6 cannot be used otherwise there will be limit in > the information supposed to be sent in one message. > > https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html > > But in general, that is a good effort, keep going on! > > Best, > > Hosnieh > > =20 > > =20 > --------------7D4F95C22B09D9685D63089C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Mohamed,

Thanks for your response. That is interesting!

just the last question is that, whether or not similar to TCP FAST OPEN, can we also have it together with this solution so that we can handle any unreliable internet connection by avoiding the break in TCP layer.


Thanks,

Best,

Hosnieh

==

One more important point is that, how NAT will handle TCP connections when we have non reliable internet connection that breaks frequently but we cannot establish the TLS every single time where the connection breaks?   What I liked about Socks 6 that was not in socks5 is that they handled the unreliable connection, either by purpose or accidentally, very well since they referred to a document such as TCP FAST OPEN.

Further, Socks proxy is  layer 5 protocol and can handle TLS communication better than NAT. I am of course not talking about the case to use socks as a MITM for my TLS connection. That is not the purpose at all here. But NAT is layer 3 or maximum with some configuration layer 4 which has no flexibility to session layer.

[Med] I’m not sure to get your last two points.  

Best,

Hosnieh

 

 

 

this is of course what I also need or expect to use from Socks as a kind of NATing but at the same time the most important thing is its interaction with firewall

On 07/06/2017 03:08 PM, mohamed.boucadair@orange.com wrote:

Hi Hosnieh,

 

Just out of curiosity, is there any particular reason you want to use SOCKS? Did you consider other protocols such as:

·         https://tools.ietf.org/html/rfc6887

·         https://tools.ietf.org/html/rfc7652

 

Thank you.

 

Cheers,

Med

 

De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Hosnieh Rafiee
Envoyé : mercredi 5 juillet 2017 21:21
À : Int-area@ietf.org
Objet : [Int-area] Review> SOCKS 6 Draft

 

Hello,


I quickly reviewed Socks6 document as I was waiting for any initiation to improve socks 5. I found it a good document, however, unfortunately the security is still weak and this document also did not address that but made it worse. I am looking for new methods of authentication as what is available in socks5 is just plain text and cannot protect against active attacker and also passive attacker if and if there is a fixed value used as a username and password.

Further, DDoS attack mentioned also in the draft cannot be addressed as easily as explained, IMHO. since the proxy server supposed to receive higher size messages and the attacker client can only overwhelm the socks server easier by less messages from different IP address that sounds to be a new client.  Further, for constrained devices, there is a limitation in size of the message, therefore, dissimilar to socks5 that could be used also for such devices, socks 6 cannot be used otherwise there will be limit in the information supposed to be sent in one message.

https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html

But in general, that is a good effort, keep going on!

Best,

Hosnieh

 

 


--------------7D4F95C22B09D9685D63089C-- From nobody Wed Jul 12 08:45:56 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809F712F257 for ; Wed, 12 Jul 2017 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=juniper.net 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 QoQwfUOppmME for ; Wed, 12 Jul 2017 08:45:53 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0124.outbound.protection.outlook.com [104.47.42.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FA712F3D5 for ; Wed, 12 Jul 2017 08:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AoWbSNK3e78SZ4uRY9Wfaf4QA5cSD87N+mqBFex8JxI=; b=BOkQiNp+vlc8B1XpHdldnjmRLRGFcFkYGiHfCEyieKKuFNA+NSxLu6KrlGqvqKMcfEaQ1jokeLuuSDLrLcdaljwhn57qEsU8dCXbeZCfhNJ6gGDc20EQbZVVPjCD9UEE108Pi1K6jlON3b1Qd1Ws6st7/ajOeHC5u94UKFIFpoM= Received: from SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) by SN1PR0501MB2030.namprd05.prod.outlook.com (10.163.227.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Wed, 12 Jul 2017 15:45:52 +0000 Received: from SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) by SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) with mapi id 15.01.1261.012; Wed, 12 Jul 2017 15:45:52 +0000 From: Ron Bonica To: "int-area@ietf.org" , "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Thread-Index: AdL7Je43Z0B6UbQRQ8OzttnbbdH15Q== Date: Wed, 12 Jul 2017 15:45:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2030; 7:FhaueoBMqo95zVx7wEo1anVMJJ6m9bw2EzjRTaDz71rbDvmO4PBYKrW5gEfhhy5Vrg83K3m6WM3qoSNZvXkS1YjS8j1ycsdAPi7QaeD+OtsVZvWWReIOsUZlL0giTwnYFbLR0lC48cuFmATfYm8WjilBhR9zAiq849BvSoWVWymMX7Hpfx3tkV0sXJDuwwFoxWZuZlRmHXQXpjsI+fwgFfrFYZE6VQMyfit02+daCrOqvmuI0LB5tM+M5tJIP6ivOQOXGa6M62vazphEs7uXHOi8KZJXXnXio2qliZA6bL7gPU/L+1gxxIJ3kRD9SjkuKnyV0YlzBt8FQamyOeUar4A9GxDN5aLiSsmTu1gz4B3jUtKt1/jIuf09igTvvEX3wpiJXu0yx4i3kIyHzjNCSdg9wYoQ8fQFUgscY5noy03De3Y9x8m5+LiteG2axIUd4gLLCu4uDw+cIOKr2CosmzonpqkqD/9W08KO39P3NjOtWPG9N+zpMml3jktI2Amx8+s4Q4jrjVolpFP5ajbeBhEc7u6wBvcSMMGcyC3uazMBG+J6pzL9di0XaAxW3WJaIf2FWqdr7M/GPL/j51QeieXpAiPffEOFo4k/jG4rvmegmreeLdr5pmSCskNUlahTzhLK1r8FwFWfSrXg6RIvqIqKV+GDZoP5UzRrfs3ar/gu/2j69Lkzhi7mBk8obJXmFke7IkchVmbKMZPuy9jhTPf2VclWwTaGxUJ9Fs5B/VMuY/iw8IH955dsxMUeFdwl2YXb7tUZt0AmkVBSGE7fPA1muDc3Q19Dy5fgjgIEd8U= x-ms-office365-filtering-correlation-id: 98ebb0bf-d30f-47df-d765-08d4c93d1387 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)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR0501MB2030; x-ms-traffictypediagnostic: SN1PR0501MB2030: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(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)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB2030; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB2030; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(39400400002)(3846002)(230783001)(6506006)(77096006)(229853002)(102836003)(2900100001)(7696004)(3280700002)(6116002)(2906002)(54356999)(3660700001)(25786009)(86362001)(50986999)(5660300001)(66066001)(2501003)(7736002)(189998001)(38730400002)(8676002)(6246003)(8936002)(53936002)(6306002)(305945005)(99286003)(9686003)(74316002)(55016002)(14454004)(478600001)(6436002)(966005)(81166006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2030; H:SN1PR0501MB2062.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 15:45:52.2690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2030 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 15:45:55 -0000 Hi Carlos, Thanks for the review. Inline, below. Ron >=20 > Hi, Ron, Authors, >=20 > As I was reading over draft-ietf-intarea-probe-00, and wanted to share a > couple of observations for your consideration. >=20 >=20 > * Have you considered the tradeoff of defining new ICMP Types versus > extending existing ICMP Types? If using existing ICMPv6 Echo Request/Repl= y > and extending them instead of defining brand new types, the backwards > interoperability achieved is higher [ [RB ]=20 I thought about extending the existing ICMP messages, but decided against i= t for backward compatibility reasons. Both existing messages end with a var= iable length data field. This field begins at a fixed position, but doesn't= have a length attribute of its own. Therefore, we can't add any more field= s after it. There may be ways to dance around the problem, but they all involve redefin= ing the existing field in the existing message. > * Have you considered using other protocols as well in addition to IC= MP for > the PROBE message, which can elicit ICMP errors or responses with > appropriate extensions? In particular UDP is a protocol much used and > desired for probes. >=20 [RB ]=20 ICMP and UDP would both work. I chose ICMP because ICMP already supports le= gacy echo/echo reply. But I'm not feeling religious about this. In the final analysis, I am willing to use whatever protocol the WG prefers= . > These two points actually reminded me of https://tools.ietf.org/html/draf= t- > shen-traceroute-ping-ext-04 (and the ICMP-only predecessor draft-shen- > udp-traceroute-ext-01) that defines a probe extension applied to ICMP Ech= o > Request and UDP, and RFC 4884 extensions to responses. That approach > seems somewhat more generic. >=20 > Additionally, I was also reminded of the ICMP AUP at RFC 7279, it would b= e > useful to map against that doc to show how this is (as it is the case) a = really > good use of ICMP. [RB ]=20 Section 3 of 7279 suggests that ICMP can be used for diagnostics. It calls = out PING as being an acceptable use. But again, I don't feel religious abou= t this. The protocol works over UDP just as well as it works over ICMP. = Ron >=20 > Thanks! >=20 > ? Carlos. >=20 >=20 ******************************* From nobody Wed Jul 12 17:35:00 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED5129B3A for ; Wed, 12 Jul 2017 17:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 OK3e0Qxs5nkN for ; Wed, 12 Jul 2017 17:34:56 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 BA5441272E1 for ; Wed, 12 Jul 2017 17:34:56 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id k192so28883106ith.1 for ; Wed, 12 Jul 2017 17:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=6ll2OPte+pMqKsPoRueGRorcmQMSEs6EGERxVQd6GJM=; b=RCgwhGslnXhOu0eFHi0F+38xPwmyJ4klq/i4Kb6BNRgViYhEIXm0s9mQ4yBRSZFjxY oqRVbenjESKoOTfWAyKycjMQ39pdhZ6JCUUjIbmhZRs32DynaP+hOj3/TlRgYZlFIJt4 LUiC1Kw9vnKwnBvV2shXAO0ot+fsJWrlLOa48rkLT79UsujambylwUL2E00auwsM+Awg Nmk3YCCexsiSwtZSFjRE3pyO++NPubGkk0RnFgeyUziwmaoye4ESqEaP4Vej2i+mtnCl qV+G+hYGvAo/ve6o8WgQCPF9233H5/9AL+t2JKdruXSOdj7IvRBIqgoCCnNf+cteTvr3 oPTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=6ll2OPte+pMqKsPoRueGRorcmQMSEs6EGERxVQd6GJM=; b=G3Sacxbm8xu13vWPR9KLhZyQvQ2mzXYhx0eQZsC/2jI0c1ilXJr+h223MU5dr/10ev Pn8XFaJBhtK1hD0JIbapg+LCAbJbJMGlCVACWQq9beyEPOhZlneW9ZxyT7UUetZM7FFg fJW5GNl+ZkJSP5ZWQEAIkOzYV9JRvK8/IzjW1LIcRVkSTEwJ5M4rpJPG377uB9RFY0iY Qu3HczLJTAH+UU5XAO+xDDLIZVP2Zy9vaypw8qMFBiaVFbEcth0qoBbJ3fx3GH/SLQzt 9ZCDhY2kGJmx9oKj4v/3Ah5oNh9lidp8t5xBTpq+1shJHRfKCsYUzsYLSzlHTAzhNE9B F6Mw== X-Gm-Message-State: AIVw110x+8K7qoSsc4bhipHQsWBtYAJAfvyFjRgUL4kruyXGjc8Kzn0M +7VOXLjLigncGZYnDtTfwsOgSL8PwewEbQI= X-Received: by 10.107.197.4 with SMTP id v4mr1215063iof.124.1499906095963; Wed, 12 Jul 2017 17:34:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Wed, 12 Jul 2017 17:34:35 -0700 (PDT) From: Jen Linkova Date: Thu, 13 Jul 2017 10:34:35 +1000 Message-ID: To: int-area@ietf.org Cc: Brian Trammell Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Int-area] Proposed Path Aware Networking RG Announcement X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 00:34:59 -0000 Hello, (My apologies if you have seen that announcement already in some other mailing lists). 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. Since bringing path awareness to the endpoint has been the focus, especially in the context of the multi homed hosts, of intarea WGs, this RG might be of general interest to the Internet area. 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. >From 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. -- SY, Jen Linkova aka Furry From nobody Thu Jul 13 08:46:07 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: X-Mailman-Approved-At: Thu, 13 Jul 2017 08:46:06 -0700 Subject: Re: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 Thu Jul 13 10:07:40 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:15 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 00:39:34 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA199131A80 for ; Mon, 17 Jul 2017 00:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 gwDyANX3U0DO for ; Mon, 17 Jul 2017 00:39:25 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544A4131945 for ; Mon, 17 Jul 2017 00:39:19 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 19DFB58C4C5 for ; Mon, 17 Jul 2017 09:39:16 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 00CB8B0C5E9; Mon, 17 Jul 2017 09:39:15 +0200 (CEST) Date: Mon, 17 Jul 2017 09:39:15 +0200 From: Toerless Eckert To: int-area@ietf.org Message-ID: <20170717073915.GJ3889@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Int-area] INT AD Office hours ? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:39:28 -0000 When & where ? I did not see a mail on the list with that subject nor on the agenda. Where should i have looked ? Thanks! Toerless From nobody Mon Jul 17 01:15:31 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 303B4131A64; Mon, 17 Jul 2017 01:15:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150027931815.32478.2498741844101648463@ietfa.amsl.com> Date: Mon, 17 Jul 2017 01:15:18 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-probe-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:15:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : PROBE: A Utility For Probing Interfaces Authors : Ron Bonica Reji Thomas Jen Linkova Chris Lenart Mohamed Boucadair Filename : draft-ietf-intarea-probe-01.txt Pages : 17 Date : 2017-07-17 Abstract: This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-probe-01 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-probe-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-probe-01 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 Tue Jul 18 02:30:31 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6A131945 for ; Tue, 18 Jul 2017 02:30:30 -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 IIWisoSmQiIr for ; Tue, 18 Jul 2017 02:30:28 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 82218126E3A for ; Tue, 18 Jul 2017 02:30:28 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 32so11147521qtv.1 for ; Tue, 18 Jul 2017 02:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=REu3VHzo88kc2z9zFhmOI2s/n8Nwh37jFfeEA78YDio=; b=mTKCisryji+tdPYvWHAtqfEbXuKqHaNqybRj2EIoJHnivMKyXfh5+58a5szELrr45+ D8OSLgQw3PyM2/UQUGNIQ3CskQRhY7mvWgDkdLP4FKkB18FWvPasPMx/ghM5Heo5BWdW ssVb/yN2U30/lSJETtBs/NGa14E3DMVEwWo40wOxFWiIavX1/g03wJr5w8TIa/Dh4/SM V50I3qkMGenXLXuHWVn8PFFrOMnvFnIWr0wavNnsFvZnIrr8kPXvfzIGmHkCXeH3Fh+Q uEaBI+HJi6idxnKavZN9HH8AHAaAW5ATOWoS4ykuGuEo7Cn9LcSgna8u80lAvNSl7+bB pUUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=REu3VHzo88kc2z9zFhmOI2s/n8Nwh37jFfeEA78YDio=; b=i2WXICJo6yFt/+WKHFPRExhJ3deAf0AHoiq6kSE9GPCyCBkUesPl0Y3CiazVl1amRd wycCZ4ut8LHWKByma17OFfn9FoEBsfv8cAEyconjQotcLutX+7L0g1I3iVNsoPkoAHfP OuDku+MxFc9WJX0weiEyyHqtGmUdRvrSIbRWh+znR14XVMYXgV8y9Cp3QXJYa6Jio+D0 a5O0uS0Y7tnJ86X5LZe0Sq4Lp4zBkc6lLYhfhDNDLJAxYSKdo73EFalm4b46t91aokUi 5w8qbaD6hTV4CcecaXDw7pUrPUmsVoICpSaSToL2pUG6n4Mez/8DspXFwC+qtx+hh+74 wxBQ== X-Gm-Message-State: AIVw110YRze3UVpihJvef6Lu4lgUHNSu5SrpAXVdhUuNWUOoqfTQVic1 124uEbjkFXlpl3HjQHyopyNfbi8wm+ztt+Y= X-Received: by 10.237.53.79 with SMTP id b15mr734802qte.83.1500370227603; Tue, 18 Jul 2017 02:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.158.196 with HTTP; Tue, 18 Jul 2017 02:30:27 -0700 (PDT) In-Reply-To: <20170717073915.GJ3889@faui40p.informatik.uni-erlangen.de> References: <20170717073915.GJ3889@faui40p.informatik.uni-erlangen.de> From: Suresh Krishnan Date: Tue, 18 Jul 2017 05:30:27 -0400 Message-ID: To: Toerless Eckert Cc: int-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] INT AD Office hours ? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:30:30 -0000 Hi Toerless, The INT AD office hours are Thursday 13:30-14:30 at the Paris Room (Lobby Level). Thanks Suresh On Mon, Jul 17, 2017 at 3:39 AM, Toerless Eckert wrote: > > When & where ? I did not see a mail on the list with that subject nor on the > agenda. Where should i have looked ? > > Thanks! > Toerless > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Jul 18 15:22:21 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA52F126B71 for ; Tue, 18 Jul 2017 15:22:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 3Nntf0rBrFrI for ; Tue, 18 Jul 2017 15:22:12 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 B357C1200F3 for ; Tue, 18 Jul 2017 15:22:11 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 12so48865865wrb.1 for ; Tue, 18 Jul 2017 15:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=eLDhDxMhlqBhA8R4eRxL4scO1mhO2hRM5DuIia0Z4uM=; b=Vx1cOKt3HJp+7jGEQcsf92R4t8T94Szu/s2yVrDSUpYVUxNi7n8Vu0tHmimuSjoXRM 6wLj/6DLM8Ro686D2qRt6RWB+/qjNG688UlQ16h7v3G7SPArNM6R26NkUsTsjiiVHn+H db/Q4YmUoDxBgg6UeSYJrUtfvzi8vo0vYxTRwLC0NWQfurRJU4Qtaco5rXt0SFvN/LXV DwfCXhSF7NMvAsLAYEQgata7S7c8rLV0/jc7aRX4wlm7ir7Ww0CB+uS1oCe5BweuwF4u WcYypt+EDkMJ3HiGNfF1GxuxXp6cr5vRebZgtezbje0e/riMOllIJp+m4VymA9YftOvd Rmiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=eLDhDxMhlqBhA8R4eRxL4scO1mhO2hRM5DuIia0Z4uM=; b=eusBhABiz94XrUZljtEbULGKOOaQK1I68Xe7DBM3etwuA+JJ6Tt5IV8dMUeYBl9WEz kPCrGMnrw9VdmYZ03gkgctTPFR5HzwgUg3W4I9hsCVt7Gp37NlWoZO5sjwFQ5brhO6Lh JYkjtstuBD2wkxALMDrdGOVC1pSp2qcwsvQA9FUBt7Qq5FqJdR4BG7knZ1wh2dcdRpXB p07kYGj+1xiFelJSTUwHmm0SAeh5hzZX72MfEWMN0UD0EmhHHm0CND8U361gUtfxsiID MztIh/iac0QobHeI88x3Og1wmQaru7ZUhJkC59/6eCitvavhATQsjtTTjpkOYvJgSHKx +6Cw== X-Gm-Message-State: AIVw111UEQfUKg4VcmDN9h48SI2XKtvDRHXG9c0RVWYKLyQf9IqhZk7y wVBR4hWIArYF2Bp4lOzPwaodUZ4zIklpUziZ2MKL1TPRETSJ3jzHVC0tw/3X/grmfmgJxA== X-Received: by 10.28.139.145 with SMTP id n139mr3652583wmd.53.1500416530214; Tue, 18 Jul 2017 15:22:10 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id y12sm5272348wrb.39.2017.07.18.15.22.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 15:22:09 -0700 (PDT) To: Internet Area , tsv-area@ietf.org From: Olivier Bonaventure Message-ID: Date: Wed, 19 Jul 2017 00:22:07 +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 Archived-At: Subject: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:22:15 -0000 Hello, The design of Multipath TCP (RFC6824) has been heavily influenced by various types of interferences caused by middleboxes. These problems have been solved and the protocol is deployed at a large scale by several smartphone vendors. One of the remaining items of the charter of the MPTCP working group is to "...explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled." One of the use cases for those MPTCP-aware middleboxes are the smartphones equipped with WiFi and cellular interfaces. Today, there are very few servers that support Multipath TCP and smartphones would benefit from using MPTCP over the cellular and WiFi network to a middlebox that would convert MPTCP into TCP and vice-versa. The working group has discussed this issue several times and today we have presented a new design that supports the creation of such functions to convert MPTCP connections into TCP connections and vice versa. The design was done with MPTCP in mind, but the proposed solution could be more generic and applied to other use cases than MPTCP. The draft that describes the new design is available via: https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt Mirja Kuehlewind suggested to send the document on the int-area and tsv-area mailing lists to see whether other working groups could be interested by this approach. I'm available this week in Prague if someone wants to discuss. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Tue Jul 18 15:32:30 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8D129B2A; Tue, 18 Jul 2017 15:32:28 -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 gxoRpWKOg9T7; Tue, 18 Jul 2017 15:32:26 -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 B3E21129AD7; Tue, 18 Jul 2017 15:32:26 -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 v6IMVl5m013722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jul 2017 15:31:50 -0700 (PDT) To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: From: Joe Touch Message-ID: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> Date: Tue, 18 Jul 2017 15:31:45 -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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:32:29 -0000 Hi, all, I've noted this before, but to share with other areas: Although I'm not averse to middleboxes as optional optimizations, I find the proposed mechanisms aren't quite optional -- they inject option information into the SYN data. That information would poison a connection to a legacy receiver if (more to the point, when) that info isn't removed by a proxy upstream of the receiver. TCP must be E2E and fall back to legacy endpoints without a reconnection attempt, as required by RFC793. These aren't generic solutions; they're attacks on a TCP connection, IMO. Joe On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: > The working group has discussed this issue several times and today we > have presented a new design that supports the creation of such > functions to convert MPTCP connections into TCP connections and vice > versa. The design was done with MPTCP in mind, but the proposed > solution could be more generic and applied to other use cases than > MPTCP. The draft that describes the new design is available via: > > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt > > > Mirja Kuehlewind suggested to send the document on the int-area and > tsv-area mailing lists to see whether other working groups could be > interested by this approach. From nobody Tue Jul 18 15:43:20 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6D128990 for ; Tue, 18 Jul 2017 15:43:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 4pLaB6XcOUSf for ; Tue, 18 Jul 2017 15:43:16 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 97A1F126BFD for ; Tue, 18 Jul 2017 15:43:16 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id w4so48272977wrb.2 for ; Tue, 18 Jul 2017 15:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KLSif0XK7/faqBxRJcEtryxQWP/AV+5zl+sUVqtRQ2k=; b=h9tL9dH+scvnnLOmlieh/gnx1Zthve/NVkoWSyp4GturHbvzUUKHi7qkWXNUj8J8z2 nt/7hspRwzEYcgHqOESQek9/R6lWQb0v2xGg2dguUGfLjo4CTzEovuEEoag1am5U+lkM 1HRJGlQSGCqHL/is4zYe33pAwEt1pI24YX/RspcZvZO/NI58V+vaUhUbO6iYMBUZqQXz p4J4gt09BclUd9AiOHLrf00a/0FbUgr7peNRGPtJrY0snfJXdyHoQIu6jMFc31fLGJZB g+YhK+h4PeJfqHJz1x6H+Cxp8EXyN8s9X7yLfHMeGRAlHW4NMaids0lzk62oSzvkfqAi MIEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KLSif0XK7/faqBxRJcEtryxQWP/AV+5zl+sUVqtRQ2k=; b=C4PVADzPXaTJESJo/CtFeNlXSnOEgUb0PoL7Bu12MatPqJJ6E8c2H21uURNHp/6xE9 YJnkAwqLEECt5QKPUcC02FRn06x9L51subyEb3XVJ81ibEWQnzOXoX8YqggxMqHc/u+h zEMXiLGV1WMZ2DGGWZtDRaQQ6PCAfxxrj5yqDsi6Te11ge+hbX4NozH5zBzU5++0i/cN komgGZaXN0Y3vZqQ2B2wOcV9W0b5p12px3n+jqFQ//7hZJz7VmsOZkaWqfyD6jNr2iTM 3h0ukc/FLlgQp9GwTpom9ghY1avzzDdSp93SVSPUL4eorTUbWrE16tOpjuKeCaBi+Uxp o1WQ== X-Gm-Message-State: AIVw112AihJYlhHPnAalulr5pRA7wGXMg4MQFwWegy70cg/QCc7fBFxW +1CDtU6uaUae8/SvuaZevnFClyIu7p6s X-Received: by 10.223.135.112 with SMTP id 45mr2475782wrz.133.1500417795030; Tue, 18 Jul 2017 15:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Tue, 18 Jul 2017 15:43:14 -0700 (PDT) In-Reply-To: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> From: Tom Herbert Date: Tue, 18 Jul 2017 15:43:14 -0700 Message-ID: To: Joe Touch Cc: Olivier Bonaventure , Internet Area , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:43:19 -0000 On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote: > Hi, all, > > I've noted this before, but to share with other areas: > > Although I'm not averse to middleboxes as optional optimizations, I find > the proposed mechanisms aren't quite optional -- they inject option > information into the SYN data. That information would poison a > connection to a legacy receiver if (more to the point, when) that info > isn't removed by a proxy upstream of the receiver. > > TCP must be E2E and fall back to legacy endpoints without a reconnection > attempt, as required by RFC793. > > These aren't generic solutions; they're attacks on a TCP connection, IMO. > I agree. This seems be akin to stateful firewalls model that impose artificial requirements on networking (like every TCP packet for a connection must got through some middlebox or the connection is dropped). We need to move things back to E2E semantics for transport protocols-- nodes that try to maintain transport state in the network should be considered the problem not the solution! Tom > Joe > > > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: >> The working group has discussed this issue several times and today we >> have presented a new design that supports the creation of such >> functions to convert MPTCP connections into TCP connections and vice >> versa. The design was done with MPTCP in mind, but the proposed >> solution could be more generic and applied to other use cases than >> MPTCP. The draft that describes the new design is available via: >> >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt >> >> >> Mirja Kuehlewind suggested to send the document on the int-area and >> tsv-area mailing lists to see whether other working groups could be >> interested by this approach. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Jul 18 15:50:01 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23013170E; Tue, 18 Jul 2017 15:49:59 -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 CPLLlJxf5jqp; Tue, 18 Jul 2017 15:49:58 -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 112AB126C23; Tue, 18 Jul 2017 15:49:58 -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 v6IMnhqp002758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jul 2017 15:49:44 -0700 (PDT) To: Tom Herbert Cc: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> From: Joe Touch Message-ID: Date: Tue, 18 Jul 2017 15:49:41 -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="------------04A9FF8E2835E89144EEC472" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:49:59 -0000 This is a multi-part message in MIME format. --------------04A9FF8E2835E89144EEC472 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/18/2017 3:43 PM, Tom Herbert wrote: >> TCP must be E2E and fall back to legacy endpoints without a reconnection >> attempt, as required by RFC793. >> >> These aren't generic solutions; they're attacks on a TCP connection, IMO. >> > I agree. This seems be akin to stateful firewalls model that impose > artificial requirements on networking (like every TCP packet for a > connection must got through some middlebox or the connection is > dropped). We need to move things back to E2E semantics for transport > protocols-- nodes that try to maintain transport state in the network > should be considered the problem not the solution! I'm a little less concerned with state in the network (link layers have state too - both hard and soft). My primary concern is this as an attack on TCP - or its equivalence to an attack. I though the point of true TCP and lower layer security was to prevent such attacks. Perhaps that's why I consider TLS and TCPcrypt to be so badly misnamed. They don't protect *TCP* at all. Joe --------------04A9FF8E2835E89144EEC472 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/18/2017 3:43 PM, Tom Herbert wrote:
TCP must be E2E and fall back to legacy endpoints without a reconnection
attempt, as required by RFC793.

These aren't generic solutions; they're attacks on a TCP connection, IMO.


I agree. This seems be akin to stateful firewalls model that impose
artificial requirements on networking (like every TCP packet for a
connection must got through some middlebox or the connection is
dropped). We need to move things back to E2E semantics for transport
protocols-- nodes that try to maintain transport state in the network
should be considered the problem not the solution!
I'm a little less concerned with state in the network (link layers have state too - both hard and soft).

My primary concern is this as an attack on TCP - or its equivalence to an attack. I though the point of true TCP and lower layer security was to prevent such attacks.

Perhaps that's why I consider TLS and TCPcrypt to be so badly misnamed. They don't protect *TCP* at all.

Joe

--------------04A9FF8E2835E89144EEC472-- From nobody Tue Jul 18 16:06:02 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56D3129AD7 for ; Tue, 18 Jul 2017 16:06:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tessares-net.20150623.gappssmtp.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 6m5AZ1jKNr0p for ; Tue, 18 Jul 2017 16:05:59 -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 373B5126BF3 for ; Tue, 18 Jul 2017 16:05:59 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id v105so19680773wrb.0 for ; Tue, 18 Jul 2017 16:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=p/4sX0C814XIEWHiDv2dbTr9hXswMCG+v7fCwOzFiz0=; b=rdr4M6AiO2EfN2m/hNAlnRqwaSb+qDwpICjxaV2stK7/XLUIBRfyXEniCkC5Je8Hma UteWDoWcmF+QDNgU211X8MJ37zON3C8p7Copnk1rnnY8HtgcOxPcahqU+HCKGDwe4KuM KgLJ+qF5D6KaCiWzMUUJOvdhYtYl4lalW0I+LSocP5vVVQiq3y+1wjIudY1ZHdCqZEWE KihrwqGg4dBG5o2uSj8Yl1UK3sRAo9usm7W1tb0kTtMp9dmSP0j3Fpt+LuFTH69pHGMV igURH99eWupnVRAA5VqnBG+Eqc4HPWvvDysWs0AGa0Pm0D+ES9DBYIYUfx7gKrXnaXrS D6pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=p/4sX0C814XIEWHiDv2dbTr9hXswMCG+v7fCwOzFiz0=; b=BM6FjYoxY9JFDk5gCwa3OZMKsQKiYijw2GVOndy786Uz2XRXmnL4yCqlJKJ5j501Wi XYVa8qo11D4lNVcr1QvPx0nDoVJgeTmHmW3NXZvG2QOjkPELHZHUEDyYIRptvGvEjv5K U3I7szyfzXItdCUIjB6Kr5alHSc/2c5Gulgi4d5azqz4FcxyPm+ml3+WmgG1UuJ9nG6u AdzJDPYkBzgrp2G2DHH6SbxPqbL2fofj4Dk9tAFCePnvnPBkza2Z8issCPUamRnyKohL cPWc8/0/UerulKCdNPje3ZGXEuW+VQg2trdo+PjNIHxqUzpcneuiCcUvV3uwp4jcMG5J 7OdA== X-Gm-Message-State: AIVw113qEOyYygoLm+mOcE3w6JEH9X3SeC+vSKuvyyT0aJAK+eYjpFwK 2j+bJtHk/DtbIc82krBCF9zxvjcN5QI6DL3wbuDAHWv+K7nI2zr9DLz/FY37Zy1OzjIYiA== X-Received: by 10.28.17.11 with SMTP id 11mr3170628wmr.109.1500419157720; Tue, 18 Jul 2017 16:05:57 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id y84sm14811790wmg.12.2017.07.18.16.05.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 16:05:57 -0700 (PDT) To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> From: Olivier Bonaventure Message-ID: <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> Date: Wed, 19 Jul 2017 01:05:56 +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: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 23:06:01 -0000 Joe, > > I've noted this before, but to share with other areas: You noted this about previous documents. The document that I mentioned describes a new design that answers several of the comments that you raised on the mptcp mailing list. > Although I'm not averse to middleboxes as optional optimizations, I find > the proposed mechanisms aren't quite optional -- they inject option > information into the SYN data. That information would poison a > connection to a legacy receiver if (more to the point, when) that info > isn't removed by a proxy upstream of the receiver. This paragraph refers to earlier documents discussed in the MPTCP working group. The new design does not inject option information into the SYN data. It works like an application layer protocol that sends messages in the SYN by using the TFO option. There is no risk of poisoning. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Tue Jul 18 16:13:11 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F6112EC39; Tue, 18 Jul 2017 16:13:10 -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 rwRw2oYd2L-F; Tue, 18 Jul 2017 16:13:08 -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 D0674129B47; Tue, 18 Jul 2017 16:13:08 -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 v6INCSj3025820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jul 2017 16:12:28 -0700 (PDT) To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> From: Joe Touch Message-ID: <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> Date: Tue, 18 Jul 2017 16:12:26 -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: <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> Content-Type: multipart/alternative; boundary="------------86318F3B0ED2952B9BA6D8F1" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 23:13:10 -0000 This is a multi-part message in MIME format. --------------86318F3B0ED2952B9BA6D8F1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/18/2017 4:05 PM, Olivier Bonaventure wrote: >> Although I'm not averse to middleboxes as optional optimizations, I find >> the proposed mechanisms aren't quite optional -- they inject option >> information into the SYN data. That information would poison a >> connection to a legacy receiver if (more to the point, when) that info >> isn't removed by a proxy upstream of the receiver. > > This paragraph refers to earlier documents discussed in the MPTCP > working group. The new design does not inject option information into > the SYN data. It works like an application layer protocol that sends > messages > in the SYN by using the TFO option. There is no risk of poisoning. OK, in that case: - I'm still not averse to middleboxes that accelerate or enhance TCP - IMO, TCP always needs to be able to fall back (which should be true now) - but I remain concerned with "injection piggybacking" - even if this is restricted to option space, it increases the risk of damaging an otherwise working connection - it flies in the face of TCP being E2E, and won't work with TCP-AO or IPsec, which IMO means it can't be considered part of "TCP" at all Joe --------------86318F3B0ED2952B9BA6D8F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 7/18/2017 4:05 PM, Olivier Bonaventure wrote:
Although I'm not averse to middleboxes as optional optimizations, I find
the proposed mechanisms aren't quite optional -- they inject option
information into the SYN data. That information would poison a
connection to a legacy receiver if (more to the point, when) that info
isn't removed by a proxy upstream of the receiver.

This paragraph refers to earlier documents discussed in the MPTCP
working group. The new design does not inject option information into
the SYN data. It works like an application layer protocol that sends messages
in the SYN by using the TFO option. There is no risk of poisoning.

OK, in that case:
- I'm still not averse to middleboxes that accelerate or enhance TCP
- IMO, TCP always needs to be able to fall back (which should be true now)
- but I remain concerned with "injection piggybacking"
    - even if this is restricted to option space, it increases the risk of damaging an otherwise working connection
    - it flies in the face of TCP being E2E, and won't work with TCP-AO or IPsec, which IMO means it can't be considered part of "TCP" at all

Joe
--------------86318F3B0ED2952B9BA6D8F1-- From nobody Tue Jul 18 23:37:44 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F71131897; Tue, 18 Jul 2017 23:37:35 -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, 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, 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 Xo5JAcyP7n_6; Tue, 18 Jul 2017 23:37:30 -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 4AC111317BB; Tue, 18 Jul 2017 23:37:27 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B57C4C05FF; Wed, 19 Jul 2017 08:37:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 7DC101A00A3; Wed, 19 Jul 2017 08:37:25 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 08:37:25 +0200 From: To: Tom Herbert , Joe Touch CC: "tsv-area@ietf.org" , Internet Area Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTABRXhChVBRjgCUaG1BH6WGredaJaCZWAgAADNgCAAKLIUA== Date: Wed, 19 Jul 2017 06:37:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> 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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:37:35 -0000 Hi Tom, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Tom Herb= ert > Envoy=E9=A0: mercredi 19 juillet 2017 00:43 > =C0=A0: Joe Touch > Cc=A0: tsv-area@ietf.org; Internet Area > Objet=A0: Re: [Int-area] Middleboxes to aid the deployment of MPTCP >=20 > On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote: > > Hi, all, > > > > I've noted this before, but to share with other areas: > > > > Although I'm not averse to middleboxes as optional optimizations, I fin= d > > the proposed mechanisms aren't quite optional -- they inject option > > information into the SYN data. That information would poison a > > connection to a legacy receiver if (more to the point, when) that info > > isn't removed by a proxy upstream of the receiver. > > > > TCP must be E2E and fall back to legacy endpoints without a reconnectio= n > > attempt, as required by RFC793. > > > > These aren't generic solutions; they're attacks on a TCP connection, > IMO. > > > I agree. This seems be akin to stateful firewalls model that impose > artificial requirements on networking (like every TCP packet for a > connection must got through some middlebox or the connection is > dropped). We need to move things back to E2E semantics for transport > protocols-- nodes that try to maintain transport state in the network > should be considered the problem not the solution! >=20 [Med] We would love to avoid requiring adding a function in the network to = assist devices to make use of their multiple interfaces/paths. Nevertheless= , the situation is that servers do not support MPTCP.=20 The proposed solution allows to: * elect some flows to benefit from network-assisted MPTCP while avoiding se= ssion failures. * Policies are configured to identify traffic that won't be forwarded via a= proxy * 0-RTT proxying * MPTCP can be used e2e if both end points are MPTCP-capable (that is, the = proxy is withdrawn from the path). * No interference with TCP options to be negotiated between endpoints. Do you have in mind such use cases when you referred to the "stateful firew= alls model"? > Tom >=20 > > Joe > > > > > > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: > >> The working group has discussed this issue several times and today we > >> have presented a new design that supports the creation of such > >> functions to convert MPTCP connections into TCP connections and vice > >> versa. The design was done with MPTCP in mind, but the proposed > >> solution could be more generic and applied to other use cases than > >> MPTCP. The draft that describes the new design is available via: > >> > >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp- > converters-01.txt > >> > >> > >> Mirja Kuehlewind suggested to send the document on the int-area and > >> tsv-area mailing lists to see whether other working groups could be > >> interested by this approach. > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Jul 18 23:40:05 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BAD12FB9C; Tue, 18 Jul 2017 23:39:56 -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 pCkUXxDrytP8; Tue, 18 Jul 2017 23:39:54 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169B912ECB4; Tue, 18 Jul 2017 23:39:54 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id BACA620712; Wed, 19 Jul 2017 08:39:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 7D45D200B2; Wed, 19 Jul 2017 08:39:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 08:39:52 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTABRXhChVBRjgCUaG1BH6WGredaJaCZWAgAAJjQCAAAHRAIAAlzNA Date: Wed, 19 Jul 2017 06:39:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00EA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> In-Reply-To: <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> 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_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:39:56 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSW50 LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpv ZSBUb3VjaA0KRW52b3nDqSA6IG1lcmNyZWRpIDE5IGp1aWxsZXQgMjAxNyAwMToxMg0Kw4AgOiBP bGl2aWVyIEJvbmF2ZW50dXJlOyBJbnRlcm5ldCBBcmVhOyB0c3YtYXJlYUBpZXRmLm9yZw0KT2Jq ZXQgOiBSZTogW0ludC1hcmVhXSBNaWRkbGVib3hlcyB0byBhaWQgdGhlIGRlcGxveW1lbnQgb2Yg TVBUQ1ANCg0KDQoNCg0KT24gNy8xOC8yMDE3IDQ6MDUgUE0sIE9saXZpZXIgQm9uYXZlbnR1cmUg d3JvdGU6DQpBbHRob3VnaCBJJ20gbm90IGF2ZXJzZSB0byBtaWRkbGVib3hlcyBhcyBvcHRpb25h bCBvcHRpbWl6YXRpb25zLCBJIGZpbmQNCnRoZSBwcm9wb3NlZCBtZWNoYW5pc21zIGFyZW4ndCBx dWl0ZSBvcHRpb25hbCAtLSB0aGV5IGluamVjdCBvcHRpb24NCmluZm9ybWF0aW9uIGludG8gdGhl IFNZTiBkYXRhLiBUaGF0IGluZm9ybWF0aW9uIHdvdWxkIHBvaXNvbiBhDQpjb25uZWN0aW9uIHRv IGEgbGVnYWN5IHJlY2VpdmVyIGlmIChtb3JlIHRvIHRoZSBwb2ludCwgd2hlbikgdGhhdCBpbmZv DQppc24ndCByZW1vdmVkIGJ5IGEgcHJveHkgdXBzdHJlYW0gb2YgdGhlIHJlY2VpdmVyLg0KDQpU aGlzIHBhcmFncmFwaCByZWZlcnMgdG8gZWFybGllciBkb2N1bWVudHMgZGlzY3Vzc2VkIGluIHRo ZSBNUFRDUA0Kd29ya2luZyBncm91cC4gVGhlIG5ldyBkZXNpZ24gZG9lcyBub3QgaW5qZWN0IG9w dGlvbiBpbmZvcm1hdGlvbiBpbnRvDQp0aGUgU1lOIGRhdGEuIEl0IHdvcmtzIGxpa2UgYW4gYXBw bGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgdGhhdCBzZW5kcyBtZXNzYWdlcw0KaW4gdGhlIFNZTiBi eSB1c2luZyB0aGUgVEZPIG9wdGlvbi4gVGhlcmUgaXMgbm8gcmlzayBvZiBwb2lzb25pbmcuDQoN Ck9LLCBpbiB0aGF0IGNhc2U6DQotIEknbSBzdGlsbCBub3QgYXZlcnNlIHRvIG1pZGRsZWJveGVz IHRoYXQgYWNjZWxlcmF0ZSBvciBlbmhhbmNlIFRDUA0KW01lZF0gVGhlIHByb3Bvc2FsIGxldmVy YWdlcyBvbiBleGlzdGluZyBJRVRGIFJGQ3MgYW5kIEJDUHMgdG8gYXNzaXN0IGVzdGFibGlzaGlu ZyBjb21tdW5pY2F0aW9ucyBvdmVyIG11bHRpcGxlIHBhdGhzIGV2ZW4gaWYgdGhlIHJlbW90ZSBz ZXJ2ZXIgaXMgbm90IE1QVENQLWNhcGFibGUuIEJUVywgd2UgaW50ZWdyYXRlZCBhbG1vc3QgYWxs IHRoZSBzdWdnZXN0aW9ucyB5b3UgbWFkZSBwcmV2aW91c2x5IChlLmcuLCB1c2UgYSBkZWRpY2F0 ZWQgc2VydmljZSBwb3J0LCBmaWd1cmUgb3V0IGhvdyB0byB1c2UgVEZPIHRvIGdldCBURk8gcGVy Zm9ybWFuY2UpLg0KDQoNCi0gSU1PLCBUQ1AgYWx3YXlzIG5lZWRzIHRvIGJlIGFibGUgdG8gZmFs bCBiYWNrICh3aGljaCBzaG91bGQgYmUgdHJ1ZSBub3cpDQpbTWVkXSBXZSBhcmUgbm90IGludGVy ZmVyaW5nIHdpdGggdGhpcy4NCg0KLSBidXQgSSByZW1haW4gY29uY2VybmVkIHdpdGggImluamVj dGlvbiBwaWdneWJhY2tpbmciDQogICAgLSBldmVuIGlmIHRoaXMgaXMgcmVzdHJpY3RlZCB0byBv cHRpb24gc3BhY2UsIGl0IGluY3JlYXNlcyB0aGUgcmlzayBvZiBkYW1hZ2luZyBhbiBvdGhlcndp c2Ugd29ya2luZyBjb25uZWN0aW9uDQpbTWVkXSBJIGRvbuKAmXQgdW5kZXJzdGFuZCB5b3VyIHJl ZmVyZW5jZSB0byB0aGUgb3B0aW9uIHNwYWNlLg0KDQogICAgLSBpdCBmbGllcyBpbiB0aGUgZmFj ZSBvZiBUQ1AgYmVpbmcgRTJFLCBhbmQgd29uJ3Qgd29yayB3aXRoIFRDUC1BTyBvciBJUHNlYywg d2hpY2ggSU1PIG1lYW5zIGl0IGNhbid0IGJlIGNvbnNpZGVyZWQgcGFydCBvZiAiVENQIiBhdCBh bGwNCltNZWRdIFR3byBjb21tZW50cyBoZXJlOg0KDQrCtyAgICAgICAgIEl0IHNlZW1zIHRoYXQg eW91IGFzc3VtZSBhbGwgdGhlIHRyYWZmaWMgd2lsbCBiZSBzeXN0ZW1hdGljYWxseSByZWxheWVk IHRvIGEgcHJveHkuIFRoaXMgaXMgbm90IHRoZSBhc3N1bXB0aW9uIHdlIGhhdmUgaW4gdGhlIG1w dGNwIFdHLg0KDQrCtyAgICAgICAgIFRoZSBtZWNoYW5pc21zIHlvdSBtZW50aW9uZWQgYXJlIGtu b3duIHRvIGhhdmUgaXNzdWVzIHdpdGggTkFUOyBleHRlbnNpb25zIGV4aXN0IHRvIHNvZnRlbiBz b21lIG9mIHRoZW0uIEkgZG9u4oCZdCBzZWUgYSBuZXcgaXNzdWUgb3V0IHRoZXJlIHdoZW4gaXQg Y29tZSB0byBhbiBuZXR3b3JrLWFzc2lzdGVkIE1QVENQIHByb3h5Lg0KDQoNCkpvZQ0K --_000_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDgzODE1MTY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDYyMTEzOTIwIC0xNjEwNjk4NDggNjc4OTUyOTkg Njc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4 OTUzMDE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSm9lLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBJbnQtYXJlYSBbbWFpbHRvOmludC1hcmVhLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBKb2UgVG91Y2g8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDAxOjEyPGJyPg0KPGI+w4Am bmJzcDs6PC9iPiBPbGl2aWVyIEJvbmF2ZW50dXJlOyBJbnRlcm5ldCBBcmVhOyB0c3YtYXJlYUBp ZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtJbnQtYXJlYV0gTWlkZGxlYm94 ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzE4LzIwMTcg NDowNSBQTSwgT2xpdmllciBCb25hdmVudHVyZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdGhvdWdoIEknbSBub3QgYXZlcnNlIHRvIG1p ZGRsZWJveGVzIGFzIG9wdGlvbmFsIG9wdGltaXphdGlvbnMsIEkgZmluZA0KPGJyPg0KdGhlIHBy b3Bvc2VkIG1lY2hhbmlzbXMgYXJlbid0IHF1aXRlIG9wdGlvbmFsIC0tIHRoZXkgaW5qZWN0IG9w dGlvbiA8YnI+DQppbmZvcm1hdGlvbiBpbnRvIHRoZSBTWU4gZGF0YS4gVGhhdCBpbmZvcm1hdGlv biB3b3VsZCBwb2lzb24gYSA8YnI+DQpjb25uZWN0aW9uIHRvIGEgbGVnYWN5IHJlY2VpdmVyIGlm IChtb3JlIHRvIHRoZSBwb2ludCwgd2hlbikgdGhhdCBpbmZvIDxicj4NCmlzbid0IHJlbW92ZWQg YnkgYSBwcm94eSB1cHN0cmVhbSBvZiB0aGUgcmVjZWl2ZXIuIDxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhpcyBwYXJhZ3JhcGggcmVm ZXJzIHRvIGVhcmxpZXIgZG9jdW1lbnRzIGRpc2N1c3NlZCBpbiB0aGUgTVBUQ1AgPGJyPg0Kd29y a2luZyBncm91cC4gVGhlIG5ldyBkZXNpZ24gZG9lcyBub3QgaW5qZWN0IG9wdGlvbiBpbmZvcm1h dGlvbiBpbnRvIDxicj4NCnRoZSBTWU4gZGF0YS4gSXQgd29ya3MgbGlrZSBhbiBhcHBsaWNhdGlv biBsYXllciBwcm90b2NvbCB0aGF0IHNlbmRzIG1lc3NhZ2VzIDxicj4NCmluIHRoZSBTWU4gYnkg dXNpbmcgdGhlIFRGTyBvcHRpb24uIFRoZXJlIGlzIG5vIHJpc2sgb2YgcG9pc29uaW5nLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHNw YW4gbGFuZz0iRU4tVVMiPk9LLCBpbiB0aGF0IGNhc2U6PGJyPg0KLSBJJ20gc3RpbGwgbm90IGF2 ZXJzZSB0byBtaWRkbGVib3hlcyB0aGF0IGFjY2VsZXJhdGUgb3IgZW5oYW5jZSBUQ1A8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5bTWVkXSBUaGUgcHJvcG9zYWwgbGV2ZXJhZ2VzIG9uIGV4aXN0aW5nIElFVEYgUkZDcyBh bmQgQkNQcyB0byBhc3Npc3QgZXN0YWJsaXNoaW5nIGNvbW11bmljYXRpb25zIG92ZXIgbXVsdGlw bGUgcGF0aHMgZXZlbiBpZiB0aGUgcmVtb3RlIHNlcnZlciBpcyBub3QgTVBUQ1AtY2FwYWJsZS4N CiBCVFcsIHdlIGludGVncmF0ZWQgYWxtb3N0IGFsbCB0aGUgc3VnZ2VzdGlvbnMgeW91IG1hZGUg cHJldmlvdXNseSAoZS5nLiwgdXNlIGEgZGVkaWNhdGVkIHNlcnZpY2UgcG9ydCwgZmlndXJlIG91 dCBob3cgdG8gdXNlIFRGTyB0byBnZXQgVEZPIHBlcmZvcm1hbmNlKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQotIElNTywgVENQIGFsd2F5cyBuZWVkcyB0byBiZSBh YmxlIHRvIGZhbGwgYmFjayAod2hpY2ggc2hvdWxkIGJlIHRydWUgbm93KTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltN ZWRdIFdlIGFyZSBub3QgaW50ZXJmZXJpbmcgd2l0aCB0aGlzLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCi0gYnV0 IEkgcmVtYWluIGNvbmNlcm5lZCB3aXRoICZxdW90O2luamVjdGlvbiBwaWdneWJhY2tpbmcmcXVv dDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgLSBldmVuIGlmIHRoaXMgaXMgcmVzdHJpY3RlZCB0 byBvcHRpb24gc3BhY2UsIGl0IGluY3JlYXNlcyB0aGUgcmlzayBvZiBkYW1hZ2luZyBhbiBvdGhl cndpc2Ugd29ya2luZyBjb25uZWN0aW9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBkb27igJl0IHVuZGVy c3RhbmQgeW91ciByZWZlcmVuY2UgdG8gdGhlIG9wdGlvbiBzcGFjZS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgLSBpdCBmbGllcyBpbiB0aGUgZmFjZSBvZiBUQ1AgYmVpbmcgRTJF LCBhbmQgd29uJ3Qgd29yayB3aXRoIFRDUC1BTyBvciBJUHNlYywgd2hpY2ggSU1PIG1lYW5zIGl0 IGNhbid0IGJlIGNvbnNpZGVyZWQgcGFydCBvZiAmcXVvdDtUQ1AmcXVvdDsgYXQgYWxsPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+W01lZF0gVHdvIGNvbW1lbnRzIGhlcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JdCBzZWVtcyB0aGF0IHlvdSBhc3N1bWUg YWxsIHRoZSB0cmFmZmljIHdpbGwgYmUgc3lzdGVtYXRpY2FsbHkgcmVsYXllZCB0byBhIHByb3h5 LiBUaGlzIGlzIG5vdCB0aGUgYXNzdW1wdGlvbiB3ZSBoYXZlIGluIHRoZSBtcHRjcCBXRy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRo ZSBtZWNoYW5pc21zIHlvdSBtZW50aW9uZWQgYXJlIGtub3duIHRvIGhhdmUgaXNzdWVzIHdpdGgg TkFUOyBleHRlbnNpb25zIGV4aXN0IHRvIHNvZnRlbiBzb21lIG9mIHRoZW0uIEkgZG9u4oCZdCBz ZWUgYSBuZXcgaXNzdWUgb3V0IHRoZXJlIHdoZW4NCiBpdCBjb21lIHRvIGFuIG5ldHdvcmstYXNz aXN0ZWQgTVBUQ1AgcHJveHkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpKb2U8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_-- From nobody Wed Jul 19 00:41:33 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BC1131C00 for ; Wed, 19 Jul 2017 00:41:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tessares-net.20150623.gappssmtp.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 g7Yk13SR524o for ; Wed, 19 Jul 2017 00:41:21 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 404FD12ECC3 for ; Wed, 19 Jul 2017 00:41:21 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id k71so1294358wrc.2 for ; Wed, 19 Jul 2017 00:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=hXCNlJtFbcbD2PziR6CDsBIv3o6wnbpynxS6InSqHg0=; b=cwaWJ2t6J0fX2bemGLdBQVjlePapcRTC4GPrbYOx5k/WqmFDVnwTvH1qNrcEWyZz3s +9xKUpEe4P4trj5yABc/xK8yTK8W8P3EH6aPLQtoQhxwabGAlxrw7HtCnsU8OiSxfiLs fXjLeqfND5l3v0lxWO9hRM10aLIRRr0ttM0YaQw+6Q3gW76vXqjadysT63D7qNLXFe3p Mp6yncCkUYJWApP2DHCiDh0iVK0uS0pWnZik4QvWYRTYMSOsxDJVVF17vCLP2OcjyyBk 19kPQ6yIxBxfZ0w6mSlh2J928O8/TPqMtYPyjN1Q/ziVDyPyuU9dD4dj84t6XvQsHhn3 q6yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=hXCNlJtFbcbD2PziR6CDsBIv3o6wnbpynxS6InSqHg0=; b=HOXe91vG6evWsr4u2qaRNVe0NSXO2VNb8OqTuYCc1hgt60Rmsu4nwSaO91Q5GWzlfw HpEhY/w8E6iyQkBwhPjQznrqWihtWCpvTWCkuMbkmi+Sd/uE8H4+tg24XPow9dMtoYxu 5jvYFtwpRHDtkTAf98t64G7TIBsGvlnyOV6QbvuAfw9DxXLIXmSlQlPNUVA3xe1kKN6i 7IulALDhEF794sV1CPf9bKcSPOtzAUMFUUUnwEO090u2rn82pxGWdb2EU/BlKbosEy+s RWGtC3cScrM6dQQwJIoqQ/mfJRnTD9pXfYip0XiX0Pko33DmWg300Ihv1UQEVwh8YVkx Bz+A== X-Gm-Message-State: AIVw110SPZThWyVuQV+jrFA+oCmCrsu/t167TAPL5tun+f41lAcKBXeo CmbdNbPJOhsZzU8FvsgrmR/7I/3XLV0rsqE7GVxij++Stcoh6sXOnmunYabTFrFh2XLWOQ== X-Received: by 10.223.158.139 with SMTP id a11mr3504363wrf.131.1500450079601; Wed, 19 Jul 2017 00:41:19 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id 33sm2922628wrr.58.2017.07.19.00.41.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 00:41:19 -0700 (PDT) To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> From: Olivier Bonaventure Message-ID: <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> Date: Wed, 19 Jul 2017 09:41:17 +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: <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:41:23 -0000 Joe, >>> Although I'm not averse to middleboxes as optional optimizations, I find >>> the proposed mechanisms aren't quite optional -- they inject option >>> information into the SYN data. That information would poison a >>> connection to a legacy receiver if (more to the point, when) that info >>> isn't removed by a proxy upstream of the receiver. >> >> This paragraph refers to earlier documents discussed in the MPTCP >> working group. The new design does not inject option information into >> the SYN data. It works like an application layer protocol that sends >> messages >> in the SYN by using the TFO option. There is no risk of poisoning. > > OK, in that case: > - I'm still not averse to middleboxes that accelerate or enhance TCP We agree > - IMO, TCP always needs to be able to fall back (which should be true now) This is not a concern with the proposed design > - but I remain concerned with "injection piggybacking" To which section of the draft are you referring to ? Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 01:30:30 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEC131C1E for ; Wed, 19 Jul 2017 01:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=google.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 kxv6tHwAxctI for ; Wed, 19 Jul 2017 01:30:27 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 E2028131C2A for ; Wed, 19 Jul 2017 01:30:26 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 74so11725775ybf.3 for ; Wed, 19 Jul 2017 01:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qPs/LFMMPbP7ggxMEJxp3hKQNHsmEd8dh8DoLkxXBNE=; b=d5EjQsn0qBM8/1I3gd9DGCvr4l1q45htykUnA7ooIpVHOGEePMznLjAjyFftRAlYiu Dz92zwsrzZPwr7kx/iuKCUuAKB4C/9VeHHyBaIH/1Bvc7eC3OtbrKOmLmnJoAsa8jtGm GMJiTUS9ZNTlfKtMwnFzPhQioO7a5bG7Ct9X4hmDYAh67tKlN419l0NJ+MXaL+e61H9F KZ6RfRgmiFyX2gHURS/FPEFB2I31NnsckLFesybkwSUYjKtcrrv6+EuExQMjkBummO2G QQMYTDQb9Zl66Xq0oJ5aK3o7fGlH621463uiheqtCz75yUow1qfoeaxeJAu/SUiDehWu p/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qPs/LFMMPbP7ggxMEJxp3hKQNHsmEd8dh8DoLkxXBNE=; b=Xvc1pV08lAXRMcS09KRjETOaJof0Ohk35AthlCl/qehN+9lLv3vWxpy753xjuSctLv cF0UDRjR57GhiG0P8I+R+cW+Y34jYVCv5fYhritPlUkdwKmBRTSLgQw2iGH2eBP03hTT uXosricoT8ybDI+jICcOMdCe0xE123JB4Cus6qxnKnccdmxlh0LDZTjG9ep+aJUcJc0Z KrATeCerIDbyolAcd3eg8UkE2eqwsdsLupYuguFW8ZX3YTMebm/EYXAtW/E8NUn0BKWx T/KB9JferSwatoidmbn08XZQ4V2qp4922VCjSpfsDHGTWfouwdxjJwWTckmUhW16wHHN gRPQ== X-Gm-Message-State: AIVw1122pgdZriDlSW9nHyqZbWW16Y3LAZUZoDMXsPdA7prTknly7bZa gMP5XHjyhjPBhVlh/U9RI4rrV/W5Y7DMq0g= X-Received: by 10.37.48.139 with SMTP id w133mr1252080ybw.84.1500453025912; Wed, 19 Jul 2017 01:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.35.69 with HTTP; Wed, 19 Jul 2017 01:30:05 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Erik Kline Date: Wed, 19 Jul 2017 10:30:05 +0200 Message-ID: To: mohamed.boucadair@orange.com Cc: Tom Herbert , Joe Touch , Internet Area , "tsv-area@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11488df6a33bf80554a77103" Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:30:29 -0000 --001a11488df6a33bf80554a77103 Content-Type: text/plain; charset="UTF-8" > [Med] We would love to avoid requiring adding a function in the network to assist devices to make use of their multiple interfaces/paths. Nevertheless, the situation is that servers do not support MPTCP. If server infrastructures aren't supporting MPTCP, maybe that's the thing that needs to be looked at...if in fact it can be helped. --001a11488df6a33bf80554a77103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgVDwaoGW6MlQVILRwJ5Rtww5BroWyCNg9 wGNIrdkBHvMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE5 MDgzMDI2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAI/Fe4+1HfoH2s8VkGcqcM+CX7TEIPp3SUO6szKbj4DO/VviiE4U m0RS0Xz7SLUcrTGfX0vJ+Xm9Lx9WIdclFFI+PMATGEkv0LGSEkP1cf2q1tCHxk3muEM3f5lBkt5e Gp5ndaWeLWiWkm2MC1IuVg/nZukRYnzoUKQMzCAcB0WA26Dk85zHVMIOGAIV3KNT+TUs83O2jkbm fMftmK0T/eAmdQmndxkGRzeWjcVzElD+PSSn9wz3h/ZheQ2ggSz+hX3QAFGhLxL0X1KPN/w/jCX3 aCRlBei0qflrpq3NDGjbDFEbRI19wpWpUc2NXutILFPj57FfCbxuXhSx8I7b7+Q= --001a11488df6a33bf80554a77103-- From nobody Wed Jul 19 01:46:49 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10DB131C2F; Wed, 19 Jul 2017 01:46:42 -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, 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, 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 HSWdxzapeEhq; Wed, 19 Jul 2017 01:46:41 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40400131C38; Wed, 19 Jul 2017 01:46:41 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id E1A5CC0715; Wed, 19 Jul 2017 10:46:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id B3F4F800BC; Wed, 19 Jul 2017 10:46:39 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 10:46:39 +0200 From: To: Erik Kline CC: Tom Herbert , Joe Touch , "Internet Area" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAGlI/K5LY2P7TE6q+ZKxS6zSn6Ja0ebg Date: Wed, 19 Jul 2017 08:46:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:46:43 -0000 SGkgRXJpaywNCg0KVGhhdCdzIHRoZSBpbnR1aXRpdmUgYXBwcm9hY2ggdG8gZm9sbG93IGJ1dCB1 bmZvcnR1bmF0ZWx5IHRoZSBzaXR1YXRpb24gaXMgbm90IHRoYXQgb2J2aW91cyB0byBnZXQgaW50 by4gDQoNCk5ldHdvcmsgcHJvdmlkZXJzIGRvIG5vdCBoYXZlIGEgY29udHJvbCBvbiB0aGUgc2Vy dmVycyBhbmQgdGhlIHRlcm1pbmFscyB0aGF0IGFyZSBlbmFibGVkIGJ5IGN1c3RvbWVycyBiZWhp bmQgdGhlIENQRS4gU28gbWFraW5nIHVzZSBvZiBNUFRDUCB0byBncmFiIG1vcmUgcmVzb3VyY2Vz ICh3aGVuIGF2YWlsYWJsZSkgb3IgdG8gcHJvdmlkZSBiZXR0ZXIgcmVzaWxpZW5jeSAod2hlbiBh IG5ldHdvcmsgYXR0YWNobWVudCBpcyBsb3N0KSB3aWxsIHJlcXVpcmUgYm90aCBlbmRwb2ludHMg dG8gYmUgTVBUQ1AtY2FwYWJsZS4gDQoNCldlIGFyZSBpbiBhIHNpdHVhdGlvbiB3aGVyZSBjdXN0 b21lcnMgYXJlIHByb3ZpZGVkIHdpdGggbXVsdGlwbGUgYWNjZXNzZXMgYnV0IHRoZXNlIGN1c3Rv bWVycyBkbyBvbmx5IGhhdmUgdGhlIFFvRSBhcyBpZiB0aGV5IGFyZSBzaW5nbGUtY29ubmVjdGVk LiANCg0KVGhlIG5ldHdvcmstYXNzaXN0ZWQgTVBUQ1AgaXMgYSBmZWF0dXJlIHRvIGhhdmUgaW1t ZWRpYXRlbHkgdGhlIGJlbmVmaXRzIG9mIE1QVENQIHdpdGhvdXQgcmVxdWlyaW5nIHRoYXQgYWxs IHRlcm1pbmFscyBhbmQgc2VydmVycyBhcmUgTVBUQ1AtY2FwYWJsZS4NCg0KVGhlIGRlc2lnbiB3 ZSBhcmUgYWR2b2NhdGluZyBmb3IgYWxsb3dzIGZvciB0aGUgdXNlIG9mIE1QVENQIGFsb25nIHRo ZSBwYXRoIHdoZW4gYm90aCBlbmRwb2ludHMgYXJlIE1QVENQLWNhcGFibGUgYW5kIHRvIGJ5cGFz cyB0aGUgcHJveHkgd2hlbiBpdCBtYWtlcyBzZW5zZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEVyaWsgS2xpbmUgW21haWx0bzpla0Bn b29nbGUuY29tXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDE5IGp1aWxsZXQgMjAxNyAxMDozMA0K PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+IENjwqA6IFRvbSBIZXJiZXJ0OyBK b2UgVG91Y2g7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3JnDQo+IE9iamV0wqA6IFJl OiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVudCBvZiBNUFRDUA0K PiANCj4gPiBbTWVkXSBXZSB3b3VsZCBsb3ZlIHRvIGF2b2lkIHJlcXVpcmluZyBhZGRpbmcgYSBm dW5jdGlvbiBpbiB0aGUgbmV0d29yaw0KPiB0byBhc3Npc3QgZGV2aWNlcyB0byBtYWtlIHVzZSBv ZiB0aGVpciBtdWx0aXBsZSBpbnRlcmZhY2VzL3BhdGhzLg0KPiBOZXZlcnRoZWxlc3MsIHRoZSBz aXR1YXRpb24gaXMgdGhhdCBzZXJ2ZXJzIGRvIG5vdCBzdXBwb3J0IE1QVENQLg0KPiANCj4gSWYg c2VydmVyIGluZnJhc3RydWN0dXJlcyBhcmVuJ3Qgc3VwcG9ydGluZyBNUFRDUCwgbWF5YmUgdGhh dCdzIHRoZQ0KPiB0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGxvb2tlZCBhdC4uLmlmIGluIGZhY3Qg aXQgY2FuIGJlIGhlbHBlZC4NCg== From nobody Wed Jul 19 08:45:10 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F582131A76 for ; Wed, 19 Jul 2017 08:45:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 4fcKfiCbGPgO for ; Wed, 19 Jul 2017 08:45:06 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 407481317BE for ; Wed, 19 Jul 2017 08:45:06 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id 33so3714484wrz.4 for ; Wed, 19 Jul 2017 08:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CCA8uCf1rl17RLz3Jmv/5hgHdHMez4gHC7u9VG6r6FA=; b=o3MfY53N9FllsxqODB7YnckSKJ31dSVLdVzRw/A/2LA7VMOsiSr3F1GrLx7qQFs5bL DI3Vykz9vqS4uS2jE43VvvE7XLThb3K5pA9gmYsCO/JRKNuR5SnJQyp0AhL+mbCn7P2g qTjUl+IanBnE/dI4uDNibMGgEtnvsnyzB1gJ8MzdxiVNVzAnDR0qbZ3YGMOj55xfi0tV JmaIU/WQsu92dG7ksZeQZQOYFeeziGrwrCEGv5PWwpAlZUfyi8jYYF/lopA88f6Qa0kb xdknf491pbvy8gPXJ2lgI5WQ3uDZg2H23g7ETlnfyf1tDwt20p1jjYy7WCDlvLWQe/xG VOzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CCA8uCf1rl17RLz3Jmv/5hgHdHMez4gHC7u9VG6r6FA=; b=SzGF5y9tDQfzwfvP20mmO7+a7JKHa83A0loCut16TQ3jhxGTnetAOkTrU8e6QkawLg slKgmTWmtKMqUcL5S4X5H/67U7sSF5KZ0SR1CoyNfjXVINz0gDme71U5cqc2b+Ki05y1 ZAyHEOVcWQz7k/B6V4WAv1RFmcGxCPda2isyyN/H7Pnl88qwI6x7ZYXfT37DHPtTQdWS wq6PvNq/Nq0ff+pbVFZ9yBExmShfgL7LIyKIXyuVsJlNvy3LMyE2J/sLnpLH2W88LKKk hx+qlVrMsZLTOPsnY+3lQ0fFp6hQp2hAmuA1ya3XM76CWpLS/cnIz6ZQvX8Zl6FDYOVc SNqw== X-Gm-Message-State: AIVw112OkFFlaRnxJbT/33z5nq8q3z496p5Fu/1dUlgzPEx3ys3lflyY KeeWyOqovkroU53jSPWf97SX4tbabmr8 X-Received: by 10.223.169.2 with SMTP id u2mr713962wrc.288.1500479104427; Wed, 19 Jul 2017 08:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Wed, 19 Jul 2017 08:45:03 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Tom Herbert Date: Wed, 19 Jul 2017 08:45:03 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: Joe Touch , "tsv-area@ietf.org" , Internet Area Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:45:08 -0000 On Tue, Jul 18, 2017 at 11:37 PM, wrote: > Hi Tom, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Tom Herbe= rt >> Envoy=C3=A9 : mercredi 19 juillet 2017 00:43 >> =C3=80 : Joe Touch >> Cc : tsv-area@ietf.org; Internet Area >> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP >> >> On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote: >> > Hi, all, >> > >> > I've noted this before, but to share with other areas: >> > >> > Although I'm not averse to middleboxes as optional optimizations, I fi= nd >> > the proposed mechanisms aren't quite optional -- they inject option >> > information into the SYN data. That information would poison a >> > connection to a legacy receiver if (more to the point, when) that info >> > isn't removed by a proxy upstream of the receiver. >> > >> > TCP must be E2E and fall back to legacy endpoints without a reconnecti= on >> > attempt, as required by RFC793. >> > >> > These aren't generic solutions; they're attacks on a TCP connection, >> IMO. >> > >> I agree. This seems be akin to stateful firewalls model that impose >> artificial requirements on networking (like every TCP packet for a >> connection must got through some middlebox or the connection is >> dropped). We need to move things back to E2E semantics for transport >> protocols-- nodes that try to maintain transport state in the network >> should be considered the problem not the solution! >> > > [Med] We would love to avoid requiring adding a function in the network t= o assist devices to make use of their multiple interfaces/paths. Neverthele= ss, the situation is that servers do not support MPTCP. > > The proposed solution allows to: > * elect some flows to benefit from network-assisted MPTCP while avoiding = session failures. > * Policies are configured to identify traffic that won't be forwarded via= a proxy > * 0-RTT proxying > * MPTCP can be used e2e if both end points are MPTCP-capable (that is, th= e proxy is withdrawn from the path). > * No interference with TCP options to be negotiated between endpoints. > > Do you have in mind such use cases when you referred to the "stateful fir= ewalls model"? One of the problems with stateful firewalls (as well as transparent proxies) is that they require all packets for a flow to consistently traverse the same middlebox device. The middlebox is not addressed by the packet, so the assumed requirement is that packets for the flow go though the same network node by virtue of routing. For a firewall in a single-homed site to the Internet this works because the firewall is the only egress/ingress point to the network. If a site is multi-homed, then the hope is that routing of packets in both directions will go through the same point. But there is absolutely no requirement that network layer packets for a flow are always routed the same way, and if routing does change and packets need to flow through different points the session breaks. If I'm reading the draft correctly, then it has the same property of maintaining transport state in the network so it implies the same requirement that all packets for a flow follow the same path. Personally, would find it ironic that a a protocol to allow muli-path transport would require the network layer to be single path. Tom > >> Tom >> >> > Joe >> > >> > >> > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: >> >> The working group has discussed this issue several times and today we >> >> have presented a new design that supports the creation of such >> >> functions to convert MPTCP connections into TCP connections and vice >> >> versa. The design was done with MPTCP in mind, but the proposed >> >> solution could be more generic and applied to other use cases than >> >> MPTCP. The draft that describes the new design is available via: >> >> >> >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp- >> converters-01.txt >> >> >> >> >> >> Mirja Kuehlewind suggested to send the document on the int-area and >> >> tsv-area mailing lists to see whether other working groups could be >> >> interested by this approach. >> > >> > _______________________________________________ >> > Int-area mailing list >> > Int-area@ietf.org >> > https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jul 19 08:51:32 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267E812F3CB for ; Wed, 19 Jul 2017 08:51:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 6qVafNMVDnki for ; Wed, 19 Jul 2017 08:51:24 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 4A0BA131D70 for ; Wed, 19 Jul 2017 08:51:21 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w126so2811167wme.0 for ; Wed, 19 Jul 2017 08:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=qsHtHCz0luExy7y+wpnfzy3w3KCLVr58LUahyTINlpw=; b=jKGpZYcY7iTAx2yaxO2eSqt0zH5KGrRhRYdgpFRuJHAznwTRqYSAGx2mdeEimbg3cy uhMDGQR7P5Eu9qD0NJIwbbh25bE79QXTNxeAdg6qe7A1+NC8xMYxWoaQi2EPqgaKzbun nHco5lVsrwiV2+2U7W7oUCNIP/l/RtFf8RIe0hIvdFft/hU01jAjevR+rI3YCXlpD9ou 8OkURRh8Ow5uoER1CIfUKl7w89EVKboi7aCvTFCbQS28SmIvvx7Fhjq/pLS5UnMMsuJ/ 0TD2zmZtPPI0NHsOYL9KPXgGbib5nf5clNaYeqIU7DIk9b6QZl8WJ1DCNKgyeF2LMeqz 7NNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qsHtHCz0luExy7y+wpnfzy3w3KCLVr58LUahyTINlpw=; b=qnOE0mi849Cytx+0uLXYFw1v9+zrlrewfRU1xpXUMIhUor9RZRUwbRI9iSKRaDjwix iNAiEltzJiQF23wHPU5L4Meg5RR+h9fW1xkEQTnlj1P1YyOoyBP/vPQ5xY16b1WX9VMA cbta/3FtOQiwkb2SlKtueL/6jzcQHvlMsLyu0BaUwiSGbsClzaI59m+BaqJfH4N2ifcl 1SUlzg8ctKqzN27o4elGWHN6NSFoKIwcuQbpLtQAigE32SAwEI/Ruyc21k1bzTA/gs15 nO7lX9KW98TbRlxcz/7vdQDwgwUWDwv3hHpg1IkAyvdxOvOf7qsLXtQ38jR0PAxpyPQS Ps1w== X-Gm-Message-State: AIVw111ZQyS8ZrUpisF2gf/8QAK8ovPbyKf1JKHuI55LkVDgy2ftACgT vGOuN4GQep9NtIXZJ6t2a1gtNHAJJXliDAr6w0crY1Xa296dVhIY7JjU+gTnNWowjYct+FWmgNQ = X-Received: by 10.28.172.4 with SMTP id v4mr335707wme.72.1500479479745; Wed, 19 Jul 2017 08:51:19 -0700 (PDT) Received: from dhcp-88fc.meeting.ietf.org ([2001:67c:370:128:8ce6:5c6:330:a26f]) by smtp.gmail.com with ESMTPSA id l22sm253442wmi.48.2017.07.19.08.51.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 08:51:18 -0700 (PDT) To: Tom Herbert , mohamed.boucadair@orange.com Cc: Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Olivier Bonaventure Message-ID: <70ccfd9e-e6eb-6f84-856f-fb5912fc0517@tessares.net> Date: Wed, 19 Jul 2017 17:51:17 +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 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:51:26 -0000 Tom, >> >> Do you have in mind such use cases when you referred to the "stateful firewalls model"? > > One of the problems with stateful firewalls (as well as transparent > proxies) is that they require all packets for a flow to consistently > traverse the same middlebox device. The middlebox is not addressed by > the packet, so the assumed requirement is that packets for the flow go > though the same network node by virtue of routing. The proposed converter has one IP address and a reserved port number. Packets follow norm routing path towards this address. > For a firewall in a > single-homed site to the Internet this works because the firewall is > the only egress/ingress point to the network. If a site is > multi-homed, then the hope is that routing of packets in both > directions will go through the same point. But there is absolutely no > requirement that network layer packets for a flow are always routed > the same way, and if routing does change and packets need to flow > through different points the session breaks. > > If I'm reading the draft correctly, then it has the same property of > maintaining transport state in the network so it implies the same > requirement that all packets for a flow follow the same path. > Personally, would find it ironic that a a protocol to allow muli-path > transport would require the network layer to be single path. The motivation for the proposed converters is that the destination does not support MPTCP. To enable the client to leverage the benefits of MPTCP (e.g. in the access networks) the MPTCP connection is terminated on the converter. The client uses the different paths between it and the converter. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 08:57:45 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78209127B60; Wed, 19 Jul 2017 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 5TkdEgjWHDi5; Wed, 19 Jul 2017 08:57:35 -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 39E2F127601; Wed, 19 Jul 2017 08:57:35 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id E7E45C07E1; Wed, 19 Jul 2017 17:57:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id C05EDC0086; Wed, 19 Jul 2017 17:57:33 +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, 19 Jul 2017 17:57:33 +0200 From: To: Tom Herbert CC: Joe Touch , "tsv-area@ietf.org" , Internet Area Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAKX+HMhC89cYFk6ZnEbwm//X0qJbSyGw Date: Wed, 19 Jul 2017 15:57:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F1D8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:57:37 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJi ZXJ0bGFuZC5jb21dDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDE3OjQ1 DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gQ2PCoDogSm9lIFRvdWNoOyB0 c3YtYXJlYUBpZXRmLm9yZzsgSW50ZXJuZXQgQXJlYQ0KPiBPYmpldMKgOiBSZTogW0ludC1hcmVh XSBNaWRkbGVib3hlcyB0byBhaWQgdGhlIGRlcGxveW1lbnQgb2YgTVBUQ1ANCj4gDQo+IE9uIFR1 ZSwgSnVsIDE4LCAyMDE3IGF0IDExOjM3IFBNLCAgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+IHdyb3RlOg0KPiA+IEhpIFRvbSwNCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiA+PiBEZSA6IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBUb20NCj4gSGVyYmVydA0KPiA+PiBFbnZvecOpIDogbWVyY3JlZGkg MTkganVpbGxldCAyMDE3IDAwOjQzDQo+ID4+IMOAIDogSm9lIFRvdWNoDQo+ID4+IENjIDogdHN2 LWFyZWFAaWV0Zi5vcmc7IEludGVybmV0IEFyZWENCj4gPj4gT2JqZXQgOiBSZTogW0ludC1hcmVh XSBNaWRkbGVib3hlcyB0byBhaWQgdGhlIGRlcGxveW1lbnQgb2YgTVBUQ1ANCj4gPj4NCj4gPj4g T24gVHVlLCBKdWwgMTgsIDIwMTcgYXQgMzozMSBQTSwgSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1 PiB3cm90ZToNCj4gPj4gPiBIaSwgYWxsLA0KPiA+PiA+DQo+ID4+ID4gSSd2ZSBub3RlZCB0aGlz IGJlZm9yZSwgYnV0IHRvIHNoYXJlIHdpdGggb3RoZXIgYXJlYXM6DQo+ID4+ID4NCj4gPj4gPiBB bHRob3VnaCBJJ20gbm90IGF2ZXJzZSB0byBtaWRkbGVib3hlcyBhcyBvcHRpb25hbCBvcHRpbWl6 YXRpb25zLCBJDQo+IGZpbmQNCj4gPj4gPiB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtcyBhcmVuJ3Qg cXVpdGUgb3B0aW9uYWwgLS0gdGhleSBpbmplY3Qgb3B0aW9uDQo+ID4+ID4gaW5mb3JtYXRpb24g aW50byB0aGUgU1lOIGRhdGEuIFRoYXQgaW5mb3JtYXRpb24gd291bGQgcG9pc29uIGENCj4gPj4g PiBjb25uZWN0aW9uIHRvIGEgbGVnYWN5IHJlY2VpdmVyIGlmIChtb3JlIHRvIHRoZSBwb2ludCwg d2hlbikgdGhhdA0KPiBpbmZvDQo+ID4+ID4gaXNuJ3QgcmVtb3ZlZCBieSBhIHByb3h5IHVwc3Ry ZWFtIG9mIHRoZSByZWNlaXZlci4NCj4gPj4gPg0KPiA+PiA+IFRDUCBtdXN0IGJlIEUyRSBhbmQg ZmFsbCBiYWNrIHRvIGxlZ2FjeSBlbmRwb2ludHMgd2l0aG91dCBhDQo+IHJlY29ubmVjdGlvbg0K PiA+PiA+IGF0dGVtcHQsIGFzIHJlcXVpcmVkIGJ5IFJGQzc5My4NCj4gPj4gPg0KPiA+PiA+IFRo ZXNlIGFyZW4ndCBnZW5lcmljIHNvbHV0aW9uczsgdGhleSdyZSBhdHRhY2tzIG9uIGEgVENQIGNv bm5lY3Rpb24sDQo+ID4+IElNTy4NCj4gPj4gPg0KPiA+PiBJIGFncmVlLiBUaGlzIHNlZW1zIGJl IGFraW4gdG8gc3RhdGVmdWwgZmlyZXdhbGxzIG1vZGVsIHRoYXQgaW1wb3NlDQo+ID4+IGFydGlm aWNpYWwgcmVxdWlyZW1lbnRzIG9uIG5ldHdvcmtpbmcgKGxpa2UgZXZlcnkgVENQIHBhY2tldCBm b3IgYQ0KPiA+PiBjb25uZWN0aW9uIG11c3QgZ290IHRocm91Z2ggc29tZSBtaWRkbGVib3ggb3Ig dGhlIGNvbm5lY3Rpb24gaXMNCj4gPj4gZHJvcHBlZCkuIFdlIG5lZWQgdG8gbW92ZSB0aGluZ3Mg YmFjayB0byBFMkUgc2VtYW50aWNzIGZvciB0cmFuc3BvcnQNCj4gPj4gcHJvdG9jb2xzLS0gbm9k ZXMgdGhhdCB0cnkgdG8gbWFpbnRhaW4gdHJhbnNwb3J0IHN0YXRlIGluIHRoZSBuZXR3b3JrDQo+ ID4+IHNob3VsZCBiZSBjb25zaWRlcmVkIHRoZSBwcm9ibGVtIG5vdCB0aGUgc29sdXRpb24hDQo+ ID4+DQo+ID4NCj4gPiBbTWVkXSBXZSB3b3VsZCBsb3ZlIHRvIGF2b2lkIHJlcXVpcmluZyBhZGRp bmcgYSBmdW5jdGlvbiBpbiB0aGUgbmV0d29yaw0KPiB0byBhc3Npc3QgZGV2aWNlcyB0byBtYWtl IHVzZSBvZiB0aGVpciBtdWx0aXBsZSBpbnRlcmZhY2VzL3BhdGhzLg0KPiBOZXZlcnRoZWxlc3Ms IHRoZSBzaXR1YXRpb24gaXMgdGhhdCBzZXJ2ZXJzIGRvIG5vdCBzdXBwb3J0IE1QVENQLg0KPiA+ DQo+ID4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGFsbG93cyB0bzoNCj4gPiAqIGVsZWN0IHNvbWUg Zmxvd3MgdG8gYmVuZWZpdCBmcm9tIG5ldHdvcmstYXNzaXN0ZWQgTVBUQ1Agd2hpbGUgYXZvaWRp bmcNCj4gc2Vzc2lvbiBmYWlsdXJlcy4NCj4gPiAqIFBvbGljaWVzIGFyZSBjb25maWd1cmVkIHRv IGlkZW50aWZ5IHRyYWZmaWMgdGhhdCB3b24ndCBiZSBmb3J3YXJkZWQNCj4gdmlhIGEgcHJveHkN Cj4gPiAqIDAtUlRUIHByb3h5aW5nDQo+ID4gKiBNUFRDUCBjYW4gYmUgdXNlZCBlMmUgaWYgYm90 aCBlbmQgcG9pbnRzIGFyZSBNUFRDUC1jYXBhYmxlICh0aGF0IGlzLA0KPiB0aGUgcHJveHkgaXMg d2l0aGRyYXduIGZyb20gdGhlIHBhdGgpLg0KPiA+ICogTm8gaW50ZXJmZXJlbmNlIHdpdGggVENQ IG9wdGlvbnMgdG8gYmUgbmVnb3RpYXRlZCBiZXR3ZWVuIGVuZHBvaW50cy4NCj4gPg0KPiA+IERv IHlvdSBoYXZlIGluIG1pbmQgc3VjaCB1c2UgY2FzZXMgd2hlbiB5b3UgcmVmZXJyZWQgdG8gdGhl ICJzdGF0ZWZ1bA0KPiBmaXJld2FsbHMgbW9kZWwiPw0KPiANCj4gT25lIG9mIHRoZSBwcm9ibGVt cyB3aXRoIHN0YXRlZnVsIGZpcmV3YWxscyAoYXMgd2VsbCBhcyB0cmFuc3BhcmVudA0KPiBwcm94 aWVzKSBpcyB0aGF0IHRoZXkgcmVxdWlyZSBhbGwgcGFja2V0cyBmb3IgYSBmbG93IHRvIGNvbnNp c3RlbnRseQ0KPiB0cmF2ZXJzZSB0aGUgc2FtZSBtaWRkbGVib3ggZGV2aWNlLiBUaGUgbWlkZGxl Ym94IGlzIG5vdCBhZGRyZXNzZWQgYnkNCj4gdGhlIHBhY2tldCwNCg0KW01lZF0gVGhpcyBpcyBu b3QgdGhlIGFjdHVhbCBwcm9wb3NhbC4gVGhlIHByb3h5IGlzIGV4cGxpY2l0bHkgY29uZmlndXJl ZCBzbyB0aGF0IGFsbCBwYWNrZXRzIGFyZSBzZW50IHRvIGl0IGRpcmVjdGx5LiBUaGF0IGlzLCB0 aGUgZGVzdGluYXRpb24gYWRkcmVzcyBvZiBvdXRnb2luZyBwYWNrZXRzIHdpbGwgYmUgc2V0IHRv IHRoZSBvbmUgb2YgdGhhdCBwcm94eS4gIA0KDQogc28gdGhlIGFzc3VtZWQgcmVxdWlyZW1lbnQg aXMgdGhhdCBwYWNrZXRzIGZvciB0aGUgZmxvdyBnbw0KPiB0aG91Z2ggdGhlIHNhbWUgbmV0d29y ayBub2RlIGJ5IHZpcnR1ZSBvZiByb3V0aW5nLiBGb3IgYSBmaXJld2FsbCBpbiBhDQo+IHNpbmds ZS1ob21lZCBzaXRlIHRvIHRoZSBJbnRlcm5ldCB0aGlzIHdvcmtzIGJlY2F1c2UgdGhlIGZpcmV3 YWxsIGlzDQo+IHRoZSBvbmx5IGVncmVzcy9pbmdyZXNzIHBvaW50IHRvIHRoZSBuZXR3b3JrLiBJ ZiBhIHNpdGUgaXMNCj4gbXVsdGktaG9tZWQsIHRoZW4gdGhlIGhvcGUgaXMgdGhhdCByb3V0aW5n IG9mIHBhY2tldHMgaW4gYm90aA0KPiBkaXJlY3Rpb25zIHdpbGwgZ28gdGhyb3VnaCB0aGUgc2Ft ZSBwb2ludC4gQnV0IHRoZXJlIGlzIGFic29sdXRlbHkgbm8NCj4gcmVxdWlyZW1lbnQgdGhhdCBu ZXR3b3JrIGxheWVyIHBhY2tldHMgZm9yIGEgZmxvdyBhcmUgYWx3YXlzIHJvdXRlZA0KPiB0aGUg c2FtZSB3YXksIGFuZCBpZiByb3V0aW5nIGRvZXMgY2hhbmdlIGFuZCBwYWNrZXRzIG5lZWQgdG8g Zmxvdw0KPiB0aHJvdWdoIGRpZmZlcmVudCBwb2ludHMgdGhlIHNlc3Npb24gYnJlYWtzLg0KPiAN Cg0KW01lZF0gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdS4gQnV0LCB3ZSBhcmUgbm90IGluIGEgdHJh bnNwYXJlbnQvaW1wbGljaXQgbW9kZS4gDQoNCj4gSWYgSSdtIHJlYWRpbmcgdGhlIGRyYWZ0IGNv cnJlY3RseSwgdGhlbiBpdCBoYXMgdGhlIHNhbWUgcHJvcGVydHkgb2YNCj4gbWFpbnRhaW5pbmcg dHJhbnNwb3J0IHN0YXRlIGluIHRoZSBuZXR3b3JrIHNvIGl0IGltcGxpZXMgdGhlIHNhbWUNCj4g cmVxdWlyZW1lbnQgdGhhdCBhbGwgcGFja2V0cyBmb3IgYSBmbG93IGZvbGxvdyB0aGUgc2FtZSBw YXRoLg0KDQpbTWVkXSBXZSBkb24ndCBoYXZlIHN1Y2ggcmVxdWlyZW1lbnQuICBUaGUgcHJveHkg aXMgbm90IHN1cHBvc2VkIHRvIGJlIG9uIG9uZSBvZiB0aGUgZGVmYXVsdCBmb3J3YXJkaW5nIHBh dGhzOyBhbGwgd2hhdCB3ZSByZXF1aXJlIGlzIHRoYXQgaXQgaXMgcmVhY2hhYmxlIHVzaW5nIGFu eSBvZiB0aGUgYXZhaWxhYmxlIHBhdGhzLiBTdWJmbG93cyBjYW4gYmUgcGxhY2VkIHVzaW5nIGFu eSBvciBhbGwgb2YgdGhlIGF2YWlsYWJsZSBwYXRocy4NCg0KPiBQZXJzb25hbGx5LCAgd291bGQg ZmluZCBpdCBpcm9uaWMgdGhhdCBhIGEgcHJvdG9jb2wgdG8gYWxsb3cgbXVsaS1wYXRoDQo+IHRy YW5zcG9ydCB3b3VsZCByZXF1aXJlIHRoZSBuZXR3b3JrIGxheWVyIHRvIGJlIHNpbmdsZSBwYXRo Lg0KPg0KDQpbTWVkXSBTb3JyeSwgYnV0IHdlIGRvbuKAmXQgaGF2ZSBzdWNoIGNvbnN0cmFpbnQv cmVxdWlyZW1lbnQuIFNlZSBteSBleHBsYW5hdGlvbiBhYm92ZS4NCg0KIA0KPiBUb20NCj4gDQo+ ID4NCj4gPj4gVG9tDQo+ID4+DQo+ID4+ID4gSm9lDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IE9u IDcvMTgvMjAxNyAzOjIyIFBNLCBPbGl2aWVyIEJvbmF2ZW50dXJlIHdyb3RlOg0KPiA+PiA+PiBU aGUgd29ya2luZyBncm91cCBoYXMgZGlzY3Vzc2VkIHRoaXMgaXNzdWUgc2V2ZXJhbCB0aW1lcyBh bmQgdG9kYXkNCj4gd2UNCj4gPj4gPj4gaGF2ZSBwcmVzZW50ZWQgYSBuZXcgZGVzaWduIHRoYXQg c3VwcG9ydHMgdGhlIGNyZWF0aW9uIG9mIHN1Y2gNCj4gPj4gPj4gZnVuY3Rpb25zIHRvIGNvbnZl cnQgTVBUQ1AgY29ubmVjdGlvbnMgaW50byBUQ1AgY29ubmVjdGlvbnMgYW5kIHZpY2UNCj4gPj4g Pj4gdmVyc2EuIFRoZSBkZXNpZ24gd2FzIGRvbmUgd2l0aCBNUFRDUCBpbiBtaW5kLCBidXQgdGhl IHByb3Bvc2VkDQo+ID4+ID4+IHNvbHV0aW9uIGNvdWxkIGJlIG1vcmUgZ2VuZXJpYyBhbmQgYXBw bGllZCB0byBvdGhlciB1c2UgY2FzZXMgdGhhbg0KPiA+PiA+PiBNUFRDUC4gVGhlIGRyYWZ0IHRo YXQgZGVzY3JpYmVzIHRoZSBuZXcgZGVzaWduIGlzIGF2YWlsYWJsZSB2aWE6DQo+ID4+ID4+DQo+ ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib25hdmVu dHVyZS1tcHRjcC0NCj4gPj4gY29udmVydGVycy0wMS50eHQNCj4gPj4gPj4NCj4gPj4gPj4NCj4g Pj4gPj4gTWlyamEgS3VlaGxld2luZCBzdWdnZXN0ZWQgdG8gc2VuZCB0aGUgZG9jdW1lbnQgb24g dGhlIGludC1hcmVhIGFuZA0KPiA+PiA+PiB0c3YtYXJlYSBtYWlsaW5nIGxpc3RzIHRvIHNlZSB3 aGV0aGVyIG90aGVyIHdvcmtpbmcgZ3JvdXBzIGNvdWxkIGJlDQo+ID4+ID4+IGludGVyZXN0ZWQg YnkgdGhpcyBhcHByb2FjaC4NCj4gPj4gPg0KPiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4gSW50LWFyZWEgbWFpbGluZyBsaXN0DQo+ ID4+ID4gSW50LWFyZWFAaWV0Zi5vcmcNCj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ludC1hcmVhDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEludC1hcmVhIG1haWxpbmcgbGlzdA0KPiA+ PiBJbnQtYXJlYUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ludC1hcmVhDQo= From nobody Wed Jul 19 09:02:53 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25696131B54 for ; Wed, 19 Jul 2017 09:02:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 Z-9OFAz72k7x for ; Wed, 19 Jul 2017 09:02:51 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 B4F84127B60 for ; Wed, 19 Jul 2017 09:02:50 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id k71so7019405wrc.2 for ; Wed, 19 Jul 2017 09:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JyZUUwhZ0FxLQ/3kOfnewTNjAFXbiveoVhSGFtFTswM=; b=WZJhXUUXsISQqtT+IFwX7ZW97aaJpRgvy8tdjeKh0YHo/tzjC0Te7HxUnaiiaw0Mhc eFaM2EvmZnpxm8owlW2zzbCgdMoa2g1jxAbBFQGi3NVtXRAkPYrRhl2TF9dNdz9XsM+g ZgTOGwF6YjMyH+vGtf6iQi9Zh2U8RScH2DAhjZQYkVsR+C2m33620uvzCby/hGPR1/Lm p5dsyQyCcV6PEo429G/Lg2oQE4zenoSGObFl4cEm6NSTt3XTFowzzJu0j1JqcfEsurTS qcnzANBCF47YIoyrVt7m8XMsPfv+VWxaz2sX8CkY1vxnQwvcoUillY47JyLFzJ7k9asG YQ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JyZUUwhZ0FxLQ/3kOfnewTNjAFXbiveoVhSGFtFTswM=; b=K+L15HP7d5R0Dmh7Ek5hbLrsCZsSmTzMN9QmzUXpzUTKVGGLyaHlzMTcKJqPaGiDjH 2Oki6W+tTjlONXZHD2/OhAW4VWhhzGIh2Bz0yVw2iUTwLHSb/Reo897t6xAUckSZQ1dX 5yS+mQJ03iRZ5Bgk23MzeCjb3rC4K1MXBulDZ0db1Oevxe4xS0rqbk8pyKD+1vUPmEhI K2dZf6n7Lxc3+MlUj/42JYYCEkx5S3CR+OquD4dKqMlo7dFLxJt6pNK+Lq5AVtiVCsYB DD93a4NC9v7jMduGW7eh0XyfjOPcamfU8uS+bGXTr9+QkDuI9CrNk/LFn7wp6ImJxCBv Mxqw== X-Gm-Message-State: AIVw110UAShJYpeXIC22th1musrpBF7qtTPYOjZAtpHsZ69CpU3imuHL 19nKjFgI/vQEq+BjZa+98opLIp8T+PGL X-Received: by 10.223.169.2 with SMTP id u2mr751918wrc.288.1500480169275; Wed, 19 Jul 2017 09:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Wed, 19 Jul 2017 09:02:48 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Tom Herbert Date: Wed, 19 Jul 2017 09:02:48 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: Erik Kline , Joe Touch , Internet Area , "tsv-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:02:52 -0000 On Wed, Jul 19, 2017 at 1:46 AM, wrote: > Hi Erik, > > That's the intuitive approach to follow but unfortunately the situation i= s not that obvious to get into. > I can give a little background on the Linux situation. There have been several attempts to get MPTCP into the stack over the past few years. Each time the patches were rejected primary because of complexity and invasiveness. I believe in the initial attempt there were something like 7,000 LOC change to tcp and that was whittled down to 5K on the next attempt IIRC. It is not impossible to get the code in the stack, but it's going to take more work to minimize code change and convince the maintainer the complexity is justified. > Network providers do not have a control on the servers and the terminals = that are enabled by customers behind the CPE. So making use of MPTCP to gra= b more resources (when available) or to provide better resiliency (when a n= etwork attachment is lost) will require both endpoints to be MPTCP-capable. > Network providers don't control CPE is either. I know iOS has support for MPTCP, AFAIK Android does not (Erik is that correct?). If Android were shipping it that would be a strong datapoint towards getting support in Linux. Tom From nobody Wed Jul 19 09:16:39 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB431317CA for ; Wed, 19 Jul 2017 09:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 yF9rkRZod_Sf for ; Wed, 19 Jul 2017 09:16:30 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 05A0D129482 for ; Wed, 19 Jul 2017 09:16:30 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id g127so3763085wmd.0 for ; Wed, 19 Jul 2017 09:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=4Zr9Pw64c4LhWyCniChWA+DG8V1RKcFhhysjmiAwyF0=; b=lQ0T4cR3LKFTgv/3K6Xbdl3xKOcS0jMkij81s7myYUeO28+eZqUvtT3rzHfmPS/wBU cojlngniA7Sv4emRaeuOl0fjcEIwvi/OXf6smMzGQb0J8WPbfFmaLoUZzyrx0JeTTdHu JxWTSgstSrcJPdsIUZsc5SP1tSyK+Cydt1/toiB1akZHKW5OIQ83mRqn1vuv8bfgffL5 zZjGQHhL6ZFwud9hPgDNCJO7FwCkeDU5dyX2xLEIlKGS+3OUKLhTgHzlaaelzA/nzmRm fY4l3MOzvmiU4/Q5eja+1BG2SMTgOtm5ODelpCZhIoKerUe2g+xZl7ptpnGSGdhyVnIh bpDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4Zr9Pw64c4LhWyCniChWA+DG8V1RKcFhhysjmiAwyF0=; b=tKJ0Wcdfk+d1tTUxqdZbEy5742Lf4EcNJZvy6FFX9UIpZob1bW9CYwJZqphvD/Cb9q RoLpUVa0YLCYd2OgSi5BcEgx+tXPzIcRWwTuM8N4IFnOG6vjkpPuZskfzBzkx1YbAY7o iERQxLG1V5JLuGbgVU/xJyN0VOGJyxeIQ+zgDSelpn6ZtVjhh+UXQwL1R13QI0IXf6s8 L2hnQT+mDTRFr4Mp52nfJUrPFa/I1u8JdcG2bcLI0nhC4PRJxbD7lMaWyvtIu2qQj1AU a2pNqzUvSibZh8IL1/OkH3Yl9Q/2NNTJVpYLpHNWLox2o+IK/6vQRF/w7a7YlwTfzayD EmBg== X-Gm-Message-State: AIVw1134Bp61vGaBJShKRpbMU++gMXoujsSTfeqEWsUnunmgs9hdOAkm abRqFv3pUxxldgGag+FM2tn7xD70KfwegDPzRwWYARo1H5PiMGXwdl4JZJEKqM2jq1LuT6ZSrBg = X-Received: by 10.28.61.4 with SMTP id k4mr358451wma.146.1500480988265; Wed, 19 Jul 2017 09:16:28 -0700 (PDT) Received: from dhcp-88fc.meeting.ietf.org ([2001:67c:370:128:114e:6216:c2ae:75f]) by smtp.gmail.com with ESMTPSA id l8sm352543wmd.15.2017.07.19.09.16.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 09:16:27 -0700 (PDT) To: Tom Herbert , mohamed.boucadair@orange.com Cc: "tsv-area@ietf.org" , Internet Area References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Olivier Bonaventure Message-ID: <2a6031ec-2c07-7bf6-8853-7980a183f5d1@tessares.net> Date: Wed, 19 Jul 2017 18:16:26 +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 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:16:34 -0000 Tom, > Network providers don't control CPE is either. I know iOS has support > for MPTCP, AFAIK Android does not (Erik is that correct?). If Android > were shipping it that would be a strong datapoint towards getting > support in Linux. In South Korea, at least 8 popular models of Android smartphones from at least two different vendors are shipped to endusers with MPTCP included in their kernel even if MPTCP is not yet part of the mainline Linux kernel. This deployment is described in https://www.ietfjournal.org/multipath-tcp-deployments/ In June, when Apple announced that they would allow any app to use MPTCP in iOS11, they also mentioned that they would help to push MPTCP upstream in the Linux kernel. This will obvisouly require non-trivial engineering efforts. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 09:33:17 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E732412F3CB; Wed, 19 Jul 2017 09:33:07 -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 vceVDXadn9xu; Wed, 19 Jul 2017 09:33:06 -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 DE962127077; Wed, 19 Jul 2017 09:33:06 -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 v6JGWbHS020438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 09:32:37 -0700 (PDT) To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> From: Joe Touch Message-ID: <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> Date: Wed, 19 Jul 2017 09:32:35 -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: <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> Content-Type: multipart/alternative; boundary="------------9D917349341C7457A2BBA51D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:33:08 -0000 This is a multi-part message in MIME format. --------------9D917349341C7457A2BBA51D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >> - IMO, TCP always needs to be able to fall back (which should be true >> now) > > This is not a concern with the proposed design Prove that is true if/when TCP-AO is enabled. Joe --------------9D917349341C7457A2BBA51D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/19/2017 12:41 AM, Olivier Bonaventure wrote:
- IMO, TCP always needs to be able to fall back (which should be true now)

This is not a concern with the proposed design
Prove that is true if/when TCP-AO is enabled.
Joe
--------------9D917349341C7457A2BBA51D-- From nobody Wed Jul 19 09:36:11 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D3A131AA9; Wed, 19 Jul 2017 09:36:09 -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, RCVD_IN_DNSWL_HI=-5, 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 HYQC9aEho4xJ; Wed, 19 Jul 2017 09:36:08 -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 9FDD3131A50; Wed, 19 Jul 2017 09:36:07 -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 v6JGZYXr020887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 09:35:35 -0700 (PDT) To: mohamed.boucadair@orange.com, Erik Kline Cc: Tom Herbert , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 09:35:32 -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: <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:36:09 -0000 On 7/19/2017 1:46 AM, mohamed.boucadair@orange.com wrote: > So making use of MPTCP to grab more resources (when available) or to provide better resiliency (when a network attachment is lost) will require both endpoints to be MPTCP-capable. That is both correct and appropriate. Doing tricks to demonstrate that an attacker (i.e., something that modifies TCP segments on path) can do otherwise should not be considered a viable alternative. Joe From nobody Wed Jul 19 09:43:42 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCCB131472; Wed, 19 Jul 2017 09:43:41 -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 NtntyiVKVI94; Wed, 19 Jul 2017 09:43:40 -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 3DDF9129482; Wed, 19 Jul 2017 09:43:40 -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 v6JGh2Gb025051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 09:43:03 -0700 (PDT) To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 09:43:01 -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: <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> 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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:43:41 -0000 On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > Joe, > >> - but I remain concerned with "injection piggybacking" > > To which section of the draft are you referring to ? It starts in the arch discussion in Sec 2: As shown in Figure 3, the Converter places its supplied information inside the handshake packets. That's what I refer to as "injection piggybacking" With TCP, the Converter protocol places the destination address and port number of the final Server in the payload of the SYN. And that is the part that violates RFC793 semantics when that SYN reaches the final destination rather than the server-side proxy. To be clear, I'm not interested in further trying to "fix" this mechanism so it can work. It can't and it shouldn't IMO. Let's use our cycles for more productive things. Joe From nobody Wed Jul 19 09:59:20 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEC81316BE for ; Wed, 19 Jul 2017 09:59:14 -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, RP_MATCHES_RCVD=-0.001, 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=swm.pp.se 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 zhrfFIXZk6mm for ; Wed, 19 Jul 2017 09:59:11 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 AC45513166C for ; Wed, 19 Jul 2017 09:59:11 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6EF67A2; Wed, 19 Jul 2017 18:59:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1500483549; bh=mWyQB1/cvVlVhnaqSPrAGjFHSH1QPvlIZoUTcJxIYNw=; h=Date:From:To:Subject:From; b=LlxnjSKkBJ3ujUdiIBTH+UHAPEqSZlv6H8fqH1UlGKSp7M/qXFuxCX/OZ8RpDhmd/ A+gO4oRPsP6cbt/gO3e3SJMHtoxn+s8hesfkgHS5CQZ/PnXPnNzkfoz8ozACEWdwvk dRl9GyHfSbjlHSZsocvRV41guSea+mY2lrP7TfrQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6D005A1 for ; Wed, 19 Jul 2017 18:59:09 +0200 (CEST) Date: Wed, 19 Jul 2017 18:59:09 +0200 (CEST) From: Mikael Abrahamsson To: int-area@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: [Int-area] multicast over wifi discussion list (fwd) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:59:15 -0000 Hi, please forward this if there are other parties or WGs that might have valuable knowledge in this. 1.5 years ago there was an email list created to discuss the issue of L1/L2 multicast packets having different delivery characteristics compared to unicast, on 802.11 and potentially other places. http://www.ieee802.org/11/email/stds-802-11/msg01838.html If you're interested in discussion on possible solution space for this, please consider subscribing. Possible outcomes is that IETF will re-design protocols to do less multicast, and/or new mechanisms would be proposed to make 802.11 (and other similar technologies) handle multicast better. There was a side meeting today with 10 people where this was discussed, and we're trying to restart this discussion, as it has been kind of stale the past year. Link to the email I sent to that list: https://mailarchive.ietf.org/arch/msg/mcast-wifi/muf8GqcTRzQubgHI-uc90aIC2YY -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 19 11:26:52 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 11:35:09 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775C01300CE; Wed, 19 Jul 2017 11:35:00 -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 GEKlHsBbmmhj; Wed, 19 Jul 2017 11:34:59 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209FC12711E; Wed, 19 Jul 2017 11:34:59 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 7B6DEC055A; Wed, 19 Jul 2017 20:34:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 438B31A00BC; Wed, 19 Jul 2017 20:34:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 20:34:56 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAKy8ppsRiqt+CEm7nfWl0LOnS6JbeSxQ Date: Wed, 19 Jul 2017 18:34:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F38C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> In-Reply-To: <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> 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_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:35:00 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lLA0KDQpBcyBtZW50aW9uZWQgaW4gYSBwcmV2aW91cyBtZXNzYWdlIGluIHRoaXMgdGhyZWFk LCBUQ1AtQU8gZXh0ZW5zaW9ucyAoNjk3OCkgdG8gcGFzcyBOQVRzIHdpbGwgYmUgcmVxdWlyZWQg b3RoZXJ3aXNlIFRDUC1BTyB3aWxsIGZhaWwgYmVjYXVzZSBvZjoNCg0KLSAgICBNYW5pcHVsYXRp bmcgbXVsdGlwbGUgYWRkcmVzc2VzDQoNCi0gICAgQXQgbGVhc3Qgb25lIG9mIHRoZSBzb3VyY2Ug SVAgYWRkcmVzc2VzIHdpbGwgYmUgcmV3cml0dGVuLg0KDQpUaGUgcHJveHkgZGVzaWduIGRvZXMg bm90IGluZHVjZSBhIG5ldyBpc3N1ZSBmb3IgVENQLUFPLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUg OiBJbnQtYXJlYSBbbWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUgSm9lIFRvdWNoDQpFbnZvecOpIDogbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDE4OjMzDQrD gCA6IE9saXZpZXIgQm9uYXZlbnR1cmU7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3Jn DQpPYmpldCA6IFJlOiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVu dCBvZiBNUFRDUA0KDQoNCg0KDQpPbiA3LzE5LzIwMTcgMTI6NDEgQU0sIE9saXZpZXIgQm9uYXZl bnR1cmUgd3JvdGU6DQotIElNTywgVENQIGFsd2F5cyBuZWVkcyB0byBiZSBhYmxlIHRvIGZhbGwg YmFjayAod2hpY2ggc2hvdWxkIGJlIHRydWUgbm93KQ0KDQpUaGlzIGlzIG5vdCBhIGNvbmNlcm4g d2l0aCB0aGUgcHJvcG9zZWQgZGVzaWduDQpQcm92ZSB0aGF0IGlzIHRydWUgaWYvd2hlbiBUQ1At QU8gaXMgZW5hYmxlZC4NCkpvZQ0K --_000_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQ1MDI3MjQ3MzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMzNzYwMDg4MCAtMTE1MDI3NjU5MiA2Nzg5NTI5 OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2 Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZS IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Sm9lLA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMgbWVudGlvbmVkIGluIGEgcHJldmlv dXMgbWVzc2FnZSBpbiB0aGlzIHRocmVhZCwgVENQLUFPIGV4dGVuc2lvbnMgKDY5NzgpIHRvIHBh c3MgTkFUcyB3aWxsIGJlIHJlcXVpcmVkIG90aGVyd2lzZSBUQ1AtQU8gd2lsbCBmYWlsIGJlY2F1 c2Ugb2Y6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWFuaXB1 bGF0aW5nIG11bHRpcGxlIGFkZHJlc3NlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkF0IGxlYXN0IG9uZSBvZiB0aGUgc291cmNlIElQIGFkZHJlc3NlcyB3aWxs IGJlIHJld3JpdHRlbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5UaGUgcHJveHkgZGVzaWduIGRvZXMgbm90IGluZHVjZSBhIG5ldyBpc3N1ZSBm b3IgVENQLUFPLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g SW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFy dCBkZTwvYj4gSm9lIFRvdWNoPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDE5 IGp1aWxsZXQgMjAxNyAxODozMzxicj4NCjxiPsOAJm5ic3A7OjwvYj4gT2xpdmllciBCb25hdmVu dHVyZTsgSW50ZXJuZXQgQXJlYTsgdHN2LWFyZWFAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNw Ozo8L2I+IFJlOiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVudCBv ZiBNUFRDUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gNy8xOS8yMDE3IDEyOjQxIEFNLCBPbGl2aWVyIEJvbmF2ZW50 dXJlIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBJTU8sIFRDUCBhbHdheXMgbmVlZHMgdG8gYmUgYWJsZSB0byBmYWxsIGJhY2sgKHdoaWNo IHNob3VsZCBiZSB0cnVlIG5vdykNCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhpcyBpcyBub3QgYSBjb25jZXJuIHdpdGggdGhlIHBy b3Bvc2VkIGRlc2lnbiA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlByb3ZlIHRoYXQgaXMgdHJ1ZSBpZi93aGVuIFRDUC1BTyBpcyBlbmFibGVkLjxi cj4NCkpvZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_-- From nobody Wed Jul 19 11:39:35 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07782131B9B; Wed, 19 Jul 2017 11:39:28 -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, 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, 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 XkPVu6wUoXsA; Wed, 19 Jul 2017 11:39:26 -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 7E5CD131B3E; Wed, 19 Jul 2017 11:39:26 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 2A4BFC055A; Wed, 19 Jul 2017 20:39:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id E3C6720071; Wed, 19 Jul 2017 20:39:24 +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; Wed, 19 Jul 2017 20:39:24 +0200 From: To: Joe Touch , Erik Kline CC: Tom Herbert , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAK0hByPMqBya7E2aRTfcerPMC6JbeiqA Date: Wed, 19 Jul 2017 18:39:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F3A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:39:28 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5l ZHVdDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDE4OjM2DQo+IMOAwqA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEVyaWsgS2xpbmUNCj4gQ2PCoDogVG9tIEhlcmJl cnQ7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbSW50 LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVudCBvZiBNUFRDUA0KPiANCj4g DQo+IA0KPiBPbiA3LzE5LzIwMTcgMTo0NiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSB3cm90ZToNCj4gPiBTbyBtYWtpbmcgdXNlIG9mIE1QVENQIHRvIGdyYWIgbW9yZSByZXNvdXJj ZXMgKHdoZW4gYXZhaWxhYmxlKSBvciB0bw0KPiBwcm92aWRlIGJldHRlciByZXNpbGllbmN5ICh3 aGVuIGEgbmV0d29yayBhdHRhY2htZW50IGlzIGxvc3QpIHdpbGwgcmVxdWlyZQ0KPiBib3RoIGVu ZHBvaW50cyB0byBiZSBNUFRDUC1jYXBhYmxlLg0KPiBUaGF0IGlzIGJvdGggY29ycmVjdCBhbmQg YXBwcm9wcmlhdGUuDQo+IA0KW01lZF0gT0suIA0KDQo+IERvaW5nIHRyaWNrcyB0byBkZW1vbnN0 cmF0ZSB0aGF0IGFuIGF0dGFja2VyIChpLmUuLCBzb21ldGhpbmcgdGhhdA0KPiBtb2RpZmllcyBU Q1Agc2VnbWVudHMgb24gcGF0aCkgY2FuIGRvIG90aGVyd2lzZSBzaG91bGQgbm90IGJlIGNvbnNp ZGVyZWQNCj4gYSB2aWFibGUgYWx0ZXJuYXRpdmUuDQoNCltNZWRdIFdlIGFyZSBkZWZpbmluZyBh biBhcHBsaWNhdGlvbiBwcm94eSB0aGF0IGFzc2lzdCB0aGUgdXNlciB0byBtYXhpbWl6ZSB0aGUg dXNlIG9mIGl0cyBhdmFpbGFibGUgbmV0d29yayByZXNvdXJjZXMuIFRoZSBwcm94eSByZWxpZXMg b24gSUVURiBkZWZpbmVkIEJDUHMgKGRlZmluZWQgYnkgYmVoYXZlIGFuZCB0c3Z3ZykgdG8gcmVs YXkgVENQIHBhY2tldHMuIA0KDQo+IEpvZQ0K From nobody Wed Jul 19 11:43:29 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564D6127180; Wed, 19 Jul 2017 11:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 FJMYxFPhfnyW; Wed, 19 Jul 2017 11:43:19 -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 CA1511267BB; Wed, 19 Jul 2017 11:43:18 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 6171AC051F; Wed, 19 Jul 2017 20:43:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 2F83B20071; Wed, 19 Jul 2017 20:43:17 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 20:43:16 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAK4x0P3r/ocVwkudgYRoNLkuu6Jbe2Nw Date: Wed, 19 Jul 2017 18:43:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:43:20 -0000 Re-,=20 I don't understand your argument here, especially because you are the one w= ho proposed me the following (check mptcp archives, April 20, 2017) which w= e endorsed in the latest version of the specification: "If that were the case, you'd simply be defining a new application service = and asking for a TCP port number." Are you saying that you suggested us a bad design choice? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Joe Touc= h > Envoy=E9=A0: mercredi 19 juillet 2017 18:43 > =C0=A0: Olivier Bonaventure; Internet Area; tsv-area@ietf.org > Objet=A0: Re: [Int-area] Middleboxes to aid the deployment of MPTCP >=20 >=20 >=20 > On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > > Joe, > > > >> - but I remain concerned with "injection piggybacking" > > > > To which section of the draft are you referring to ? > It starts in the arch discussion in Sec 2: >=20 > As shown in Figure 3, the Converter places its supplied information > inside the handshake packets. >=20 > That's what I refer to as "injection piggybacking" >=20 > With TCP, the Converter protocol places the destination address and > port number of the final Server in the payload of the SYN. >=20 > And that is the part that violates RFC793 semantics when that SYN reaches > the final destination rather than the server-side proxy. >=20 > To be clear, I'm not interested in further trying to "fix" this mechanism > so it can work. It can't and it shouldn't IMO. Let's use our cycles for > more productive things. >=20 > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jul 19 12:23:35 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:37:37 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F2E1242F7 for ; Wed, 19 Jul 2017 12:37:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tessares-net.20150623.gappssmtp.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 4DyrrhDWbk5a for ; Wed, 19 Jul 2017 12:37:34 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 AFB8F126DC2 for ; Wed, 19 Jul 2017 12:37:33 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id y43so62495181wrd.3 for ; Wed, 19 Jul 2017 12:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=vPqMfgVCxfY8vHbvyYLT82fAhudiThTCtJG/VzXmjP0=; b=ejgtwwsmZYhOwL84Xf01chTfOpbFSM4N/0VKgGEsx3XXfuANmnr7VYof3U/GRU6p1M ipBK6U1u94Pz8H/xbYRLqmUrP3JEvemnp9bjxomrZWY+S4aJL3K192wKj4UAEeB79Itb 7iG2IeQ6/kHyupdRFVQ9y+7CKQtbJjkj6T/3IjpgaTMlbtvWW837MKvCKwdPtSyEPbpQ tpU5n2DlOOt8JvmLpD0/F0EW5UG64mw0wVD/lQAMzcbNIS7o5u4sOUJYJ20d3kGPUaf9 83Pqn77AGemZFY6JSINtjhnVgttK9Rv7Le4nJ39IWanctfWxLshtg+H+ULA6zMjLAbh4 CzIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vPqMfgVCxfY8vHbvyYLT82fAhudiThTCtJG/VzXmjP0=; b=kSEPxh1NUXTSHUxdJfOEBvgkJBXGg6zu7fWnJ4tZNjp/0Syzo4yPRSn5XhM4ceInKy 0glGaJYJ1OBJJEZ4hy/WRnGILbEK7GlgUBYdifX0ou2xZO4+PENdtr3WAZDnw5y6W5ZK p+AAXsmTCsIOg04CL+9eMDwVM9oLRNNfuhJbvCI9CHKMzas2QTtpCYY7hZ+UCZVpp4p7 AXZcXjA49ug/WZOAeZkPlBSh0IFTzDPfBvfb4JPDGKb2e1nZf8pXM5P2ihQ45F3F7ldP GSOEXl18f65EksZt5+rOzurxEtoW9at5+3QP1KeTPuuvNiM0FG9LpAsoFxEEkG4AxYka fBqA== X-Gm-Message-State: AIVw110WXhRLffrNiXG5DSG1vsDbmPWdOMkWI5yg0LYEoZ6iBFmYln6f EOjhrKTweoXZBDxqQRlXs8ck90n9FtVpoRfXinPk3GgugVv0mXeg7oI91J02x9T4skJox3p+1Tg = X-Received: by 10.223.132.133 with SMTP id 5mr4867209wrg.132.1500493052218; Wed, 19 Jul 2017 12:37:32 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id u1sm1002921wrd.73.2017.07.19.12.37.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 12:37:16 -0700 (PDT) To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> From: Olivier Bonaventure Message-ID: Date: Wed, 19 Jul 2017 21:37:16 +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: <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:37:36 -0000 On 19/07/17 18:32, Joe Touch wrote: > > > On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>> - IMO, TCP always needs to be able to fall back (which should be true >>> now) >> >> This is not a concern with the proposed design > Prove that is true if/when TCP-AO is enabled. I don't think that TCP-AO is a use case for the proposed converters. If an application requests TCP-AO, then it indicates that it expects authentication until the server. I do not see a benefit of having authentication on a subset of the path. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 12:40:11 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EFF129AF6 for ; Wed, 19 Jul 2017 12:40:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tessares-net.20150623.gappssmtp.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 RhXr8g4PqZEH for ; Wed, 19 Jul 2017 12:40: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 886CD126DC2 for ; Wed, 19 Jul 2017 12:40:07 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id v105so32372831wrb.0 for ; Wed, 19 Jul 2017 12:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=nsZ+ULuz1U1kJ33q2amkvJMg5X6gmoPOu8FdJn5U2LY=; b=wATenLkTT+ty8apghpOSRWE33xBrUU7t1fLzup82CK38ntEt+sBiHWtsH2WwQ42Gk3 zHHIX6FWYMqaKV1VnwwmyAB8K49b/xhLfndoNwkn2PDyTOYg+/aAtjeCbCB+Whay6UYW 2SqdIcHgsvLkSnb2f+xpv/KNqIjFsnoUP5mcZSvQVjSVHcRqrORKQ5AgFD4n6yoTQ+dn 0sc9cH2GJMDRZV4Q1SmaHG7j6rCuSsTzUNnqQL8orXComN4wn4g9lJrgTelDc67UjsTG abhRyH1oxSLeooWsBvN2INTEsVmK9+EVcROvB9PLGdnPEd+Dl5WL+6V6kcYNNQNOQl3k RxqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=nsZ+ULuz1U1kJ33q2amkvJMg5X6gmoPOu8FdJn5U2LY=; b=mdLGWtUOp59+xodfY7jufEM1qzh44oajS3ShKrWLk+J2sTgOQf+Q1bd3OB1xML3XO4 Sa5SXyk7qDchlVuZwFFMVuXvOUJWldh2KyO7yTaCvTmfKSqFEKKp838RpCv7zPi/Fe9d g5jjCidDqFmNY0lIZM0KTt4NyQxTiHeY+1Sb+lfxMsciBQf4SiZr4Z+v9NbSepcPEFT0 2rrGhFWFXldGv7Pm7nNxpkkg0C3KRuXmX4sWufE23vYfyWP2LF6p8z6UY0pEcpgli8/n ZY93Y9iItyUDu1dZlPbD2GTtzQBfa183fHudZTG3vSRHQSJ+hwk4pQk4bIuwOQVEaBsH IB0A== X-Gm-Message-State: AIVw112zGx1xI6M9GTh/4sAm9Iw8eC7dCUr1/ZaXUxH1VP43L1dXzXdf BGl5FDwzXKIvQOHbtpzs4D02lg0bEOz5pbWC+bnq382+y99ZiY8BtpWM/vreuy4ZFdbO3A== X-Received: by 10.223.171.200 with SMTP id s66mr3990025wrc.38.1500493206072; Wed, 19 Jul 2017 12:40:06 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id u66sm1481462wrb.77.2017.07.19.12.40.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 12:40:05 -0700 (PDT) To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> From: Olivier Bonaventure Message-ID: <00d13338-0471-2830-d659-7c28c784671f@tessares.net> Date: Wed, 19 Jul 2017 21:40: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: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:40:10 -0000 Joe, > > To be clear, I'm not interested in further trying to "fix" this mechanism so it can work. It can't and it shouldn't IMO. Let's use our cycles for more productive things. I agree that we disagree on this point. As I said in the draft, I would like to thank you once again for your comments that have been very helpful in improving the draft compared to earlier iterations. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 12:41:27 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:41:21 -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 12:43:49 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563CE126DC2; Wed, 19 Jul 2017 12:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 LIOp5AhXftEM; Wed, 19 Jul 2017 12:43:46 -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 3C91D128A32; Wed, 19 Jul 2017 12:43:46 -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 v6JJhMlL008389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:43:23 -0700 (PDT) To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F38C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 12:43:21 -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: <787AE7BB302AE849A7480A190F8B93300A00F38C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------1A07C61261265D9BBD079C2D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:43:47 -0000 This is a multi-part message in MIME format. --------------1A07C61261265D9BBD079C2D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 11:34 AM, mohamed.boucadair@orange.com wrote: > > Joe, > > > > As mentioned in a previous message in this thread, TCP-AO extensions > (6978) to pass NATs will be required otherwise TCP-AO will fail > because of: > > - Manipulating multiple addresses > > - At least one of the source IP addresses will be rewritten. > TCP-AO-NAT is experimental. It also has nothing to do with whether the TCP options are covered - that's determined by the MKT on a per-connection basis, and is opaque to on-path devices. An on-path device that manipulates TCP options would break TCP-AO-NAT if the MKT covers the options. Joe --------------1A07C61261265D9BBD079C2D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



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

Joe,

 

As mentioned in a previous message in this thread, TCP-AO extensions (6978) to pass NATs will be required otherwise TCP-AO will fail because of:

-    Manipulating multiple addresses

-    At least one of the source IP addresses will be rewritten.

TCP-AO-NAT is experimental.

It also has nothing to do with whether the TCP options are covered - that's determined by the MKT on a per-connection basis, and is opaque to on-path devices.

An on-path device that manipulates TCP options would break TCP-AO-NAT if the MKT covers the options.

Joe
--------------1A07C61261265D9BBD079C2D-- From nobody Wed Jul 19 12:46:05 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85369131468; Wed, 19 Jul 2017 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 BGANJt30ejID; Wed, 19 Jul 2017 12:45:54 -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 5058C126DC2; Wed, 19 Jul 2017 12:45:54 -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 v6JJj3At008865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:45:04 -0700 (PDT) To: mohamed.boucadair@orange.com, Erik Kline Cc: Tom Herbert , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00F3A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 12:45:01 -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: <787AE7BB302AE849A7480A190F8B93300A00F3A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------62814551B0BA39CB381CD993" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:45:56 -0000 This is a multi-part message in MIME format. --------------62814551B0BA39CB381CD993 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 11:39 AM, mohamed.boucadair@orange.com wrote: >> Doing tricks to demonstrate that an attacker (i.e., something that >> modifies TCP segments on path) can do otherwise should not be considered >> a viable alternative. > [Med] We are defining an application proxy that assist the user to maximize the use of its available network resources. The proxy relies on IETF defined BCPs (defined by behave and tsvwg) to relay TCP packets. Application proxies don't relay TCP segments. They don't even see TCP segments. And they can't work unless the client opens a connection to the proxy; if the client opens a connection to the server, then intercepting and modifying the TCP segments in-flight is called an attack on TCP. Joe --------------62814551B0BA39CB381CD993 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/19/2017 11:39 AM, mohamed.boucadair@orange.com wrote:
Doing tricks to demonstrate that an attacker (i.e., something that
modifies TCP segments on path) can do otherwise should not be considered
a viable alternative.

[Med] We are defining an application proxy that assist the user to maximize the use of its available network resources. The proxy relies on IETF defined BCPs (defined by behave and tsvwg) to relay TCP packets.
Application proxies don't relay TCP segments. They don't even see TCP segments.

And they can't work unless the client opens a connection to the proxy; if the client opens a connection to the server, then intercepting and modifying the TCP segments in-flight is called an attack on TCP.

Joe
--------------62814551B0BA39CB381CD993-- From nobody Wed Jul 19 12:46:27 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DCD126DC2; Wed, 19 Jul 2017 12:46:21 -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, RCVD_IN_DNSWL_HI=-5, 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 jf965BnTbTvj; Wed, 19 Jul 2017 12:46:19 -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 6C29D131BBE; Wed, 19 Jul 2017 12:46:16 -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 v6JJjwJV009101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:45:59 -0700 (PDT) To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> Date: Wed, 19 Jul 2017 12:45:57 -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: <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:46:21 -0000 On 7/19/2017 11:43 AM, mohamed.boucadair@orange.com wrote: > I don't understand your argument here, especially because you are the one who proposed me the following (check mptcp archives, April 20, 2017) which we endorsed in the latest version of the specification: > > "If that were the case, you'd simply be defining a new application service and asking for a TCP port number." > > Are you saying that you suggested us a bad design choice? The text I saw talks about SYN packets. If this is at the application layer - and doesn't hijack TCP connections to other IP addresses - then it's fine, but then the ID is very badly in need of revision. I'm working off the text I saw. Joe From nobody Wed Jul 19 12:47:48 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6186C126DC2; Wed, 19 Jul 2017 12:47:47 -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 T4-2_iB2a97c; Wed, 19 Jul 2017 12:47:46 -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 646451200FC; Wed, 19 Jul 2017 12:47:46 -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 v6JJlRi0009848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:47:28 -0700 (PDT) To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> From: Joe Touch Message-ID: <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> Date: Wed, 19 Jul 2017 12:47:25 -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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:47:47 -0000 On 7/19/2017 12:37 PM, Olivier Bonaventure wrote: > On 19/07/17 18:32, Joe Touch wrote: >> >> >> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>>> - IMO, TCP always needs to be able to fall back (which should be >>>> true now) >>> >>> This is not a concern with the proposed design >> Prove that is true if/when TCP-AO is enabled. > > I don't think that TCP-AO is a use case for the proposed converters. You don't get to decide that. If you use TCP, then TCP-AO could be enabled on the client. Joe From nobody Wed Jul 19 12:52:02 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F854131468 for ; Wed, 19 Jul 2017 12:52:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 tWREuGm0P-q3 for ; Wed, 19 Jul 2017 12:51:59 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 739701200FC for ; Wed, 19 Jul 2017 12:51:59 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id w191so8449483wmw.1 for ; Wed, 19 Jul 2017 12:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=H7DT39MxiQSwehgq/oJNw72QDXszrZCPClqOC8kM2Y8=; b=ZSed486LibhlRTGC1zXudF2DcY9hDNc5wg9kyAkNQfFRkptfiSZNIIjw4NHgnwJt3b GDnnNLulqWlp1OEr9LpJ7RUH8CmfpU8Eh4VXZ4nEXEFKzioSuwGehDIsLsze0p5kfi74 mRAqf8xzvZDxV5+/isqFn8w5dwhyKQyrT+L6JKI4gUvqQGTvrlCvG7jdPoJmZvwsNLaH efwEJVTKmeXDxisHh7/SORGxB377KtQ/u6qM4UHUcBJn+HdC3m7mjOd/O6RWTm1a6kmS 1vro2//fzDZD98yuqBLMXqHjFyvlnf32wByS+d97zcS12kiMbcmmo6dfmBGCIYgTMre6 VWyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=H7DT39MxiQSwehgq/oJNw72QDXszrZCPClqOC8kM2Y8=; b=m5FIwLD3KzDclFD50tvUMXtsko88gF/B+Zae4KdKHHepKsnlKfHTGi/NotWj8u5tL7 Czwip4N4wurcygdUEuboeAMpTus6q5y+jeXon7G/0jcDcq7MV0TELFEyc4kNwr/SMhAG tlDlMj4meO1M0b/Y2zciAJqO2526EDEeCQvOEcG1EUPptrOIi9EjkvQuMbB6iGqKCqkx TvRUR7UFbJNz080yp0sf2whCi6xmUkpvqtHa37XzVYgbgHhlqwUY6R1+ZE41crUh10bJ gXSxZ1Q10WV/7N25CDI/5G5VouEMz6lh7m+X2hXxckV0bhXe1GMVwLLPfZMWJoF46+Gk 6IfQ== X-Gm-Message-State: AIVw112fBoSohfGMik1raFGGr+G6W8d7iixrCzKAqJErxOoUCdCtqkMj uhW9vYZ7LcWRH6swOBuypkstVpXqgM8UUWUYpBhmuRCYW4bj8xuP5ogklm7ZJc+N8Ev4rqj/YCE = X-Received: by 10.28.95.137 with SMTP id t131mr723996wmb.102.1500493917962; Wed, 19 Jul 2017 12:51:57 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id y84sm651310wmg.12.2017.07.19.12.51.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 12:51:57 -0700 (PDT) To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> From: Olivier Bonaventure Message-ID: Date: Wed, 19 Jul 2017 21:51:57 +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: <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:52:01 -0000 Joe, >>> >>> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>>>> - IMO, TCP always needs to be able to fall back (which should be >>>>> true now) >>>> >>>> This is not a concern with the proposed design >>> Prove that is true if/when TCP-AO is enabled. >> >> I don't think that TCP-AO is a use case for the proposed converters. > > You don't get to decide that. If you use TCP, then TCP-AO could be > enabled on the client. The converter is not intended to be used for all TCP connections. In the draft we explain how an MPTCP endpoint can bypass the converter if the destination server supports MPTCP. For TCP-AO, my recommendation would be that the default policy of the client would be to never use the converter if TCP-AO is requested by the application. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 12:58:26 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF26129789; Wed, 19 Jul 2017 12:58:18 -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 KUHH0gUxysP1; Wed, 19 Jul 2017 12:58:17 -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 8195D120724; Wed, 19 Jul 2017 12:58:17 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJvlvm015068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:57:47 -0700 (PDT) To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> From: Joe Touch Message-ID: <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> Date: Wed, 19 Jul 2017 12:57: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: 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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:58:18 -0000 On 7/19/2017 12:51 PM, Olivier Bonaventure wrote: > Joe, >>>> >>>> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>>>>> - IMO, TCP always needs to be able to fall back (which should be >>>>>> true now) >>>>> >>>>> This is not a concern with the proposed design >>>> Prove that is true if/when TCP-AO is enabled. >>> >>> I don't think that TCP-AO is a use case for the proposed converters. >> >> You don't get to decide that. If you use TCP, then TCP-AO could be >> enabled on the client. > > The converter is not intended to be used for all TCP connections. In > the draft we explain how an MPTCP endpoint can bypass the converter if > the destination server supports MPTCP. For TCP-AO, my recommendation > would be that the default policy of the client would be to never use > the converter if TCP-AO is requested by the application. How do you know you're using the converter? Is the initial connection to that converter? Or does the converter hijack (the latter is the implication of the text, AFAICT). Joe From nobody Wed Jul 19 17:32:50 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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:23 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 nobody Wed Jul 19 22:39:08 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20DE12783A; Wed, 19 Jul 2017 22:39:06 -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, FREEMAIL_FROM=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 k5m1KJ2MEoQH; Wed, 19 Jul 2017 22:39:05 -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 7A732126B6E; Wed, 19 Jul 2017 22:39:05 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id CBF5640522; Thu, 20 Jul 2017 07:39:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7ECBA1C00B1; Thu, 20 Jul 2017 07:39:03 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 07:39:03 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAMej/WwR69lLRUy6PvQRGBZ9W6JcMrmw Date: Thu, 20 Jul 2017 05:39:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> In-Reply-To: <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 05:39:07 -0000 SGkgSm9lLCANCg0KVGhlIHRleHQgY2FuIGFsd2F5cyBiZSB3b3JrZWQgb3V0LiBUaGlzIGlzIG5v dCBhbiBJRVRGIExDIDopDQoNClRoZSBtYWluIHBvaW50IGlzIHRoYXQgd2UgYXJlIGZvbGxvd2lu ZyB5b3VyIHN1Z2dlc3Rpb24gdG8gZGVmaW5lIHRoZSBzb2x1dGlvbiBhcyBhbiBhcHBsaWNhdGlv biBwcm94eSB1c2luZyBhIGRlZGljYXRlZCBwb3J0IG51bWJlci4gDQoNCkNoZWVycywNCk1lZA0K DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0 bzp0b3VjaEBpc2kuZWR1XQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDE5IGp1aWxsZXQgMjAxNyAy MTo0Ng0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBPbGl2aWVyIEJvbmF2ZW50 dXJlOyBJbnRlcm5ldCBBcmVhOyB0c3YtDQo+IGFyZWFAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6 IFtJbnQtYXJlYV0gTWlkZGxlYm94ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQDQo+ IA0KPiANCj4gDQo+IE9uIDcvMTkvMjAxNyAxMTo0MyBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSB3cm90ZToNCj4gPiBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBhcmd1bWVudCBoZXJl LCBlc3BlY2lhbGx5IGJlY2F1c2UgeW91IGFyZSB0aGUNCj4gb25lIHdobyBwcm9wb3NlZCBtZSB0 aGUgZm9sbG93aW5nIChjaGVjayBtcHRjcCBhcmNoaXZlcywgQXByaWwgMjAsIDIwMTcpDQo+IHdo aWNoIHdlIGVuZG9yc2VkIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgc3BlY2lmaWNhdGlv bjoNCj4gPg0KPiA+ICJJZiB0aGF0IHdlcmUgdGhlIGNhc2UsIHlvdSdkIHNpbXBseSBiZSBkZWZp bmluZyBhIG5ldyBhcHBsaWNhdGlvbg0KPiBzZXJ2aWNlIGFuZCBhc2tpbmcgZm9yIGEgVENQIHBv cnQgbnVtYmVyLiINCj4gPg0KPiA+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IHN1Z2dlc3RlZCB1 cyBhIGJhZCBkZXNpZ24gY2hvaWNlPw0KPiBUaGUgdGV4dCBJIHNhdyB0YWxrcyBhYm91dCBTWU4g cGFja2V0cy4NCj4gDQo+IElmIHRoaXMgaXMgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIC0gYW5k IGRvZXNuJ3QgaGlqYWNrIFRDUCBjb25uZWN0aW9ucw0KPiB0byBvdGhlciBJUCBhZGRyZXNzZXMg LSB0aGVuIGl0J3MgZmluZSwgYnV0IHRoZW4gdGhlIElEIGlzIHZlcnkgYmFkbHkgaW4NCj4gbmVl ZCBvZiByZXZpc2lvbi4gSSdtIHdvcmtpbmcgb2ZmIHRoZSB0ZXh0IEkgc2F3Lg0KPiANCj4gSm9l DQoNCg== From nobody Wed Jul 19 22:43:56 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF01124D85; Wed, 19 Jul 2017 22:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 oZvvwO5G3uKn; Wed, 19 Jul 2017 22:43:52 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE82124217; Wed, 19 Jul 2017 22:43:52 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id AF329C0503; Thu, 20 Jul 2017 07:43:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 76D6F1A00C4; Thu, 20 Jul 2017 07:43:50 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 07:43:50 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAMZ+/WwR69lLRUy6PvQRGBZ9W6JbbJyAgAABRICAAAGgAIAAw/oQ Date: Thu, 20 Jul 2017 05:43:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F6BD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> In-Reply-To: <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 05:43:54 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Joe Touc= h > Envoy=E9=A0: mercredi 19 juillet 2017 21:58 > =C0=A0: Olivier Bonaventure; Internet Area; tsv-area@ietf.org > Objet=A0: Re: [Int-area] Middleboxes to aid the deployment of MPTCP >=20 >=20 >=20 > On 7/19/2017 12:51 PM, Olivier Bonaventure wrote: > > Joe, > >>>> > >>>> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > >>>>>> - IMO, TCP always needs to be able to fall back (which should be > >>>>>> true now) > >>>>> > >>>>> This is not a concern with the proposed design > >>>> Prove that is true if/when TCP-AO is enabled. > >>> > >>> I don't think that TCP-AO is a use case for the proposed converters. > >> > >> You don't get to decide that. If you use TCP, then TCP-AO could be > >> enabled on the client. > > > > The converter is not intended to be used for all TCP connections. In > > the draft we explain how an MPTCP endpoint can bypass the converter if > > the destination server supports MPTCP. For TCP-AO, my recommendation > > would be that the default policy of the client would be to never use > > the converter if TCP-AO is requested by the application. >=20 > How do you know you're using the converter? [Med] The converter is explicilty configured (e.g., locally configured or y= means of https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-07).=20 Is the initial connection to > that converter? [Med] When a connection is eligible to network-assisted MPTCP, the first su= bflow will be established via the converter. Subsequent flows will be estab= lished with that proxy involved. Packets are sent with destination IP addre= ss set to the one of the converter.=20 Or does the converter hijack (the latter is the > implication of the text, AFAICT). >=20 > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jul 19 23:19:10 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041C81289B0 for ; Wed, 19 Jul 2017 23:19:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 EgrzQp3Vh0EA for ; Wed, 19 Jul 2017 23:19:06 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 65A28124217 for ; Wed, 19 Jul 2017 23:19:06 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id w126so15419213wme.0 for ; Wed, 19 Jul 2017 23:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=apj3CGXPkH6i1uOYB8ogAiPiobAisoUrp1NWOzGVzXM=; b=K3wUBf6N9281U9nu0Q5CgT/335I9AtZe/mVQanmpMIZu9dodAkGDEr7y9DQAjMwO7k ANIv7nMge0xWPkUJtih0MA4Apf/ZoA0cHWq/MOVgspDcCeqtRUPi5BOcWASMjgHz5jFc oHgXLbKBN4rKdVgM8UiiVGO/S413Ltwme4k1jAIH4IyYhSF3bF1/qHYU8I5TcNB/dLe2 btXTzw4nVef36pzV+jA1QVaEmtdEBXvLMwj7RlSUoxsZtPpfd03++ZuDYmsT71JMplFX FiDtj8GLP/4oLtbhbne4oQRaR/oyn1Uv3iFNE0h+d6w+nluK9FjBc3u3riruxa7Y1yhK uR7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=apj3CGXPkH6i1uOYB8ogAiPiobAisoUrp1NWOzGVzXM=; b=gEApRKhhjPIK5/8yYmyTenXFlYXkWgHqWVSqdgsJZ2ZdwzmJd0YhPgd8OYc3EtoabM KBHiRqOztmk8xPiNlHNR89wx6J/DyFQvdy2AAOIjQLXBk6dFvd/BxK5tmN8eScLlhq/Z trybmPfjwrTWl601FxLZllCK5LqQS4GIvamFViGjvAk+GIbHR/hWCiAu1Gr+F2jYXPhw 7SjCawMw0uMpVPVhbHPwmTKPWIEKlT6rs0WsXOfXy/rDoMzohAZmigs+PCMxOYKUn2UJ w6fzu4UQaUAjtaNzWy9MYEPCeqhaBvp/I1MHPELTIUHkrNZgVRTGOz7zgiz/T9+o5CFZ OOYw== X-Gm-Message-State: AIVw1130aAqj1Q0ApoW5xBfJa2IYZduj8b4ZhHlgqSfnu6p1SPqi1BWF xU5YujKIRs5ELt/AVAM4WvDVF9/2Gn+0pH75pPTHlImwuIMtQEsUe4JfHiWz5cSUSPHDZoRnA6M = X-Received: by 10.28.212.7 with SMTP id l7mr1523103wmg.31.1500531544928; Wed, 19 Jul 2017 23:19:04 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id j137sm2270634wmf.43.2017.07.19.23.19.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 23:19:04 -0700 (PDT) To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> From: Olivier Bonaventure Message-ID: <3bf7fffa-c267-5d67-c124-01fa52ebafdc@tessares.net> Date: Thu, 20 Jul 2017 08:19:03 +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: <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:19:08 -0000 Joe, >>>> >>>> I don't think that TCP-AO is a use case for the proposed converters. >>> >>> You don't get to decide that. If you use TCP, then TCP-AO could be >>> enabled on the client. >> >> The converter is not intended to be used for all TCP connections. In >> the draft we explain how an MPTCP endpoint can bypass the converter if >> the destination server supports MPTCP. For TCP-AO, my recommendation >> would be that the default policy of the client would be to never use >> the converter if TCP-AO is requested by the application. > > How do you know you're using the converter? Is the initial connection to > that converter? Or does the converter hijack (the latter is the > implication of the text, AFAICT). Consider a simple implementation using LD_PRELOAD to overload the connect system call on Linux. When the application issues connect, it has already set the required socket options that apply for this new connection. The converter implementation uses the destination address of the connect system call to create the TLV message and sets the TFO socket option to send it during its own connect with the converter. If the application had requested TFO, then the converter library simply uses the regular connect call and everything is fine. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Thu Jul 20 00:22:31 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 01:00:36 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA80126B72 for ; Thu, 20 Jul 2017 01:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=microsoft.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 rvN4ISkFxdO2 for ; Thu, 20 Jul 2017 01:00:32 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.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 223F1126557 for ; Thu, 20 Jul 2017 01:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6s/SaN77xAgmTZcOL+Q756ZQa0BCHHYpwgnMYS5FQ2A=; b=jtKQMTWh1sP8iyxfj3FQ5DjzfoBZKAZQycerGMna/4B9EXZlAp7+QK5i+49uWgFfm5y0vnvT5Up0J7UzkdbYYu+gDOBOKdyrCjEUoXSUmDlgHADoPta86la78uYde//PSo4q+2S4Z8yi/WNuZMgXc/0/9JXhiqLr0OyAYhsukyA= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0640.namprd21.prod.outlook.com (10.175.141.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Thu, 20 Jul 2017 08:00:29 +0000 Received: from MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) by MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) with mapi id 15.01.1282.008; Thu, 20 Jul 2017 08:00:29 +0000 From: Dave Thaler To: Ron Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Thread-Index: AdL7Je43Z0B6UbQRQ8OzttnbbdH15QGByLdQ Date: Thu, 20 Jul 2017 08:00:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:128:bce4:a630:ff7d:7258] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0640; 7:HyKyRLeKtxPgbmvTf2k1rNoS2E9P51CP9Oicait5i+/EodpHVil38gFJKV8HXeLYQeG8Y8b7wgu+DfLXhciYufB3vEw5z3tk9XbXCYhq7Iy1wSpBIr34oBnmWcpaTY2R1NwezyPs5RlsgOLxRMSVHOHfsGjzJqlfX18pyH+jPnANuEDZyVKV8X8PLqIv/IXvkqI4E9Zm8Sj+rVt3sGjvD8ApOIgbqezxa6v+p/aJVfaOC1S83+Pcz1XSpJzH0u5vlHMTOKYOmFYGeZ6d1gTYvs0Lo5lleTdFZn9UQrwH1/YtXIKFsZR6v3KUDipc60U3/tCldxngyMNZxVJM8lWrxJWAn9BAsJ5Ocd1+0DaNlwS5o+R0NrzhqKCOjMR5V5NwHP6LLa7q26vYX1omtzKuaqCkMYiNjySaVvsdY8ElWaxERRW2f6yUUDfe8We1tRTs3wYkk45enPzlSJuzLsf7GGfTiqQzDPGOiVT4RlsQIQSweMxdn2rxv04ePaA0IVaB+5zp6hiVyDLWr78OLA0rNt8FSDGrsS4pTmlWQfNtjo0tDPlQVujiSSPEub7W5dZFGKL0GnJ6CGxwcIiqBzp+2wC08MS9asWPCxuJRwkla3eYodVecLzkFbF7kjr3mjDBEmKFg78GW0OVisV5njwJ9rvWCSyHaNg07Gi1K/7naiN801mMn/Z6TDWt7WZ8LaTczuWsLO3GN3klJUmEHR586fJsL/taBIWsaOyr3fIqa8Xotg/8sQCxszIaqGZYz7eSeovuxAkaEUOWKIipQqImO+bk+Z6cZ1hyIDOgwcl2RxyY5WOt6TzMmbUUt6CFa4Ov x-ms-office365-filtering-correlation-id: 824a3954-3f2f-47d3-0740-08d4cf456341 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0640; x-ms-traffictypediagnostic: MWHPR21MB0640: x-exchange-antispam-report-test: UriScan:(236129657087228)(189930954265078)(48057245064654)(148574349560750)(219752817060721)(164587983369549)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0640; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0640; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39860400002)(39450400003)(39850400002)(39410400002)(39840400002)(13464003)(51914003)(377454003)(76176999)(2950100002)(8676002)(81166006)(10090500001)(25786009)(54356999)(50986999)(86362001)(8936002)(7736002)(10290500003)(74316002)(2900100001)(6306002)(230783001)(77096006)(5005710100001)(33656002)(53546010)(14454004)(9686003)(2501003)(53936002)(966005)(478600001)(189998001)(99286003)(7696004)(305945005)(8666007)(5660300001)(55016002)(6436002)(6506006)(3660700001)(3280700002)(38730400002)(6246003)(2906002)(6116002)(102836003)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0640; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 08:00:28.8481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0640 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:00:35 -0000 Section 2.1: > If the Interface Identification Object identifies the probed > interface by name, the object payload contains the human-readable > interface name. The interface name SHOULD be the full MIB-II ifName, > if less than 255 octets, or the first 255 octets of the ifName, if > the ifName is longer. The interface name MAY be some other human- > meaningful name of the interface. The interface name MUST be > represented in the UTF-8 charset [RFC3629] using the Default Language > [RFC2277]. As I mentioned during the meeting today, the above text has a bunch of prob= lems as written: 1) Saying UTF-8 is not sufficient, you need to discuss normalization form, = etc. See RFC 7564. You can't just copy a paragraph from some other spec, you have to dete= rmine what properties you actually want, but the Precis WG defined a number of re= usable classes. There are precis experts that can help the WG determine what profile i= s most appropriate. 2) You can't truncate a UTF-8 string at 255 octets and still have a valid U= TF-8 string, since characters can span multiple octets and you might truncate in the midd= le and get a partial character, which leaves you with an invalid string. 3) The length restriction is only part of the SHOULD. Does that mean that = if you follow the MAY, there is no such length restriction? Dave -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Wednesday, July 12, 2017 5:46 PM To: int-area@ietf.org; Carlos Pignataro (cpignata) Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Hi Carlos, Thanks for the review. Inline, below. Ron >=20 > Hi, Ron, Authors, >=20 > As I was reading over draft-ietf-intarea-probe-00, and wanted to share=20 > a couple of observations for your consideration. >=20 >=20 > * Have you considered the tradeoff of defining new ICMP Types versus > extending existing ICMP Types? If using existing ICMPv6 Echo=20 > Request/Reply and extending them instead of defining brand new types,=20 > the backwards interoperability achieved is higher [ [RB ] I thought about extending the existing ICMP messages, but decided against i= t for backward compatibility reasons. Both existing messages end with a var= iable length data field. This field begins at a fixed position, but doesn't= have a length attribute of its own. Therefore, we can't add any more field= s after it. There may be ways to dance around the problem, but they all involve redefin= ing the existing field in the existing message. > * Have you considered using other protocols as well in addition to IC= MP for > the PROBE message, which can elicit ICMP errors or responses with=20 > appropriate extensions? In particular UDP is a protocol much used and=20 > desired for probes. >=20 [RB ] ICMP and UDP would both work. I chose ICMP because ICMP already supports le= gacy echo/echo reply. But I'm not feeling religious about this. In the final analysis, I am willing to use whatever protocol the WG prefers= . > These two points actually reminded me of=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools > .ietf.org%2Fhtml%2Fdraft-&data=3D02%7C01%7Cdthaler%40microsoft.com%7C4f6 > 74c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7 > C0%7C636354711627226706&sdata=3DG5vSnrYbaFBryTvzh5pn3AVaJz3hURtt1PJYLVah > rnM%3D&reserved=3D0 > shen-traceroute-ping-ext-04 (and the ICMP-only predecessor draft-shen- > udp-traceroute-ext-01) that defines a probe extension applied to ICMP=20 > Echo Request and UDP, and RFC 4884 extensions to responses. That=20 > approach seems somewhat more generic. >=20 > Additionally, I was also reminded of the ICMP AUP at RFC 7279, it=20 > would be useful to map against that doc to show how this is (as it is=20 > the case) a really good use of ICMP. [RB ] Section 3 of 7279 suggests that ICMP can be used for diagnostics. It calls = out PING as being an acceptable use. But again, I don't feel religious abou= t this. The protocol works over UDP just as well as it works over ICMP. = Ron >=20 > Thanks! >=20 > ? Carlos. >=20 >=20 ******************************* _______________________________________________ Int-area mailing list Int-area@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fint-area&data=3D02%7C01%7Cdthaler%40microsoft.c= om%7C4f674c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636354711627226706&sdata=3DxSDwSJAGRkBNGO9IO9FfArdLkywAnaHf8AZ5OWcs= Dsk%3D&reserved=3D0 From nobody Thu Jul 20 01:03:23 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA21129562 for ; Thu, 20 Jul 2017 01:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=microsoft.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 iGrgL-WeEuLH for ; Thu, 20 Jul 2017 01:03:20 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA46126B72 for ; Thu, 20 Jul 2017 01:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bw9tJ/hKYb7i/GyO9X36y0CDy8XrOEf9WTaE2whISCQ=; b=jlisL8hlE5vtwf1qylAkWR7o/lrz1n+JioFPfG0NiU0QYfEhU3OR46ZJolgdjTgjcrER4l3hbP9kOp04mMtd6Tio4fHwXicV0yXlz6fp3Az1ATVP4H0fvi5oavPNGQjRd2vC9eDt0uA1tK2WKVp/4Mo9b6N8aDB1u9+7QQ3VRLY= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0640.namprd21.prod.outlook.com (10.175.141.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Thu, 20 Jul 2017 08:03:16 +0000 Received: from MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) by MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) with mapi id 15.01.1282.008; Thu, 20 Jul 2017 08:03:16 +0000 From: Dave Thaler To: Ron Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Thread-Index: AdL7Je43Z0B6UbQRQ8OzttnbbdH15QGByLdQAABgOLA= Date: Thu, 20 Jul 2017 08:03:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:128:bce4:a630:ff7d:7258] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0640; 7:lcOfa4PL8xlO/aB2I6qG+EoT0Bic/rVqUQppm6uL+I9+/vfAG2sA4cNvK4iGwVWM7NOw5oPjV6KlS5ez+vtIrkpKvq8zJWymFV6Kq/xJtyIiy0eBT3YkTkCsRZx5d3IYBMs0jxFduGbW/ceh1vJNakjaoqkX9tv+L0IyMWeaHOxryKvsROUbTaqxm7G+iOe8sD5AXadsfWx7RzO6Qdl11MXCaTq3gzoQy2Or0YYJ78WEtQMK1/KIAIomXXCAauJS/jon32OvSm0cREh7EcWTqL3U4VUQTXPVRXcKar55Xsohrwswf1RvShZc6k9QtCB1ZbvW7s3oA7u1HxWXG4l9KIwR6iMb0Wh2+G6FHZN7DGYJodb4lXrXF6pshGJthDhWAQCOQ4kH4w4+soE45hqidEcfHX2XxJxgCB6gSFMlmpWXodDr+/UTqp9rc228CTLyR0Awt4/EomwtZxYJCYoinxNG4tWs8wu8CdTQee20Uv33pmGHdCrIXJ7L/4RgmYLJh2wCeCaGNSXuZfdtINk+WtMaxk9oLuDCqKXdPU9AKof8scw8UPdP359/1f9cID902WNaImZ11S/2SWcLkSkZnek3S/iH/1bId7fBx4LXPWRVLKqHgcIvUkk14sWc3iw7r5Qju8hgVgWhH3M7J8L09Vm9WrAMelqNHxf6lrWNY3T8vcJJtZhqMSLUD7Zn8dBBkciOC/yjXfL76FoO+2Aw9ue6SbOQo3+NGRL7c0hL4PMYMk+4IqtRHejNJaf3isoBeJyyz1oZkTwq/P6LZ3OWgkyyhazrAnwRLTejm0MmiLTFNnJsFJHxRLFHePpdgGXe x-ms-office365-filtering-correlation-id: 83ff563b-bf17-41e8-ef66-08d4cf45c732 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0640; x-ms-traffictypediagnostic: MWHPR21MB0640: x-exchange-antispam-report-test: UriScan:(236129657087228)(189930954265078)(138986009662008)(48057245064654)(148574349560750)(219752817060721)(164587983369549)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0640; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0640; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39860400002)(39450400003)(39850400002)(39410400002)(39840400002)(13464003)(51914003)(377454003)(76176999)(2950100002)(8676002)(81166006)(10090500001)(25786009)(54356999)(50986999)(86362001)(8936002)(7736002)(10290500003)(74316002)(2900100001)(6306002)(230783001)(77096006)(5005710100001)(33656002)(53546010)(14454004)(9686003)(2501003)(53936002)(966005)(478600001)(189998001)(99286003)(2940100002)(7696004)(305945005)(8666007)(5660300001)(55016002)(6436002)(6506006)(3660700001)(3280700002)(38730400002)(6246003)(2906002)(6116002)(102836003)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0640; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 08:03:16.4967 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0640 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:03:23 -0000 BTW, RFC 7564 is being updated by https://tools.ietf.org/html/draft-ietf-precis-7564bis-09 which is in IESG e= valuation. -----Original Message----- From: Dave Thaler=20 Sent: Thursday, July 20, 2017 10:01 AM To: 'Ron Bonica' ; int-area@ietf.org Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Section 2.1: > If the Interface Identification Object identifies the probed > interface by name, the object payload contains the human-readable > interface name. The interface name SHOULD be the full MIB-II ifName, > if less than 255 octets, or the first 255 octets of the ifName, if > the ifName is longer. The interface name MAY be some other human- > meaningful name of the interface. The interface name MUST be > represented in the UTF-8 charset [RFC3629] using the Default Language > [RFC2277]. As I mentioned during the meeting today, the above text has a bunch of prob= lems as written: 1) Saying UTF-8 is not sufficient, you need to discuss normalization form, = etc. See RFC 7564. You can't just copy a paragraph from some other spec, you have to dete= rmine what properties you actually want, but the Precis WG defined a number of re= usable classes. There are precis experts that can help the WG determine what profile i= s most appropriate. 2) You can't truncate a UTF-8 string at 255 octets and still have a valid U= TF-8 string, since characters can span multiple octets and you might truncate in the midd= le and get a partial character, which leaves you with an invalid string. 3) The length restriction is only part of the SHOULD. Does that mean that = if you follow the MAY, there is no such length restriction? Dave -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Wednesday, July 12, 2017 5:46 PM To: int-area@ietf.org; Carlos Pignataro (cpignata) Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Hi Carlos, Thanks for the review. Inline, below. Ron >=20 > Hi, Ron, Authors, >=20 > As I was reading over draft-ietf-intarea-probe-00, and wanted to share=20 > a couple of observations for your consideration. >=20 >=20 > * Have you considered the tradeoff of defining new ICMP Types versus > extending existing ICMP Types? If using existing ICMPv6 Echo=20 > Request/Reply and extending them instead of defining brand new types,=20 > the backwards interoperability achieved is higher [ [RB ] I thought about extending the existing ICMP messages, but decided against i= t for backward compatibility reasons. Both existing messages end with a var= iable length data field. This field begins at a fixed position, but doesn't= have a length attribute of its own. Therefore, we can't add any more field= s after it. There may be ways to dance around the problem, but they all involve redefin= ing the existing field in the existing message. > * Have you considered using other protocols as well in addition to IC= MP for > the PROBE message, which can elicit ICMP errors or responses with=20 > appropriate extensions? In particular UDP is a protocol much used and=20 > desired for probes. >=20 [RB ] ICMP and UDP would both work. I chose ICMP because ICMP already supports le= gacy echo/echo reply. But I'm not feeling religious about this. In the final analysis, I am willing to use whatever protocol the WG prefers= . > These two points actually reminded me of=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools > .ietf.org%2Fhtml%2Fdraft-&data=3D02%7C01%7Cdthaler%40microsoft.com%7C4f6 > 74c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7 > C0%7C636354711627226706&sdata=3DG5vSnrYbaFBryTvzh5pn3AVaJz3hURtt1PJYLVah > rnM%3D&reserved=3D0 > shen-traceroute-ping-ext-04 (and the ICMP-only predecessor draft-shen- > udp-traceroute-ext-01) that defines a probe extension applied to ICMP=20 > Echo Request and UDP, and RFC 4884 extensions to responses. That=20 > approach seems somewhat more generic. >=20 > Additionally, I was also reminded of the ICMP AUP at RFC 7279, it=20 > would be useful to map against that doc to show how this is (as it is=20 > the case) a really good use of ICMP. [RB ] Section 3 of 7279 suggests that ICMP can be used for diagnostics. It calls = out PING as being an acceptable use. But again, I don't feel religious abou= t this. The protocol works over UDP just as well as it works over ICMP. = Ron >=20 > Thanks! >=20 > ? Carlos. >=20 >=20 ******************************* _______________________________________________ Int-area mailing list Int-area@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fint-area&data=3D02%7C01%7Cdthaler%40microsoft.c= om%7C4f674c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636354711627226706&sdata=3DxSDwSJAGRkBNGO9IO9FfArdLkywAnaHf8AZ5OWcs= Dsk%3D&reserved=3D0 From nobody Thu Jul 20 01:11:26 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8E5126557 for ; Thu, 20 Jul 2017 01:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 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, 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 f9fcA6Pex3bK for ; Thu, 20 Jul 2017 01:11:22 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4423B129562 for ; Thu, 20 Jul 2017 01:11:22 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id D899B401BC; Thu, 20 Jul 2017 10:11:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id A84131A00C8; Thu, 20 Jul 2017 10:11:20 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 10:11:20 +0200 From: To: "Bob Briscoe (ietf@bobbriscoe.net)" CC: Internet Area Thread-Topic: Open issue: rfc6040update & SFC Thread-Index: AdMBL8MQU3YBpnYmSjaXmXmS66QYOA== Date: Thu, 20 Jul 2017 08:11:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F869@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.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A00F869OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Int-area] Open issue: rfc6040update & SFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:11:24 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A00F869OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, You asked during your presentation whether SFC is to be marked as N/A. I confirm. SFC encapsulation is not a transport encapsulation. ECN should b= e managed by the transport encapsulation used within an SFC-enabled domain. You have a long list of encap protocols; it is actually cool to reduce that= list by one :) Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A00F869OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

You asked during your presentation whether = SFC is to be marked as N/A.

 

I confirm. SFC encapsulation is not a trans= port encapsulation. ECN should be managed by the transport encapsulation us= ed within an SFC-enabled domain.

 

You have a long list of encap protocols; it= is actually cool to reduce that list by one :)   

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A00F869OPEXCLILMA3corp_-- From nobody Thu Jul 20 01:11:58 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9857E129B55 for ; Thu, 20 Jul 2017 01:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=microsoft.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 FmQFpoNA9bLY for ; Thu, 20 Jul 2017 01:11:54 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DC9129AA0 for ; Thu, 20 Jul 2017 01:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iu60HjyaoKUcwFK+IByOiAV2Qz7iFcTVvwaZ4paa4+c=; b=ZLES04xaLSrTH8IoBZ+KMRg13BIe5ld9/U2FTUC+T4nUo2HRzkJOoFkrGKZSgJA7U8i3SqnjEs4CHxDe6HD7yYeWhfo9IDORmsAj/GKWDg27AwLbin7/ND4fnEvdwHB1wGlX1aP5pwW88jfAiVE+ctJo3X39tLUfEpx2NkNXtG8= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0704.namprd21.prod.outlook.com (10.175.142.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.1; Thu, 20 Jul 2017 08:11:51 +0000 Received: from MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) by MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) with mapi id 15.01.1282.008; Thu, 20 Jul 2017 08:11:51 +0000 From: Dave Thaler To: Ron Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Thread-Index: AdL7Je43Z0B6UbQRQ8OzttnbbdH15QGByLdQAABgOLAAAEKEQA== Date: Thu, 20 Jul 2017 08:11:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:128:bce4:a630:ff7d:7258] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0704; 7:qwGiEWqfMl4woaqZXEUMyyoTEtBlyqcdLgM2/+tgiM9JjGaO3PDN6vDRVOH+0uykeTku8tM5+6ak116zMrVqvPevcS0IemCJkNdPznZQ2MaGUb9FxASIeF/2efOTe9fM4OhVxjVmxKlNWbzmu6Ft6G1Z6r0XYYyg84VP1iAWUur+wESYQsNOFv5TZHDCA2IP9URCVCBqXdBU8OjCL4oUd2qUikXXTD5nD69JlOibSGTNWeO+zh3vhhyhlwnK377qR6rk4/gwKnef8bFXr4M7Ud40ZGzvED02pvpPOg5aIvHhdDN4Z1/UV7n+ZW0Lzz96lNEOfogP+35dnrh1Y6DdFADIxfaxftwgxHGBVEd6c0kQIJgS/QYxrVZqqC5lj6pNFEWPGACcyqSHeJHQPN143MNbrKulAYlle2bjpZFboTJYpJFoxeg1IEN6WubtHf4bAuOUvEdJujqzPTm0BkhAsdLO4mQIuxS5TNUANOflG3p1RyoizcLDk81K0juIbdWHkFrFEHu03bFhgyhF7xuFdhSz8WgK1OCbO6QelSAXc1WmQsHlIuj9fqUQS0xdCjFHFY3P49OUl6sPUgPj8aJQNJg8n/3RloJ8YyikDM+1HjeZXJREcd7V4RqxVAbeHp2qEBKGLRe5/j+IOz6B7JftRcCO8UwSqwpyo8n2Gx6X/N+AFdIi3ufaS/8eU1sTp2NIFIuQmPZ2W4HUTzn1cVst28nvzFuXTwDYqG18S3wQjwkiJthS6HhHmWtFfgQm9TGH8thd1DZdjhEPhBhi/jzhMuisy8BpjMRpZukrCApZ+SSDgrmdh5ARGtR9l0xqMwki x-ms-office365-filtering-correlation-id: 8143fe85-a676-4458-929e-08d4cf46f9e8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0704; x-ms-traffictypediagnostic: MWHPR21MB0704: x-exchange-antispam-report-test: UriScan:(236129657087228)(189930954265078)(138986009662008)(48057245064654)(148574349560750)(219752817060721)(247924648384137)(164587983369549)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0704; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0704; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39410400002)(39400400002)(39850400002)(39450400003)(51914003)(377454003)(13464003)(10290500003)(5005710100001)(966005)(229853002)(2940100002)(102836003)(478600001)(7736002)(86362001)(8676002)(2950100002)(77096006)(6116002)(7696004)(6436002)(3660700001)(76176999)(8936002)(50986999)(3280700002)(8666007)(55016002)(38730400002)(54356999)(6246003)(6306002)(10090500001)(81166006)(9686003)(5660300001)(33656002)(74316002)(53936002)(305945005)(2906002)(230783001)(2501003)(53546010)(14454004)(2900100001)(189998001)(99286003)(25786009)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0704; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 08:11:50.9761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0704 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:11:57 -0000 Section 5.11 of https://tools.ietf.org/html/rfc7652 contains an example of the sort of things you have to say, but you can't ju= st paste that without analyzing whether your case wants the same semantics as that RFC us= es. In fact you probably don't, since that one is more of a username than an interfacen= ame. -----Original Message----- From: Dave Thaler=20 Sent: Thursday, July 20, 2017 10:03 AM To: 'Ron Bonica' ; 'int-area@ietf.org' Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt BTW, RFC 7564 is being updated by https://tools.ietf.org/html/draft-ietf-precis-7564bis-09 which is in IESG e= valuation. -----Original Message----- From: Dave Thaler Sent: Thursday, July 20, 2017 10:01 AM To: 'Ron Bonica' ; int-area@ietf.org Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Section 2.1: > If the Interface Identification Object identifies the probed > interface by name, the object payload contains the human-readable > interface name. The interface name SHOULD be the full MIB-II ifName, > if less than 255 octets, or the first 255 octets of the ifName, if > the ifName is longer. The interface name MAY be some other human- > meaningful name of the interface. The interface name MUST be > represented in the UTF-8 charset [RFC3629] using the Default Language > [RFC2277]. As I mentioned during the meeting today, the above text has a bunch of prob= lems as written: 1) Saying UTF-8 is not sufficient, you need to discuss normalization form, = etc. See RFC 7564. You can't just copy a paragraph from some other spec, you have to dete= rmine what properties you actually want, but the Precis WG defined a number of re= usable classes. There are precis experts that can help the WG determine what profile i= s most appropriate. 2) You can't truncate a UTF-8 string at 255 octets and still have a valid U= TF-8 string, since characters can span multiple octets and you might truncate in the midd= le and get a partial character, which leaves you with an invalid string. 3) The length restriction is only part of the SHOULD. Does that mean that = if you follow the MAY, there is no such length restriction? Dave -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Wednesday, July 12, 2017 5:46 PM To: int-area@ietf.org; Carlos Pignataro (cpignata) Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt Hi Carlos, Thanks for the review. Inline, below. Ron >=20 > Hi, Ron, Authors, >=20 > As I was reading over draft-ietf-intarea-probe-00, and wanted to share=20 > a couple of observations for your consideration. >=20 >=20 > * Have you considered the tradeoff of defining new ICMP Types versus > extending existing ICMP Types? If using existing ICMPv6 Echo=20 > Request/Reply and extending them instead of defining brand new types,=20 > the backwards interoperability achieved is higher [ [RB ] I thought about extending the existing ICMP messages, but decided against i= t for backward compatibility reasons. Both existing messages end with a var= iable length data field. This field begins at a fixed position, but doesn't= have a length attribute of its own. Therefore, we can't add any more field= s after it. There may be ways to dance around the problem, but they all involve redefin= ing the existing field in the existing message. > * Have you considered using other protocols as well in addition to IC= MP for > the PROBE message, which can elicit ICMP errors or responses with=20 > appropriate extensions? In particular UDP is a protocol much used and=20 > desired for probes. >=20 [RB ] ICMP and UDP would both work. I chose ICMP because ICMP already supports le= gacy echo/echo reply. But I'm not feeling religious about this. In the final analysis, I am willing to use whatever protocol the WG prefers= . > These two points actually reminded me of=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools > .ietf.org%2Fhtml%2Fdraft-&data=3D02%7C01%7Cdthaler%40microsoft.com%7C4f6 > 74c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7 > C0%7C636354711627226706&sdata=3DG5vSnrYbaFBryTvzh5pn3AVaJz3hURtt1PJYLVah > rnM%3D&reserved=3D0 > shen-traceroute-ping-ext-04 (and the ICMP-only predecessor draft-shen- > udp-traceroute-ext-01) that defines a probe extension applied to ICMP=20 > Echo Request and UDP, and RFC 4884 extensions to responses. That=20 > approach seems somewhat more generic. >=20 > Additionally, I was also reminded of the ICMP AUP at RFC 7279, it=20 > would be useful to map against that doc to show how this is (as it is=20 > the case) a really good use of ICMP. [RB ] Section 3 of 7279 suggests that ICMP can be used for diagnostics. It calls = out PING as being an acceptable use. But again, I don't feel religious abou= t this. The protocol works over UDP just as well as it works over ICMP. = Ron >=20 > Thanks! >=20 > ? Carlos. >=20 >=20 ******************************* _______________________________________________ Int-area mailing list Int-area@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fint-area&data=3D02%7C01%7Cdthaler%40microsoft.c= om%7C4f674c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636354711627226706&sdata=3DxSDwSJAGRkBNGO9IO9FfArdLkywAnaHf8AZ5OWcs= Dsk%3D&reserved=3D0 From nobody Thu Jul 20 01:35:22 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271D5131566 for ; Thu, 20 Jul 2017 01:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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=bobbriscoe.net 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 LlClvtjo19kR for ; Thu, 20 Jul 2017 01:35:19 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A417F131A81 for ; Thu, 20 Jul 2017 01:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To:Sender:Reply-To: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=XxWncNo8anlcVQJLPDqQk/9CS2jEFrXJvYrn8HLVto4=; b=eb/s8G+Vd4z3Px2vzNwh9Y64iG jaIgjVpK95jEGepuF0fbqfrp5h8k6jO5H9z7dUbecmwfh6WDtoWIAmowuHoPTe2HapFLhUb+VK0d7 ATflbucV8KLs/u5gTGOOlDrvVxOL5SLbQ/ecpqBJ6cHRWz2r6AS2NsUgjqr6WSjZK7Qch4W+j7uC4 AbnTB8DfqiPSS/Er4HYxUSVKh7K1PHTzXBfBn0+6w8c/Mg591VCPqkeP6NFGutzyBGqHsWfxHgSyY tojkmeKnau+5Tuab23yTPxUIvgp1/e3N7YVC12VqK1tQ+zUP4BO3+HQ4eYxPQIlNTFFGcA9KzHOVO hNhmFE3A==; Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:39970) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dY6vU-0003AN-O5; Thu, 20 Jul 2017 09:35:16 +0100 To: Tal Mizrahi Cc: Joachim Fabini , Al Morton , intarea IETF list From: Bob Briscoe Message-ID: Date: Thu, 20 Jul 2017 09:35:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [Int-area] timestamp activity in tcpm X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:35:20 -0000 Tal, As promised: Latest development: TCP Low Latency Option https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00 Previous attempt (long expired, but not necessarily dead): (Ab)using the TCP timestamp field to negotiate variables, including the resolution of TCP timestamps. https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05 Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Jul 20 01:55:00 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A309131566 for ; Thu, 20 Jul 2017 01:54:54 -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, 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=bobbriscoe.net 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 IBfrPVgvEVBC for ; Thu, 20 Jul 2017 01:54:50 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 D15F313157A for ; Thu, 20 Jul 2017 01:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wKiTUGsfknBP6zxbM5seF+dV8NzhQWiOGq9c9YUCcnM=; b=nzF/B5DOyaTecuR/MSVnSzmnu ZS89RzjGN8r9iAqOsF+V+QUG3u8RwmMghFpo8dlEgrcyBIomjEb8xLSY2kwJ/ioTtxjBuYk/7GS5g Q6RfshVWViQQhm2nwN2qlSwwPY7MUR4HgTXJLL4WxDpFON1sA0IdB1jZQdYGlNLEhsAvXG/Bc9ind QaVEnGc5v2/a04KUtO1o5Rm2v+mqFZvCjL62hhQCkvnnWi1UCLeVnciz8Rj0RlUWzFJndg1otcEl3 VpGz8wuij2xqnRlUBEPukK+UGCCvX16WBBULtSlStS+6l6K6k5BdjSarr1Us4UvsnI/nIC6kl8z8k GT/2t/7Vg==; Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:40274) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dY7EO-00055Y-Av; Thu, 20 Jul 2017 09:54:48 +0100 To: mohamed.boucadair@orange.com Cc: Internet Area References: <787AE7BB302AE849A7480A190F8B93300A00F869@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Bob Briscoe Message-ID: <3d5aa651-635e-adc1-bda4-e428553c3612@bobbriscoe.net> Date: Thu, 20 Jul 2017 09:54:38 +0100 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: <787AE7BB302AE849A7480A190F8B93300A00F869@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------0A1C240FDC6F8AC22CBDEB58" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [Int-area] Open issue: rfc6040update & SFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:54:54 -0000 This is a multi-part message in MIME format. --------------0A1C240FDC6F8AC22CBDEB58 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Med, Thx Bob On 20/07/17 09:11, mohamed.boucadair@orange.com wrote: > > Bob, > > You asked during your presentation whether SFC is to be marked as N/A. > > I confirm. SFC encapsulation is not a transport encapsulation. ECN > should be managed by the transport encapsulation used within an > SFC-enabled domain. > > You have a long list of encap protocols; it is actually cool to reduce > that list by one :) > > Cheers, > > Med > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------0A1C240FDC6F8AC22CBDEB58 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Med,

Thx




Bob

On 20/07/17 09:11, mohamed.boucadair@orange.com wrote:

Bob,

 

You asked during your presentation whether SFC is to be marked as N/A.

 

I confirm. SFC encapsulation is not a transport encapsulation. ECN should be managed by the transport encapsulation used within an SFC-enabled domain.

 

You have a long list of encap protocols; it is actually cool to reduce that list by one :)   

 

Cheers,

Med


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------0A1C240FDC6F8AC22CBDEB58-- From nobody Thu Jul 20 07:37:53 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917D8131C67; Thu, 20 Jul 2017 07:37:51 -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 AL9OtI9lF34V; Thu, 20 Jul 2017 07:37: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 9B793131C66; Thu, 20 Jul 2017 07:37:50 -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 vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6KEbM0C008791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 07:37:33 -0700 (PDT) To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> Date: Thu, 20 Jul 2017 07:37:20 -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: <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:37:51 -0000 On 7/19/2017 10:39 PM, mohamed.boucadair@orange.com wrote: > Hi Joe, > > The text can always be worked out. This is not an IETF LC :) Agreed - I was explaining that the current text - and many of the responses in this chain, both from you and others, continues to be confusing. > The main point is that we are following your suggestion to define the solution as an application proxy using a dedicated port number. As feedback for the doc, that could be made more explicit, including in the title (this is an application proxy, not typically referred to as middleboxes). That also includes limiting the doc to using TCP app-layer APIs and describing any behavior that *might* happen at the segment level as just that - hypothetical, perhaps desired, but NOT the mechanism being proposed. FWIW. Joe From nobody Thu Jul 20 07:40:29 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268AE131C66; Thu, 20 Jul 2017 07:40:28 -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 ULOI9UTUyoTh; Thu, 20 Jul 2017 07:40:26 -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 B88CE1317A4; Thu, 20 Jul 2017 07:40:26 -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 vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6KEdZeq009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 07:39:47 -0700 (PDT) To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6BD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Thu, 20 Jul 2017 07:39:33 -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: <787AE7BB302AE849A7480A190F8B93300A00F6BD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:40:28 -0000 On 7/19/2017 10:43 PM, mohamed.boucadair@orange.com wrote: > ... >>> The converter is not intended to be used for all TCP connections. In >>> the draft we explain how an MPTCP endpoint can bypass the converter if >>> the destination server supports MPTCP. For TCP-AO, my recommendation >>> would be that the default policy of the client would be to never use >>> the converter if TCP-AO is requested by the application. >> How do you know you're using the converter? > [Med] The converter is explicilty configured (e.g., locally configured or y means of https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-07). AOK. If these are independent TCP connections that are explicitly addressed, they should be described as such. The current doc implies SYN translation - whether that's an implementation optimization (limited to successful TFO SYNs) or not needs to be very clearly described as such as well. Joe From nobody Thu Jul 20 07:52:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C25E131A7A; Thu, 20 Jul 2017 07:52:24 -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 EUOYEVtvJKvn; Thu, 20 Jul 2017 07:52:23 -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 148EF131CFA; Thu, 20 Jul 2017 07:52:23 -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 vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6KEpcuc024893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 07:51:48 -0700 (PDT) To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> <3bf7fffa-c267-5d67-c124-01fa52ebafdc@tessares.net> From: Joe Touch Message-ID: <63ad0458-0eed-e843-fec8-aadcedcc3e74@isi.edu> Date: Thu, 20 Jul 2017 07:51:36 -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: <3bf7fffa-c267-5d67-c124-01fa52ebafdc@tessares.net> Content-Type: multipart/alternative; boundary="------------1BBCBFC63D2B35D9D0089E4D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:52:25 -0000 This is a multi-part message in MIME format. --------------1BBCBFC63D2B35D9D0089E4D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 11:19 PM, Olivier Bonaventure wrote: >> How do you know you're using the converter? Is the initial connection to >> that converter? Or does the converter hijack (the latter is the >> implication of the text, AFAICT). > > Consider a simple implementation using LD_PRELOAD to overload the > connect system call on Linux. When the application issues connect, it > has already set the required socket options that apply for this new > connection. The converter implementation uses the destination address > of the connect system call to create the TLV message and sets the TFO > socket option to send it during its own connect with the converter. If > the application had requested TFO, then the converter library simply > uses the regular connect call and everything is fine. The Linux API is not the TCP API. The TCP API is a generic, implementation-independent interface to upper layer protocols and applications. This mechanism needs to be described in terms of the TCP API. Yes, the app can SEND data to the socketpair before the connection is established, per RFC793 (note - I'm using 793 terms, not unix terms here). There's nothing in RFC7413 (TFO) that confirms that TFO will succeed on a new connection and that RFC explicitly admits it did not introduce an API extension by which an application can read (RECEIVE) SYN data before the connection is established: But the client's socket may have data available to read before it's connected. This document does not cover the corresponding API change. I.e., it's important to explain what you're doing using the TCP API, not the features of an implementation (the latter can be helpful as an example, e.g., in an appendix, though). Joe --------------1BBCBFC63D2B35D9D0089E4D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 7/19/2017 11:19 PM, Olivier Bonaventure wrote:
How do you know you're using the converter? Is the initial connection to
that converter? Or does the converter hijack (the latter is the
implication of the text, AFAICT).

Consider a simple implementation using LD_PRELOAD to overload the connect system call on Linux. When the application issues connect, it has already set the required socket options that apply for this new connection. The converter implementation uses the destination address of the connect system call to create the TLV message and sets the TFO socket option to send it during its own connect with the converter. If the application had requested TFO, then the converter library simply uses the regular connect call and everything is fine.
The Linux API is not the TCP API. The TCP API is a generic, implementation-independent interface to upper layer protocols and applications.

This mechanism needs to be described in terms of the TCP API.

Yes, the app can SEND data to the socketpair before the connection is established, per RFC793 (note - I'm using 793 terms, not unix terms here). There's nothing in RFC7413 (TFO) that confirms that TFO will succeed on a new connection and that RFC explicitly admits it did not introduce an API extension by which an application can read (RECEIVE) SYN data before the connection is established:
   But the client's socket may have data available to read before it's
   connected.  This document does not cover the corresponding API
   change.
I.e., it's important to explain what you're doing using the TCP API, not the features of an implementation (the latter can be helpful as an example, e.g., in an appendix, though).

Joe
--------------1BBCBFC63D2B35D9D0089E4D-- From nobody Thu Jul 20 08:26:38 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E244C131CE7; Thu, 20 Jul 2017 08:26:37 -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, FREEMAIL_FROM=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 49hS1wE_ZFCE; Thu, 20 Jul 2017 08:26:36 -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 BB752131C43; Thu, 20 Jul 2017 08:26:35 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 702C6A05A0; Thu, 20 Jul 2017 17:26:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 472C11C008F; Thu, 20 Jul 2017 17:26:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 17:26:33 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAWXFBmj7/jopsUiQDq1/JQyPZ6Jc1ZKA Date: Thu, 20 Jul 2017 15:26:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A010201@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> In-Reply-To: <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:26:38 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2ku ZWR1XQ0KPiBFbnZvecOpwqA6IGpldWRpIDIwIGp1aWxsZXQgMjAxNyAxNjozNw0KPiDDgMKgOiBC T1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBPbGl2aWVyIEJvbmF2ZW50dXJlOyBJbnRlcm5ldCBB cmVhOyB0c3YtDQo+IGFyZWFAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtJbnQtYXJlYV0gTWlk ZGxlYm94ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQDQo+IA0KPiANCj4gDQo+IE9u IDcvMTkvMjAxNyAxMDozOSBQTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN Cj4gPiBIaSBKb2UsDQo+ID4NCj4gPiBUaGUgdGV4dCBjYW4gYWx3YXlzIGJlIHdvcmtlZCBvdXQu IFRoaXMgaXMgbm90IGFuIElFVEYgTEMgOikNCj4gQWdyZWVkIC0gSSB3YXMgZXhwbGFpbmluZyB0 aGF0IHRoZSBjdXJyZW50IHRleHQgLSBhbmQgbWFueSBvZiB0aGUNCj4gcmVzcG9uc2VzIGluIHRo aXMgY2hhaW4sIGJvdGggZnJvbSB5b3UgYW5kIG90aGVycywgY29udGludWVzIHRvIGJlDQo+IGNv bmZ1c2luZy4NCj4gDQpbTWVkXSBDYWxsaW5nIG91dCB0aG9zZSBjb25mdXNpbmcgcG9pbnRzIHdv dWxkIGhlbHAuICANCg0KPiA+IFRoZSBtYWluIHBvaW50IGlzIHRoYXQgd2UgYXJlIGZvbGxvd2lu ZyB5b3VyIHN1Z2dlc3Rpb24gdG8gZGVmaW5lIHRoZQ0KPiBzb2x1dGlvbiBhcyBhbiBhcHBsaWNh dGlvbiBwcm94eSB1c2luZyBhIGRlZGljYXRlZCBwb3J0IG51bWJlci4NCj4gQXMgZmVlZGJhY2sg Zm9yIHRoZSBkb2MsIHRoYXQgY291bGQgYmUgbWFkZSBtb3JlIGV4cGxpY2l0LCBpbmNsdWRpbmcg aW4NCj4gdGhlIHRpdGxlICh0aGlzIGlzIGFuIGFwcGxpY2F0aW9uIHByb3h5LCBub3QgdHlwaWNh bGx5IHJlZmVycmVkIHRvIGFzDQo+IG1pZGRsZWJveGVzKS4NCj4gDQoNCltNZWRdIExvb2tzIGxp a2UgYSBnb29kIGlkZWEgdG8gbWUuDQoNCj4gVGhhdCBhbHNvIGluY2x1ZGVzIGxpbWl0aW5nIHRo ZSBkb2MgdG8gdXNpbmcgVENQIGFwcC1sYXllciBBUElzIGFuZA0KPiBkZXNjcmliaW5nIGFueSBi ZWhhdmlvciB0aGF0ICptaWdodCogaGFwcGVuIGF0IHRoZSBzZWdtZW50IGxldmVsIGFzIGp1c3QN Cj4gdGhhdCAtIGh5cG90aGV0aWNhbCwgcGVyaGFwcyBkZXNpcmVkLCBidXQgTk9UIHRoZSBtZWNo YW5pc20gYmVpbmcNCj4gcHJvcG9zZWQuDQo+DQo+IEZXSVcuDQo+IA0KPiBKb2UNCg0K From nobody Thu Jul 20 08:39:04 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E60131D07 for ; Thu, 20 Jul 2017 08:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 t19V5sZIplNK for ; Thu, 20 Jul 2017 08:38:56 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 044F9131C3E for ; Thu, 20 Jul 2017 08:38:54 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id k69so27822392wmc.1 for ; Thu, 20 Jul 2017 08:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xSa96iYIa+pgwsJ4c3jbbO2CwyZgxIptI14mVczm36g=; b=HtmbgozqcLtFxkNYXwkQ6WbvglihsMfBTJyB6ZgtXcJqJgi8TrG/5q0jggnlV4SxCr 97E90LLBEKCTZ5EBwj5tx4gRdnBp4LtxV7qRMyOnrDVJwsIPU4UEPKW4CEGeg9+IMNgx /YEEEM+I4y5bMsL3ZQnpzv6Ab/r/ykWwTMe/b6gHySEwIVYkicxoywIhk1TCCy/aaA1Y ga0zlvu0tblu5pFgOlpIeYEhUs/oa5hVJmUVE69bqXZOTmw0dEnzoEevbmh/EXMeU7kj A47sGVsDU/HcmDHg0DPiX4rFyTaHX9SSvPxBVakcUsRkZK0lNJOOf37qHKF/DJ/1VXTH M3Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xSa96iYIa+pgwsJ4c3jbbO2CwyZgxIptI14mVczm36g=; b=fqn8R8E7JiNDviJoXMEmu+rDBqN/RBkExr/G9UXBy2z0b8YckPbPEYnti+KYIxpgAN 2y82x3wyEC6pyL3oM4xS9pigATVmNPrzfd4K/u1sK3WfzOonG51ARS9pLP9UeGAVi+m1 LloaA1DJgty3PC+HJMAunFg1hool1j2tbcFABQF9pyCLXFhsdvHFi4CjXZ/lhsDFFvcb M1WrZ283mzkP2TUL768hx32BFj5VDf+EDvDqovM2O24SXtBZHvkkWSG2ESG8Uje47JZb n3uQC0U4ojpDqqMFzeDpgT6SQnB4M20z0bqe58ywUABaIklnZBgmCdwVNoVOC5ZJzoiL YlHg== X-Gm-Message-State: AIVw112n+1A7K0Jt1Y/yVRp45OUWBbkZYY0YKHsA1ofzToBxz4+gjQGV yRyHyEFE+qYKjJkV1M0aKLOdv94n7bye X-Received: by 10.28.175.135 with SMTP id y129mr2640532wme.87.1500565132465; Thu, 20 Jul 2017 08:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Thu, 20 Jul 2017 08:38:51 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A010201@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> <787AE7BB302AE849A7480A190F8B93300A010201@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Tom Herbert Date: Thu, 20 Jul 2017 08:38:51 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:38:59 -0000 On Thu, Jul 20, 2017 at 8:26 AM, wrote: > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joe Touch [mailto:touch@isi.edu] >> Envoy=C3=A9 : jeudi 20 juillet 2017 16:37 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; = tsv- >> area@ietf.org >> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP >> >> >> >> On 7/19/2017 10:39 PM, mohamed.boucadair@orange.com wrote: >> > Hi Joe, >> > >> > The text can always be worked out. This is not an IETF LC :) >> Agreed - I was explaining that the current text - and many of the >> responses in this chain, both from you and others, continues to be >> confusing. >> > [Med] Calling out those confusing points would help. > >> > The main point is that we are following your suggestion to define the >> solution as an application proxy using a dedicated port number. >> As feedback for the doc, that could be made more explicit, including in >> the title (this is an application proxy, not typically referred to as >> middleboxes). >> > > [Med] Looks like a good idea to me. > That use of the term middleboxes as opposed to proxy was also confusing to me. I'd also suggest not to call this a netwotk function, that has other connotations that don't apply here. Tom >> That also includes limiting the doc to using TCP app-layer APIs and >> describing any behavior that *might* happen at the segment level as just >> that - hypothetical, perhaps desired, but NOT the mechanism being >> proposed. >> >> FWIW. >> >> Joe > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Jul 20 08:40:21 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE8A12EC46; Thu, 20 Jul 2017 08:40:14 -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, FREEMAIL_FROM=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 2V0wi3Om7FLD; Thu, 20 Jul 2017 08:40:13 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB45413188D; Thu, 20 Jul 2017 08:40:12 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id C0A5B1C02B8; Thu, 20 Jul 2017 17:40:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 94D1E4005C; Thu, 20 Jul 2017 17:40:11 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 17:40:11 +0200 From: To: Tom Herbert CC: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAW5LBJKptC9OQkqhFf+x8f1OoqJc2f2Q Date: Thu, 20 Jul 2017 15:40:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A01027E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> <787AE7BB302AE849A7480A190F8B93300A010201@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:40:15 -0000 R29vZCBzdWdnZXN0aW9uLCBUb20uDQoNClRoYW5rcy4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9t QGhlcmJlcnRsYW5kLmNvbV0NCj4gRW52b3nDqcKgOiBqZXVkaSAyMCBqdWlsbGV0IDIwMTcgMTc6 MzkNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiBDY8KgOiBKb2UgVG91Y2g7 IE9saXZpZXIgQm9uYXZlbnR1cmU7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3JnDQo+ IE9iamV0wqA6IFJlOiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVu dCBvZiBNUFRDUA0KPiANCj4gT24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgODoyNiBBTSwgIDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPiBSZS0sDQo+ID4NCj4gPiBQbGVh c2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGUgOiBKb2UgVG91Y2ggW21haWx0bzp0b3Vj aEBpc2kuZWR1XQ0KPiA+PiBFbnZvecOpIDogamV1ZGkgMjAganVpbGxldCAyMDE3IDE2OjM3DQo+ ID4+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgT2xpdmllciBCb25hdmVudHVyZTsg SW50ZXJuZXQgQXJlYTsgdHN2LQ0KPiA+PiBhcmVhQGlldGYub3JnDQo+ID4+IE9iamV0IDogUmU6 IFtJbnQtYXJlYV0gTWlkZGxlYm94ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQDQo+ ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIDcvMTkvMjAxNyAxMDozOSBQTSwgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4gPiBIaSBKb2UsDQo+ID4+ID4NCj4gPj4gPiBU aGUgdGV4dCBjYW4gYWx3YXlzIGJlIHdvcmtlZCBvdXQuIFRoaXMgaXMgbm90IGFuIElFVEYgTEMg OikNCj4gPj4gQWdyZWVkIC0gSSB3YXMgZXhwbGFpbmluZyB0aGF0IHRoZSBjdXJyZW50IHRleHQg LSBhbmQgbWFueSBvZiB0aGUNCj4gPj4gcmVzcG9uc2VzIGluIHRoaXMgY2hhaW4sIGJvdGggZnJv bSB5b3UgYW5kIG90aGVycywgY29udGludWVzIHRvIGJlDQo+ID4+IGNvbmZ1c2luZy4NCj4gPj4N Cj4gPiBbTWVkXSBDYWxsaW5nIG91dCB0aG9zZSBjb25mdXNpbmcgcG9pbnRzIHdvdWxkIGhlbHAu DQo+ID4NCj4gPj4gPiBUaGUgbWFpbiBwb2ludCBpcyB0aGF0IHdlIGFyZSBmb2xsb3dpbmcgeW91 ciBzdWdnZXN0aW9uIHRvIGRlZmluZSB0aGUNCj4gPj4gc29sdXRpb24gYXMgYW4gYXBwbGljYXRp b24gcHJveHkgdXNpbmcgYSBkZWRpY2F0ZWQgcG9ydCBudW1iZXIuDQo+ID4+IEFzIGZlZWRiYWNr IGZvciB0aGUgZG9jLCB0aGF0IGNvdWxkIGJlIG1hZGUgbW9yZSBleHBsaWNpdCwgaW5jbHVkaW5n IGluDQo+ID4+IHRoZSB0aXRsZSAodGhpcyBpcyBhbiBhcHBsaWNhdGlvbiBwcm94eSwgbm90IHR5 cGljYWxseSByZWZlcnJlZCB0byBhcw0KPiA+PiBtaWRkbGVib3hlcykuDQo+ID4+DQo+ID4NCj4g PiBbTWVkXSBMb29rcyBsaWtlIGEgZ29vZCBpZGVhIHRvIG1lLg0KPiA+DQo+IFRoYXQgdXNlIG9m IHRoZSB0ZXJtIG1pZGRsZWJveGVzIGFzIG9wcG9zZWQgdG8gcHJveHkgd2FzIGFsc28NCj4gY29u ZnVzaW5nIHRvIG1lLiBJJ2QgYWxzbyBzdWdnZXN0IG5vdCB0byBjYWxsIHRoaXMgYSBuZXR3b3Rr IGZ1bmN0aW9uLA0KPiB0aGF0IGhhcyBvdGhlciBjb25ub3RhdGlvbnMgdGhhdCBkb24ndCBhcHBs eSBoZXJlLg0KPiANCj4gVG9tDQo+IA0KPiA+PiBUaGF0IGFsc28gaW5jbHVkZXMgbGltaXRpbmcg dGhlIGRvYyB0byB1c2luZyBUQ1AgYXBwLWxheWVyIEFQSXMgYW5kDQo+ID4+IGRlc2NyaWJpbmcg YW55IGJlaGF2aW9yIHRoYXQgKm1pZ2h0KiBoYXBwZW4gYXQgdGhlIHNlZ21lbnQgbGV2ZWwgYXMN Cj4ganVzdA0KPiA+PiB0aGF0IC0gaHlwb3RoZXRpY2FsLCBwZXJoYXBzIGRlc2lyZWQsIGJ1dCBO T1QgdGhlIG1lY2hhbmlzbSBiZWluZw0KPiA+PiBwcm9wb3NlZC4NCj4gPj4NCj4gPj4gRldJVy4N Cj4gPj4NCj4gPj4gSm9lDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IEludC1hcmVhIG1haWxpbmcgbGlzdA0KPiA+IEludC1hcmVh QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQt YXJlYQ0K From nobody Thu Jul 20 09:33:11 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576DC129B15 for ; Thu, 20 Jul 2017 09:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.734 X-Spam-Level: X-Spam-Status: No, score=-4.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_SOFTFAIL=0.665] 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 8TpmkfNCw1Da for ; Thu, 20 Jul 2017 09:33:07 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961C9127B60 for ; Thu, 20 Jul 2017 09:33:07 -0700 (PDT) Received: from [31.133.157.127] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1dYENo-0005nq-Kl; Thu, 20 Jul 2017 12:33:00 -0400 References: <150050561543.24146.13881541422679319061.idtracker@ietfa.amsl.com> To: "int-area@ietf.org" Cc: Juan Zuniga , "Stanley, Dorothy" , Warren Kumari , "Pascal Thubert (pthubert)" From: Charlie Perkins Organization: Blue Sky Meadows X-Forwarded-Message-Id: <150050561543.24146.13881541422679319061.idtracker@ietfa.amsl.com> Message-ID: <840a8edd-07e8-ae22-d256-cd3f08445bfd@computer.org> Date: Thu, 20 Jul 2017 09:32:57 -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: <150050561543.24146.13881541422679319061.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------D3F6C5527E5CE11110C7D4BA" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95b07b31f8daa74aa3cf390e4abd997f2c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.157.127 Archived-At: Subject: [Int-area] Fwd: New Version Notification for draft-perkins-intarea-multicast-ieee802-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:33:10 -0000 This is a multi-part message in MIME format. --------------D3F6C5527E5CE11110C7D4BA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, We have submitted an updated version of our Multicast Considerations draft. Pascal Thubert has contributed some new material explaining the value of a Proxy ND approach for 6LowPAN wireless networks. Your comments will be appreciated! Regards, Charlie P. -------- Forwarded Message -------- Subject: New Version Notification for draft-perkins-intarea-multicast-ieee802-03.txt Date: Wed, 19 Jul 2017 16:06:55 -0700 From: internet-drafts@ietf.org To: Charles Perkins , Warren Kumari , Juan Carlos Zuniga , Dorothy Stanley , Charles E. Perkins , Juan Zuniga A new version of I-D, draft-perkins-intarea-multicast-ieee802-03.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-intarea-multicast-ieee802 Revision: 03 Title: Multicast Considerations over IEEE 802 Wireless Media Document date: 2017-07-19 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-perkins-intarea-multicast-ieee802-03.txt Status: https://datatracker.ietf.org/doc/draft-perkins-intarea-multicast-ieee802/ Htmlized: https://tools.ietf.org/html/draft-perkins-intarea-multicast-ieee802-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-perkins-intarea-multicast-ieee802-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-perkins-intarea-multicast-ieee802-03 Abstract: Performance issues have been observed when multicast packet transmissions of IETF protocols are used over IEEE 802 wireless media. Even though enhamcements for multicast transmissions have been designed at both IETF and IEEE 802, there seems to exist a disconnect between specifications, implementations and configuration choices. This draft describes the different issues that have been observed, the multicast enhancement features that have been specified at IETF and IEEE 802 for wireless media, as well as the operational chioces that can be taken to improve the performace of the network. Finally, it provides some recommendations about the usage and combination of these features and operational choices. 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. The IETF Secretariat --------------D3F6C5527E5CE11110C7D4BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello folks,

We have submitted an updated version of our Multicast Considerations draft.  Pascal Thubert has contributed some new material explaining the value of a Proxy ND approach for 6LowPAN wireless networks.

Your comments will be appreciated!

Regards,
Charlie P.




-------- Forwarded Message --------
Subject: New Version Notification for draft-perkins-intarea-multicast-ieee802-03.txt
Date: Wed, 19 Jul 2017 16:06:55 -0700
From: internet-drafts@ietf.org
To: Charles Perkins <charliep@computer.org>, Warren Kumari <warren@kumari.net>, Juan Carlos Zuniga <j.c.zuniga@ieee.org>, Dorothy Stanley <dstanley@arubanetworks.com>, Charles E. Perkins <charliep@computer.org>, Juan Zuniga <j.c.zuniga@ieee.org> 


A new version of I-D, draft-perkins-intarea-multicast-ieee802-03.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-intarea-multicast-ieee802
Revision:	03
Title:		Multicast Considerations over IEEE 802 Wireless Media
Document date:	2017-07-19
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-perkins-intarea-multicast-ieee802-03.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-intarea-multicast-ieee802/
Htmlized:       https://tools.ietf.org/html/draft-perkins-intarea-multicast-ieee802-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-perkins-intarea-multicast-ieee802-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-perkins-intarea-multicast-ieee802-03

Abstract:
   Performance issues have been observed when multicast packet
   transmissions of IETF protocols are used over IEEE 802 wireless
   media.  Even though enhamcements for multicast transmissions have
   been designed at both IETF and IEEE 802, there seems to exist a
   disconnect between specifications, implementations and configuration
   choices.  This draft describes the different issues that have been
   observed, the multicast enhancement features that have been specified
   at IETF and IEEE 802 for wireless media, as well as the operational
   chioces that can be taken to improve the performace of the network.
   Finally, it provides some recommendations about the usage and
   combination of these features and operational choices.

                                                                                  


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.

The IETF Secretariat
--------------D3F6C5527E5CE11110C7D4BA-- From nobody Thu Jul 20 10:31:52 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] [multipathtcp] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List 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 Sat Jul 22 12:21:23 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D41A12EC37; Sat, 22 Jul 2017 12:21:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150075128159.20420.7690421440018747900@ietfa.amsl.com> Date: Sat, 22 Jul 2017 12:21:21 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-probe-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 19:21:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group WG of the IETF. Title : PROBE: A Utility For Probing Interfaces Authors : Ron Bonica Reji Thomas Jen Linkova Chris Lenart Mohamed Boucadair Filename : draft-ietf-intarea-probe-02.txt Pages : 17 Date : 2017-07-22 Abstract: This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-probe-02 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-probe-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-probe-02 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 Sat Jul 22 12:28:48 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F34129B5E; Sat, 22 Jul 2017 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net 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 THU8JNBcid1J; Sat, 22 Jul 2017 12:28:44 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0108.outbound.protection.outlook.com [104.47.32.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C6C12EC37; Sat, 22 Jul 2017 12:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0kr/ApTfML9V3NqbNNT7LrvyoQzm+s3sSOcI0R6fwYw=; b=WpBxY973RT+LS+UiTPPtKzd+LNGJ1D6XwtfiSulDhMLnQWugv6E9bhTN+JoNdyWVyePMr1AdmaVmQ4mOewOAKYxM6QehHJZV5GItYHKtqphRv7C4yzG4oMvqcvi9Re6keTzOh4GIJwZ9tVJ/ajeuqnlU51STVlk7ExFqrAUKTV8= Received: from SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) by SN1PR0501MB1837.namprd05.prod.outlook.com (10.163.131.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 22 Jul 2017 19:28:42 +0000 Received: from SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) by SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) with mapi id 15.01.1282.016; Sat, 22 Jul 2017 19:28:42 +0000 From: Ron Bonica To: "intarea-chairs@ietf.org" , "int-area@ietf.org" , Dave Thaler Thread-Topic: New Version Notification for draft-ietf-intarea-probe-02.txt Thread-Index: AQHTAx+1kab6Pop1qU2mmwpsfKlo9qJgOk1g Date: Sat, 22 Jul 2017 19:28:41 +0000 Message-ID: References: <150075128177.20420.2398618711238654604.idtracker@ietfa.amsl.com> In-Reply-To: <150075128177.20420.2398618711238654604.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1837; 7:ao0ICUAtGDsoVkMnswaRfzr8M7jZ6OtfehBxME/JORH/PQ16qGQ5tiP0Wl3dCviI7n+NtfU3qzmid2pcRN7Bmgz4tJkP2Vjt/jhf2obeMbSlI3PuNXr+Ik+j06uxtkqXLebEE67eJKqcEFNUMyRrq8bVX6kiAUmAsAdLFGa7p/lfQ5z1XgbPB+andJE/J2HmYCq+tYshOFx5ZHpNnRju8XKuVU7J7DO9bSuGH4TXTUd7zntKINub+x8O7nO7iVjV6KGzj7uSLi2gTIopY1YnEqgWEGrps5N3ZjIyZ7Oha6cJ5r3mOtG82K2gSeEviNbTs3vY1i7npBrMR3GrjjzT1L+EDc4SNoz3G+6VVfQEUshtjt6nc54nk0P5WnGVqSVUPaXTvw/SaYAExIL7Ff9xfwNIEAr4hj3TMq6Oh8wxo+lxfZ2mXrUNurXQuumd2g62w7RQI3T1qEZDm0mqw7urlbb08k/tnOgpyqZ2V/+V+y60Zw70UmX52paqti/QCMbTnkhsQk6rqXijaHEs80aLvEMtyVIgAybeFB6gXs8CDLQ2DwwCoLiSLLxVfn11oq2hlJgDl0O/+Zca4NNP+ytFKfIgTFktLskA7Aw4rFiijPcG/tQpTRJDLxdMhfo6V2OVWRgr97IHOlWYqb2LThHDF4h9dURrMOWUjNgIw4AKjYnQmaw7Ayfhp263Unv0ArXE+F9rBBM5Z46QTOaePaPC5WKxyxpUT2g51G5RSzSYsfiJ77jIoefMOdLw89hiHt+bguxOHkzC+n1QEP3qzYNLFKGqGK8GndQEc93qYmXh/ao= x-ms-office365-filtering-correlation-id: 96497089-cd76-4a0f-c29b-08d4d137dc9a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR0501MB1837; x-ms-traffictypediagnostic: SN1PR0501MB1837: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(211936372134217)(153496737603132)(18271650672692)(154440410675630); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB1837; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB1837; x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39860400002)(39400400002)(39850400002)(39450400003)(377454003)(377424004)(189002)(13464003)(199003)(25786009)(81166006)(6116002)(3846002)(102836003)(8936002)(53546010)(3660700001)(5660300001)(81156014)(8676002)(3280700002)(966005)(66066001)(230783001)(229853002)(2561002)(189998001)(6506006)(2501003)(77096006)(2950100002)(305945005)(7696004)(7736002)(2906002)(76176999)(99286003)(55016002)(54356999)(106356001)(9686003)(2473003)(50986999)(6306002)(14454004)(1511001)(8666007)(68736007)(33656002)(86362001)(105586002)(53936002)(101416001)(74316002)(34040400001)(2421001)(97736004)(2900100001)(38730400002)(6436002)(478600001)(15650500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1837; H:SN1PR0501MB2062.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2017 19:28:41.9837 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1837 Archived-At: Subject: [Int-area] FW: New Version Notification for draft-ietf-intarea-probe-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 19:28:47 -0000 Rm9sa3MsDQoNCkkgaGF2ZSB1cGRhdGVkIGRyYWZ0LWludGFyZWEtcHJvYmUtMDIgdG8gcmVmbGVj dCBEYXZlIFRoYWxlcicgcyBjb21tZW50Lg0KDQpEYXZlLA0KDQpQbGVhc2UgbG9vayBhdCB0aGUg ZGlmZiB0byBzZWUgb2YgdGhpcyBjaGFuZ2UgcmVmbGVjdHMgeW91ciByZWNvbW1lbmRhdGlvbi4N Cg0KQ2hhaXJzLA0KDQpJZiBEYXZlIHRoaW5rcyB0aGF0IGhpcyBjb21tZW50IGhhcyBiZWVuIGFk ZHJlc3NlZCwgY291bGQgd2UgaW5pdGlhdGUgYSBXRyBsYXN0IGNhbGw/DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDog U2F0dXJkYXksIEp1bHkgMjIsIDIwMTcgOToyMSBQTQ0KVG86IFJvbiBCb25pY2EgPHJib25pY2FA anVuaXBlci5uZXQ+OyBNb2hhbWVkIEJvdWNhZGFpciA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT47IEplbiBMaW5rb3ZhIDxmdXJyeUBnb29nbGUuY29tPjsgUmVqaSBUaG9tYXMgPHJlaml0 aG9tYXNAanVuaXBlci5uZXQ+OyBKLiBMaW5rb3ZhIDxmdXJyeUBnb29nbGUuY29tPjsgQ2hyaXMg TGVuYXJ0IDxjaHJpcy5sZW5hcnRAdmVyaXpvbi5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtaW50YXJlYS1wcm9iZS0wMi50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAyLnR4dCBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJvbiBCb25pY2EgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlDQpSZXZp c2lvbjoJMDINClRpdGxlOgkJUFJPQkU6IEEgVXRpbGl0eSBGb3IgUHJvYmluZyBJbnRlcmZhY2Vz DQpEb2N1bWVudCBkYXRlOgkyMDE3LTA3LTIyDQpHcm91cDoJCWludGFyZWENClBhZ2VzOgkJMTcN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaW50YXJlYS1wcm9iZS8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXBy b2JlLTAyDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLWludGFyZWEtcHJvYmUtMDINCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAyDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBuZXR3b3JrIGRpYWdub3N0 aWMgdG9vbCBjYWxsZWQgUFJPQkUuDQogICBQUk9CRSBpcyBzaW1pbGFyIHRvIFBJTkcsIGluIHRo YXQgaXQgY2FuIGJlIHVzZWQgdG8gdGVzdCB0aGUgc3RhdHVzDQogICBvZiBhIHByb2JlZCBpbnRl cmZhY2UuICBJdCBkaWZmZXJzIGZyb20gUElORyBpbiB0aGF0IGl0IGRvZXMgbm90DQogICByZXF1 aXJlIGJpZGlyZWN0aW9uYWwgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhlIHByb2JpbmcgYW5kIHBy b2JlZA0KICAgaW50ZXJmYWNlcy4gIEFsdGVybmF0aXZlbHksIFBST0JFIHJlcXVpcmVzIGJpZGly ZWN0aW9uYWwgY29ubmVjdGl2aXR5DQogICBiZXR3ZWVuIHRoZSBwcm9iaW5nIGludGVyZmFjZSBh bmQgYSBwcm94eSBpbnRlcmZhY2UuICBUaGUgcHJveHkNCiAgIGludGVyZmFjZSBjYW4gcmVzaWRl IG9uIHRoZSBzYW1lIG5vZGUgYXMgdGhlIHByb2JlZCBpbnRlcmZhY2Ugb3IgaXQNCiAgIGNhbiBy ZXNpZGUgb24gYSBub2RlIHRvIHdoaWNoIHRoZSBwcm9iZWQgaW50ZXJmYWNlIGlzIGRpcmVjdGx5 DQogICBjb25uZWN0ZWQuICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDQ4ODQuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sat Jul 22 21:35:36 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DAB131C18; Sat, 22 Jul 2017 21:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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=microsoft.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 ABHJMN81le52; Sat, 22 Jul 2017 21:35:32 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0120.outbound.protection.outlook.com [104.47.34.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABC6131892; Sat, 22 Jul 2017 21:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xlNc3DNUhypKXEKeb1HhAVDrqURN7k98R9Sl7o4ebQU=; b=EYSWjpsgcUl9UkZZImh9Wpz5NTPYZY1w75En1cvcfUy0nJzZxYpV4WXjqQtm1SP4RObVwbcM6qYRDpDvSvkCCL40NDzP4uesWM4yYD0k8UjT5JQyGfRQTB9EWXMXUmtEggO/LUqRBudSGqmXgHftPSm219LzzqfxihYyLhsNd7Y= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0190.namprd21.prod.outlook.com (10.173.52.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Sun, 23 Jul 2017 04:35:30 +0000 Received: from MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) by MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) with mapi id 15.01.1282.008; Sun, 23 Jul 2017 04:35:30 +0000 From: Dave Thaler To: Ron Bonica , "intarea-chairs@ietf.org" , "int-area@ietf.org" Thread-Topic: New Version Notification for draft-ietf-intarea-probe-02.txt Thread-Index: AQHTAx+1kab6Pop1qU2mmwpsfKlo9qJgOk1ggACYqEA= Date: Sun, 23 Jul 2017 04:35:30 +0000 Message-ID: References: <150075128177.20420.2398618711238654604.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [73.254.202.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0190; 7:YZ/Q2b8TxHWBuXapUvJfWnISdmIjvTrh3ZWB9tfbZ4p32Ahwgc7QCXQiXDkliuxhDq0l8YX5MFZPZWxi9E9g2XC1oUGWJAyxCbthzu2vzGejGvj49lsU57BADzW/bTfqbwjUJiFr5iV+NX0aCsyVImo9kIcXxo2wyI5QSGLCwG9F2VvDWajFYkQQxtTt2NaCFjgkBwb/jNUEqm6r8Bkq6y+U4sqcxtBD5mub3wZ6vO1psfJqwCiQbHFTE6HHHlHWGWWkgWwV3t0/Og/byZEitYKdIMZS1Bp/6cjMaurLfdlVf99PsXbmrj5eibEdM5XJbgabM010gu7kh4xNY5+CAbN7VCqZB+2rWGJpx2/Up5tqJ1NjF/0tylgmmq+UxYHCiT5gh3TcSt+vSl7m7qHBSQPFbTssAdNSWRjtLWL0ndkkHgvzEo1NFbh705S1eJCgg52KinAeSJXLvDn8h3Ldb5cfg4kZgcefeNdDWfxJKZ6Epiv1teMl5/CGUd169ZB5QZwqs8p76uQYzVzJcCyHLtR5r9yy5jUvjav+PAKsOs1RGZy9tagUMOedEr22KI23ooUFWeFHDVn6DkNdJCXMFUQEuOGnhp/WkfQGrckrjwUO5T4G9BzJ6QVWSe1v3LLxTM0vxbnpFJf/0vIm09VFi8vNQQf3qQXS43GBHbeZXyMyQPorrptMw8OgBHilK6nlTnpNZoOV5cMo/HeAnwUrZtsnxFFHmDVq/IBW7eV0aoCcYYNJ/pOHBxegc8/qId2GwkaxrjlJZO/LxH3cgy+mJf14P40+ZMMUAs85irlVSAQvNIRUWQ24GIw209/tEfbQ x-ms-office365-filtering-correlation-id: 5a0a7a54-936c-478c-e7f7-08d4d1844007 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:MWHPR21MB0190; x-ms-traffictypediagnostic: MWHPR21MB0190: x-exchange-antispam-report-test: UriScan:(89211679590171)(189930954265078)(138986009662008)(788757137089)(211936372134217)(153496737603132)(18271650672692)(219752817060721)(154440410675630); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0190; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0190; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39850400002)(39860400002)(39410400002)(39400400002)(47760400005)(377424004)(199003)(189002)(13464003)(377454003)(86362001)(575784001)(966005)(66066001)(102836003)(230783001)(68736007)(25786009)(10090500001)(3660700001)(15650500001)(2906002)(101416001)(3280700002)(81156014)(478600001)(6116002)(2201001)(86612001)(50986999)(3846002)(10290500003)(76176999)(54356999)(106356001)(2501003)(105586002)(81166006)(305945005)(7736002)(8936002)(1941001)(6306002)(7696004)(229853002)(53546010)(2950100002)(97736004)(6246003)(53936002)(6506006)(8990500004)(189998001)(38730400002)(74316002)(55016002)(9686003)(8666007)(5660300001)(5005710100001)(6436002)(33656002)(8676002)(34040400001)(77096006)(14454004)(99286003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0190; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2017 04:35:30.4980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0190 Archived-At: Subject: Re: [Int-area] New Version Notification for draft-ietf-intarea-probe-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 04:35:35 -0000 SXQncyBwYXJ0bHkgdGhlcmUsIGJ1dCBub3QgcXVpdGUgcmVhZHkuDQoNCg0KPiAgIElmIHRoZSBJ bnRlcmZhY2UgSWRlbnRpZmljYXRpb24gT2JqZWN0IGlkZW50aWZpZXMgdGhlIHByb2JlZA0KPiAg IGludGVyZmFjZSBieSBuYW1lLCB0aGUgb2JqZWN0IHBheWxvYWQgY29udGFpbnMgdGhlIGh1bWFu LXJlYWRhYmxlDQo+ICAgaW50ZXJmYWNlIG5hbWUuICBUaGUgaW50ZXJmYWNlIG5hbWUgU0hPVUxE IGJlIHRoZSBmdWxsIE1JQi1JSSBpZk5hbWUsDQo+ICAgaWYgbGVzcyB0aGFuIDI1NSBvY3RldHMs IG9yIHRoZSBmaXJzdCAyNTUgb2N0ZXRzIG9mIHRoZSBpZk5hbWUsIGlmDQo+ICAgdGhlIGlmTmFt ZSBpcyBsb25nZXIuDQoNCkZpcnN0LCB5b3UgYW5kIEkgdGFsa2VkIGFib3V0IGl0IGJlaW5nIHJl cXVpcmVkIHRvIGJlIGFuIGlmTmFtZSwgd2hlcmUgYWJvdmUNCnN0aWxsIGhhcyBhIFNIT1VMRC4g IFNlY29uZCwgaWZOYW1lIGlzIGRlZmluZWQgYXMgYSBEaXNwbGF5U3RyaW5nLCBhbmQNCkRpc3Bs YXlTdHJpbmcgaXMgZGVmaW5lZCBhcyAwLTI1NSBBU0NJSSBjaGFyYWN0ZXJzLCBzbyB0aGUgdHJ1 bmNhdGlvbiBwYXJ0IGlzDQppcnJlbGV2YW50LiAgSSB3b3VsZCByZXBsYWNlIHRoZSBwYXJhZ3Jh cGggd2l0aCBqdXN0Og0KDQogICBJZiB0aGUgSW50ZXJmYWNlIElkZW50aWZpY2F0aW9uIE9iamVj dCBpZGVudGlmaWVzIHRoZSBwcm9iZWQgaW50ZXJmYWNlIGJ5IG5hbWUsDQogICB0aGUgb2JqZWN0 IHBheWxvYWQgTVVTVCBiZSB0aGUgTUlCLUlJIFtSRkMyODYzXSBpZk5hbWUuDQoNCkRhdmUNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb24gQm9uaWNhIFttYWlsdG86 cmJvbmljYUBqdW5pcGVyLm5ldF0NCj4gU2VudDogU2F0dXJkYXksIEp1bHkgMjIsIDIwMTcgMTI6 MjkgUE0NCj4gVG86IGludGFyZWEtY2hhaXJzQGlldGYub3JnOyBpbnQtYXJlYUBpZXRmLm9yZzsg RGF2ZSBUaGFsZXINCj4gPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4NCj4gU3ViamVjdDogRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAyLnR4 dA0KPiANCj4gRm9sa3MsDQo+IA0KPiBJIGhhdmUgdXBkYXRlZCBkcmFmdC1pbnRhcmVhLXByb2Jl LTAyIHRvIHJlZmxlY3QgRGF2ZSBUaGFsZXInIHMgY29tbWVudC4NCj4gDQo+IERhdmUsDQo+IA0K PiBQbGVhc2UgbG9vayBhdCB0aGUgZGlmZiB0byBzZWUgb2YgdGhpcyBjaGFuZ2UgcmVmbGVjdHMg eW91ciByZWNvbW1lbmRhdGlvbi4NCj4gDQo+IENoYWlycywNCj4gDQo+IElmIERhdmUgdGhpbmtz IHRoYXQgaGlzIGNvbW1lbnQgaGFzIGJlZW4gYWRkcmVzc2VkLCBjb3VsZCB3ZSBpbml0aWF0ZSBh IFdHDQo+IGxhc3QgY2FsbD8NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KPiANCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogU2F0dXJkYXksIEp1 bHkgMjIsIDIwMTcgOToyMSBQTQ0KPiBUbzogUm9uIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5l dD47IE1vaGFtZWQgQm91Y2FkYWlyDQo+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsg SmVuIExpbmtvdmEgPGZ1cnJ5QGdvb2dsZS5jb20+OyBSZWppDQo+IFRob21hcyA8cmVqaXRob21h c0BqdW5pcGVyLm5ldD47IEouIExpbmtvdmEgPGZ1cnJ5QGdvb2dsZS5jb20+OyBDaHJpcw0KPiBM ZW5hcnQgPGNocmlzLmxlbmFydEB2ZXJpem9uLmNvbT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWludGFyZWEtcHJvYmUtMDIudHh0DQo+IA0KPiAN Cj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtaW50YXJlYS1wcm9iZS0wMi50eHQg aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5DQo+IHN1Ym1pdHRlZCBieSBSb24gQm9uaWNhIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1pZXRmLWludGFy ZWEtcHJvYmUNCj4gUmV2aXNpb246CTAyDQo+IFRpdGxlOgkJUFJPQkU6IEEgVXRpbGl0eSBGb3Ig UHJvYmluZyBJbnRlcmZhY2VzDQo+IERvY3VtZW50IGRhdGU6CTIwMTctMDctMjINCj4gR3JvdXA6 CQlpbnRhcmVhDQo+IFBhZ2VzOgkJMTcNCj4gVVJMOg0KPiBodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pDQo+IGV0Zi5v cmclMkZpbnRlcm5ldC1kcmFmdHMlMkZkcmFmdC1pZXRmLWludGFyZWEtcHJvYmUtDQo+IDAyLnR4 dCZkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3Q2U4Y2M2OThmYzliOTRi MWYzNQ0KPiA1YjA4ZDRkMTM3ZGRkYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdDMSU3QzAlN0M2MzYNCj4gMzYzNDg1Mjc2MDcxODU1JnNkYXRhPTNsJTJGaTRXQXRiWFoydVZl ZFRkZFhXZ1ZSalBTb0hEQ2NhdlVIMmxwDQo+IExmOTAlM0QmcmVzZXJ2ZWQ9MA0KPiBTdGF0dXM6 DQo+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGZGF0YXRyDQo+IGFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1p bnRhcmVhLQ0KPiBwcm9iZSUyRiZkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNv bSU3Q2U4Y2M2OThmYzliOTRiDQo+IDFmMzU1YjA4ZDRkMTM3ZGRkYiU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0MNCj4gNjM2MzYzNDg1Mjc2MDcxODU1JnNkYXRh PXNZZ05PaXllc3VvZlhsQllqJTJGOUxoWjZ5RHN5eDZWRFM5blYlMkINCj4gMTd1UmJjWSUzRCZy ZXNlcnZlZD0wDQo+IEh0bWxpemVkOg0KPiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmkNCj4gZXRmLm9yZyUyRmh0 bWwlMkZkcmFmdC1pZXRmLWludGFyZWEtcHJvYmUtDQo+IDAyJmRhdGE9MDIlN0MwMSU3Q2R0aGFs ZXIlNDBtaWNyb3NvZnQuY29tJTdDZThjYzY5OGZjOWI5NGIxZjM1NWIwDQo+IDhkNGQxMzdkZGRi JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM2Mw0KPiA0 ODUyNzYwNzE4NTUmc2RhdGE9cmk5c2xqMEpvaXh0ajdrM2NwZDRQUDU2ZWR1R2g5NDE3ODNiUlZB SzltWSUzRA0KPiAmcmVzZXJ2ZWQ9MA0KPiBIdG1saXplZDoNCj4gaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHINCj4g YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLQ0K PiAwMiZkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3Q2U4Y2M2OThmYzli OTRiMWYzNTViMA0KPiA4ZDRkMTM3ZGRkYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzYzNjMNCj4gNDg1Mjc2MDcxODU1JnNkYXRhPUxBSU9KYWhsd3ZFS05Z ZGRmYUo3QVJEbVlaU1IlMkZpRyUyQjNKcVA2a0FHDQo+IERaSSUzRCZyZXNlcnZlZD0wDQo+IERp ZmY6DQo+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3LmkNCj4gZXRmLm9yZyUyRnJmY2RpZmYlM0Z1cmwyJTNEZHJhZnQt aWV0Zi1pbnRhcmVhLXByb2JlLQ0KPiAwMiZkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9z b2Z0LmNvbSU3Q2U4Y2M2OThmYzliOTRiMWYzNTViMA0KPiA4ZDRkMTM3ZGRkYiU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjMNCj4gNDg1Mjc2MDcxODU1 JnNkYXRhPTVaT0p5NkFJUEN4OXBFcno3TXc5NnQ4dTZlQjdnWnZXVUolMkY5ViUyQnENCj4gRG1S dyUzRCZyZXNlcnZlZD0wDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYSBuZXR3b3JrIGRpYWdub3N0aWMgdG9vbCBjYWxsZWQgUFJPQkUuDQo+ICAgIFBST0JF IGlzIHNpbWlsYXIgdG8gUElORywgaW4gdGhhdCBpdCBjYW4gYmUgdXNlZCB0byB0ZXN0IHRoZSBz dGF0dXMNCj4gICAgb2YgYSBwcm9iZWQgaW50ZXJmYWNlLiAgSXQgZGlmZmVycyBmcm9tIFBJTkcg aW4gdGhhdCBpdCBkb2VzIG5vdA0KPiAgICByZXF1aXJlIGJpZGlyZWN0aW9uYWwgY29ubmVjdGl2 aXR5IGJldHdlZW4gdGhlIHByb2JpbmcgYW5kIHByb2JlZA0KPiAgICBpbnRlcmZhY2VzLiAgQWx0 ZXJuYXRpdmVseSwgUFJPQkUgcmVxdWlyZXMgYmlkaXJlY3Rpb25hbCBjb25uZWN0aXZpdHkNCj4g ICAgYmV0d2VlbiB0aGUgcHJvYmluZyBpbnRlcmZhY2UgYW5kIGEgcHJveHkgaW50ZXJmYWNlLiAg VGhlIHByb3h5DQo+ICAgIGludGVyZmFjZSBjYW4gcmVzaWRlIG9uIHRoZSBzYW1lIG5vZGUgYXMg dGhlIHByb2JlZCBpbnRlcmZhY2Ugb3IgaXQNCj4gICAgY2FuIHJlc2lkZSBvbiBhIG5vZGUgdG8g d2hpY2ggdGhlIHByb2JlZCBpbnRlcmZhY2UgaXMgZGlyZWN0bHkNCj4gICAgY29ubmVjdGVkLiAg VGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA0ODg0Lg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Sun Jul 23 01:39:04 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E75BA126B6E; Sun, 23 Jul 2017 01:38:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150079913690.31200.15789177718524647730@ietfa.amsl.com> Date: Sun, 23 Jul 2017 01:38:56 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-probe-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 08:38:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group WG of the IETF. Title : PROBE: A Utility For Probing Interfaces Authors : Ron Bonica Reji Thomas Jen Linkova Chris Lenart Mohamed Boucadair Filename : draft-ietf-intarea-probe-03.txt Pages : 16 Date : 2017-07-23 Abstract: This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-probe-03 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-probe-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-probe-03 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 Sun Jul 23 01:58:53 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8F3126B6E; Sun, 23 Jul 2017 01:58:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150080032493.31228.17037422522539562887@ietfa.amsl.com> Date: Sun, 23 Jul 2017 01:58:44 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-probe-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 08:58:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group WG of the IETF. Title : PROBE: A Utility For Probing Interfaces Authors : Ron Bonica Reji Thomas Jen Linkova Chris Lenart Mohamed Boucadair Filename : draft-ietf-intarea-probe-04.txt Pages : 16 Date : 2017-07-23 Abstract: This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-probe-04 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-probe-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-probe-04 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 Sun Jul 23 02:00:32 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6326A12783A; Sun, 23 Jul 2017 02:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net 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 ZNPQJIZ8JZe2; Sun, 23 Jul 2017 02:00:28 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCFB126B6E; Sun, 23 Jul 2017 02:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RP2SiByb7qkZofXMytiLSUasE+z9HMs+SdNX5y+JBCQ=; b=QnnKAkmvXqrshOyYNFLhODOi4dHeD6BtpaSyUyujvtyVuHcST08k2Q7RF9RtcGrjaKKIk0fGIWdiWRycINjxVg+7ydRIW5YmCh+VBnYj1xi7RhzMZ/rkeh46tjLtzelJlh4YkinTxG6uGgyw86OFYQPF6GsJd3mkAS5ONdTJ76Q= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2083.namprd05.prod.outlook.com (10.164.23.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Sun, 23 Jul 2017 09:00:26 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1304.011; Sun, 23 Jul 2017 09:00:26 +0000 From: Ron Bonica To: Dave Thaler , "intarea-chairs@ietf.org" , "int-area@ietf.org" Thread-Topic: New Version Notification for draft-ietf-intarea-probe-02.txt Thread-Index: AQHTAx+1kab6Pop1qU2mmwpsfKlo9qJgOk1ggACYqECAAErCUA== Date: Sun, 23 Jul 2017 09:00:26 +0000 Message-ID: References: <150075128177.20420.2398618711238654604.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [193.110.55.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2083; 7:0jmb9lG+tc602D2FXqJ1NeI00sd1U/9wXmg3BCEpO1M9gS+RQIuEYqSka5vpmrndEtHBx84ydNZvJtTOOOkGAFiYF72tFdIyabU9djw7W5gF51qyPj7jHRf0sCrkY9IvCYRO7Ykkl9HC1zlFfO63wZt4ZWYjnsv1KLN19vUHuBeL7JQX2UDPUN+7OdXZ6EwUR5hb8iDObdjiSGKcG0OV33TNN43ot2G09bhVif3AoNVmFeSRLMHsOfdgThRceP7RiWDRUu6Kr0qVjywpxTA+wsqdCwBOAob/3IU9dqFEVUQpPNni/lrb6OaFyQ4l98TY1e9RJ92ky9RvxBPJI+TrJRsOVpHeunp4fhAAZUc4NHmJMFlzbfWKKOPigfM9AsMZGEfu7bQubBP5CtyIo4nTti++Z8hGdLxfwRM6clYRDHGa5R1e19VzFNmiSqZ893MQ+6d+JGOCii+LGUSaNvUMnTwT9x9THJS4IboAZSKrnosmH5bENMIQVzlCjEJpm/hrgt9HKN7l/V/ky0uS75I4ph7xccSDs2z0oCTkPdnD57qUmftonsdX/dJYvN7xSP+C8K68qb5UWqNJ7pKJDP0ay2L0vxRSbQHIxQU3aAZDqqAMwT+rvdeVUe34Ms2B3v6X4cSRZE9s87Hk5LTnQ/pQUr3fj/bvcnWfu+iUSX1hldo8a/BwxTajtOkn2Cyh/msigrbMLnf5RhP5vrrzCV9XhqcwNnTqeSMwEy6lfKIbsSGlPbXuiE9ge1IbIlvl8UyLIwNDPFRvVkeuBveQgyUctp7gsotIvoQBmtFhvlh+a1I= x-ms-office365-filtering-correlation-id: e5aaac66-57d3-4f11-e9ed-08d4d1a942c4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB2083; x-ms-traffictypediagnostic: BLUPR0501MB2083: x-exchange-antispam-report-test: UriScan:(89211679590171)(189930954265078)(138986009662008)(788757137089)(211936372134217)(153496737603132)(18271650672692)(219752817060721)(154440410675630); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB2083; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB2083; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39400400002)(39410400002)(39450400003)(39840400002)(377424004)(13464003)(189002)(377454003)(199003)(68736007)(2950100002)(8676002)(76176999)(77096006)(54356999)(106356001)(50986999)(105586002)(229853002)(2906002)(3280700002)(2900100001)(3660700001)(6506006)(97736004)(230783001)(8936002)(189998001)(81156014)(81166006)(66066001)(101416001)(55016002)(99286003)(9686003)(6306002)(74316002)(2561002)(8666007)(6246003)(38730400002)(53936002)(1511001)(5660300001)(2421001)(33656002)(7696004)(2501003)(6436002)(102836003)(6116002)(3846002)(34040400001)(305945005)(7736002)(14454004)(45080400002)(2201001)(53546010)(15650500001)(25786009)(478600001)(966005)(575784001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2083; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2017 09:00:26.5180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2083 Archived-At: Subject: Re: [Int-area] New Version Notification for draft-ietf-intarea-probe-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 09:00:30 -0000 RGF2ZSwNCg0KSSBoYXZlIGp1c3QgbWFkZSB0aGF0IGNoYW5nZSBhbmQgcG9zdGVkIGl0IGluIFZl cnNpb24gMDQuDQoNCkNoYWlycywNCg0KVGhpcyBjbGVhcnMgdGhlIGxhc3QgY29tbWVudCBvZiB3 aGljaCBJIGFtIGF3YXJlLiBXZSBtYXkgYmUgcmVhZHkgZm9yIFdHTEMuDQoNCiAgICAgICAgICAg ICAgICAgICBSb24NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERh dmUgVGhhbGVyIFttYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQuY29tXQ0KPiBTZW50OiBTdW5kYXks IEp1bHkgMjMsIDIwMTcgMTI6MzYgQU0NCj4gVG86IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBl ci5uZXQ+OyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzsgaW50LQ0KPiBhcmVhQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtaW50 YXJlYS1wcm9iZS0wMi50eHQNCj4gDQo+IEl0J3MgcGFydGx5IHRoZXJlLCBidXQgbm90IHF1aXRl IHJlYWR5Lg0KPiANCj4gDQo+ID4gICBJZiB0aGUgSW50ZXJmYWNlIElkZW50aWZpY2F0aW9uIE9i amVjdCBpZGVudGlmaWVzIHRoZSBwcm9iZWQNCj4gPiAgIGludGVyZmFjZSBieSBuYW1lLCB0aGUg b2JqZWN0IHBheWxvYWQgY29udGFpbnMgdGhlIGh1bWFuLXJlYWRhYmxlDQo+ID4gICBpbnRlcmZh Y2UgbmFtZS4gIFRoZSBpbnRlcmZhY2UgbmFtZSBTSE9VTEQgYmUgdGhlIGZ1bGwgTUlCLUlJIGlm TmFtZSwNCj4gPiAgIGlmIGxlc3MgdGhhbiAyNTUgb2N0ZXRzLCBvciB0aGUgZmlyc3QgMjU1IG9j dGV0cyBvZiB0aGUgaWZOYW1lLCBpZg0KPiA+ICAgdGhlIGlmTmFtZSBpcyBsb25nZXIuDQo+IA0K PiBGaXJzdCwgeW91IGFuZCBJIHRhbGtlZCBhYm91dCBpdCBiZWluZyByZXF1aXJlZCB0byBiZSBh biBpZk5hbWUsIHdoZXJlIGFib3ZlDQo+IHN0aWxsIGhhcyBhIFNIT1VMRC4gIFNlY29uZCwgaWZO YW1lIGlzIGRlZmluZWQgYXMgYSBEaXNwbGF5U3RyaW5nLCBhbmQNCj4gRGlzcGxheVN0cmluZyBp cyBkZWZpbmVkIGFzIDAtMjU1IEFTQ0lJIGNoYXJhY3RlcnMsIHNvIHRoZSB0cnVuY2F0aW9uIHBh cnQgaXMNCj4gaXJyZWxldmFudC4gIEkgd291bGQgcmVwbGFjZSB0aGUgcGFyYWdyYXBoIHdpdGgg anVzdDoNCj4gDQo+ICAgIElmIHRoZSBJbnRlcmZhY2UgSWRlbnRpZmljYXRpb24gT2JqZWN0IGlk ZW50aWZpZXMgdGhlIHByb2JlZCBpbnRlcmZhY2UgYnkNCj4gbmFtZSwNCj4gICAgdGhlIG9iamVj dCBwYXlsb2FkIE1VU1QgYmUgdGhlIE1JQi1JSSBbUkZDMjg2M10gaWZOYW1lLg0KPiANCj4gRGF2 ZQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJvbiBCb25p Y2EgW21haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0XQ0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBKdWx5 IDIyLCAyMDE3IDEyOjI5IFBNDQo+ID4gVG86IGludGFyZWEtY2hhaXJzQGlldGYub3JnOyBpbnQt YXJlYUBpZXRmLm9yZzsgRGF2ZSBUaGFsZXINCj4gPiA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPg0K PiA+IFN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQt aWV0Zi1pbnRhcmVhLXByb2JlLTAyLnR4dA0KPiA+DQo+ID4gRm9sa3MsDQo+ID4NCj4gPiBJIGhh dmUgdXBkYXRlZCBkcmFmdC1pbnRhcmVhLXByb2JlLTAyIHRvIHJlZmxlY3QgRGF2ZSBUaGFsZXIn IHMgY29tbWVudC4NCj4gPg0KPiA+IERhdmUsDQo+ID4NCj4gPiBQbGVhc2UgbG9vayBhdCB0aGUg ZGlmZiB0byBzZWUgb2YgdGhpcyBjaGFuZ2UgcmVmbGVjdHMgeW91ciByZWNvbW1lbmRhdGlvbi4N Cj4gPg0KPiA+IENoYWlycywNCj4gPg0KPiA+IElmIERhdmUgdGhpbmtzIHRoYXQgaGlzIGNvbW1l bnQgaGFzIGJlZW4gYWRkcmVzc2VkLCBjb3VsZCB3ZSBpbml0aWF0ZQ0KPiA+IGEgV0cgbGFzdCBj YWxsPw0KPiA+DQo+ID4NCj4gPiBSb24NCj4gPg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4gU2VudDogU2F0dXJkYXksIEp1bHkgMjIsIDIwMTcg OToyMSBQTQ0KPiA+IFRvOiBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0PjsgTW9oYW1l ZCBCb3VjYWRhaXINCj4gPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEplbiBMaW5r b3ZhIDxmdXJyeUBnb29nbGUuY29tPjsNCj4gUmVqaQ0KPiA+IFRob21hcyA8cmVqaXRob21hc0Bq dW5pcGVyLm5ldD47IEouIExpbmtvdmEgPGZ1cnJ5QGdvb2dsZS5jb20+OyBDaHJpcw0KPiA+IExl bmFydCA8Y2hyaXMubGVuYXJ0QHZlcml6b24uY29tPg0KPiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAyLnR4dA0KPiA+DQo+ ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1pbnRhcmVhLXByb2JlLTAy LnR4dCBoYXMgYmVlbg0KPiA+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9uIEJvbmljYSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1lOgkJZHJhZnQt aWV0Zi1pbnRhcmVhLXByb2JlDQo+ID4gUmV2aXNpb246CTAyDQo+ID4gVGl0bGU6CQlQUk9CRTog QSBVdGlsaXR5IEZvciBQcm9iaW5nIEludGVyZmFjZXMNCj4gPiBEb2N1bWVudCBkYXRlOgkyMDE3 LTA3LTIyDQo+ID4gR3JvdXA6CQlpbnRhcmVhDQo+ID4gUGFnZXM6CQkxNw0KPiA+IFVSTDoNCj4g Pg0KPiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnd3dy5pDQo+ID4gZXRmLm9yZyUyRmludGVybmV0LWRyYWZ0cyUyRmRyYWZ0 LWlldGYtaW50YXJlYS1wcm9iZS0NCj4gPg0KPiAwMi50eHQmZGF0YT0wMiU3QzAxJTdDZHRoYWxl ciU0MG1pY3Jvc29mdC5jb20lN0NlOGNjNjk4ZmM5Yjk0YjFmMzUNCj4gPg0KPiA1YjA4ZDRkMTM3 ZGRkYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYNCj4g Pg0KPiAzNjM0ODUyNzYwNzE4NTUmc2RhdGE9M2wlMkZpNFdBdGJYWjJ1VmVkVGRkWFdnVlJqUFNv SERDY2F2VUgybHANCj4gPiBMZjkwJTNEJnJlc2VydmVkPTANCj4gPiBTdGF0dXM6DQo+ID4NCj4g aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZkYXRhdA0KPiA+IHINCj4gPiBhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWll dGYtaW50YXJlYS0NCj4gPg0KPiBwcm9iZSUyRiZkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWlj cm9zb2Z0LmNvbSU3Q2U4Y2M2OThmYzliOTRiDQo+ID4NCj4gMWYzNTViMDhkNGQxMzdkZGRiJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3Qw0KPiA+DQo+IDYzNjM2 MzQ4NTI3NjA3MTg1NSZzZGF0YT1zWWdOT2l5ZXN1b2ZYbEJZaiUyRjlMaFo2eURzeXg2VkRTOW5W JTJCDQo+ID4gMTd1UmJjWSUzRCZyZXNlcnZlZD0wDQo+ID4gSHRtbGl6ZWQ6DQo+ID4gaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ0b29scw0KPiA+IC5pDQo+ID4gZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWludGFyZWEt cHJvYmUtDQo+ID4NCj4gMDImZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20l N0NlOGNjNjk4ZmM5Yjk0YjFmMzU1YjANCj4gPg0KPiA4ZDRkMTM3ZGRkYiU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjMNCj4gPg0KPiA0ODUyNzYwNzE4 NTUmc2RhdGE9cmk5c2xqMEpvaXh0ajdrM2NwZDRQUDU2ZWR1R2g5NDE3ODNiUlZBSzltWSUzRA0K PiA+ICZyZXNlcnZlZD0wDQo+ID4gSHRtbGl6ZWQ6DQo+ID4NCj4gaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdA0KPiA+ IHINCj4gPiBhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWludGFyZWEt cHJvYmUtDQo+ID4NCj4gMDImZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20l N0NlOGNjNjk4ZmM5Yjk0YjFmMzU1YjANCj4gPg0KPiA4ZDRkMTM3ZGRkYiU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjMNCj4gPg0KPiA0ODUyNzYwNzE4 NTUmc2RhdGE9TEFJT0phaGx3dkVLTllkZGZhSjdBUkRtWVpTUiUyRmlHJTJCM0pxUDZrQUcNCj4g PiBEWkklM0QmcmVzZXJ2ZWQ9MA0KPiA+IERpZmY6DQo+ID4NCj4gaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaQ0KPiA+ IGV0Zi5vcmclMkZyZmNkaWZmJTNGdXJsMiUzRGRyYWZ0LWlldGYtaW50YXJlYS1wcm9iZS0NCj4g Pg0KPiAwMiZkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3Q2U4Y2M2OThm YzliOTRiMWYzNTViMA0KPiA+DQo+IDhkNGQxMzdkZGRiJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM2Mw0KPiA+DQo+IDQ4NTI3NjA3MTg1NSZzZGF0YT01 Wk9KeTZBSVBDeDlwRXJ6N013OTZ0OHU2ZUI3Z1p2V1VKJTJGOVYlMkJxDQo+ID4gRG1SdyUzRCZy ZXNlcnZlZD0wDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhIG5ldHdvcmsgZGlhZ25vc3RpYyB0b29sIGNhbGxlZCBQUk9CRS4NCj4gPiAgICBQUk9C RSBpcyBzaW1pbGFyIHRvIFBJTkcsIGluIHRoYXQgaXQgY2FuIGJlIHVzZWQgdG8gdGVzdCB0aGUg c3RhdHVzDQo+ID4gICAgb2YgYSBwcm9iZWQgaW50ZXJmYWNlLiAgSXQgZGlmZmVycyBmcm9tIFBJ TkcgaW4gdGhhdCBpdCBkb2VzIG5vdA0KPiA+ICAgIHJlcXVpcmUgYmlkaXJlY3Rpb25hbCBjb25u ZWN0aXZpdHkgYmV0d2VlbiB0aGUgcHJvYmluZyBhbmQgcHJvYmVkDQo+ID4gICAgaW50ZXJmYWNl cy4gIEFsdGVybmF0aXZlbHksIFBST0JFIHJlcXVpcmVzIGJpZGlyZWN0aW9uYWwgY29ubmVjdGl2 aXR5DQo+ID4gICAgYmV0d2VlbiB0aGUgcHJvYmluZyBpbnRlcmZhY2UgYW5kIGEgcHJveHkgaW50 ZXJmYWNlLiAgVGhlIHByb3h5DQo+ID4gICAgaW50ZXJmYWNlIGNhbiByZXNpZGUgb24gdGhlIHNh bWUgbm9kZSBhcyB0aGUgcHJvYmVkIGludGVyZmFjZSBvciBpdA0KPiA+ICAgIGNhbiByZXNpZGUg b24gYSBub2RlIHRvIHdoaWNoIHRoZSBwcm9iZWQgaW50ZXJmYWNlIGlzIGRpcmVjdGx5DQo+ID4g ICAgY29ubmVjdGVkLiAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA0ODg0Lg0KPiA+DQo+ID4N Cj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4N Cj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Jul 24 23:59:56 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8AC1270A7 for ; Mon, 24 Jul 2017 23:59:54 -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, 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 Iog43uNZiFWR for ; Mon, 24 Jul 2017 23:59:52 -0700 (PDT) Received: from mailrelay32.naist.jp (mailrelay32.naist.jp [163.221.12.152]) by ietfa.amsl.com (Postfix) with ESMTP id 147F9126DC2 for ; Mon, 24 Jul 2017 23:59:51 -0700 (PDT) Received: from mailpost32.naist.jp (mailscan32.naist.jp [163.221.12.157]) by mailrelay32.naist.jp (Postfix) with ESMTP id 1B87024A; Tue, 25 Jul 2017 15:59:50 +0900 (JST) Received: from [IPv6:2001:200:16a:1010:ec23:f810:1955:42af] (unknown [IPv6:2001:200:16a:1010:ec23:f810:1955:42af]) by mailpost32.naist.jp (Postfix) with ESMTPSA id 0737D248; Tue, 25 Jul 2017 15:59:50 +0900 (JST) To: int-area@ietf.org Cc: Marius Georgescu , Szilagyi Szabolcs , Fejes Ferenc , Gabor Lencse From: Gabor Lencse Message-ID: <4515c18c-b2f7-a5c8-8471-299422092e43@is.naist.jp> Date: Tue, 25 Jul 2017 15:59:49 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1808-8.1.0.1062-23216.005 X-TM-AS-Result: No--1.584-7.0-31-10 X-imss-scan-details: No--1.584-7.0-31-10 X-TMASE-MatchedRID: 2w8kyAWNRgRITndh1lLRAco3MPo0IsVYZodCyXXZLezkMnUVL5d0E9oJ bLBq7ybG4IM5D3LsWeyjsPtMTDGc7dEbg9qbbdsc7T+j7/gPsPM7UrmIzxDooFyPhb2isyDdW1Y UUpDyM93aRHMaXpLn/CPFaMkpew2yRbMNi6fpErhomJbPMdjPdNIv4RV84lHTlBIvfA0qYysABi mEpQDQqwswLGS5Or9kBdf1QysO0uTjKsURniXFrX7siEtWY367lxClX9Ey45YFi3R9x/2qQrrU2 qVvXL7Kf7MlQqVWlbR9s58jMuZnrqOfNrZ8RZlLYvBaXC1vHWDRm6N++KG8MAJQ/k29F8v//4Qm Cej9TILfvgsxrno8strkLDt5TjPxsbx3O7bBNSJxgZi4qPpiYOiY+s2L3xQE9dlN5u7m7zqaM5p Ws9hAAZRrl+/Cr2oJpPezQ6N5NDwqLRKxFITytuw8wbnnSw8bHFcmKgYd2lGzJFPSA2GBZTeV4v HOhudk4Ti7mYE8wMUJ7FXE1EDUOBnbBraVaoae8CORMyRE01QuLZ3AqIxH3Jsoi2XrUn/JyeMtM D9QOgCZWTzFmu70VPAXcWxgcD5ysZqEAAHb9pT6C0ePs7A07cKVf7avePdYCiqhiJY/WhAbCUmd S04xtoalKYRD5YT30UaIVaYGTtI+/RPnhFM16Ikz1IPbcrQX4UhPz6v5gIyJ4aofuMUJhw3ylpU MnzfWENb7T9KcFkovfMoFfcFWT9VyTHAYlqHPxCW2rPy/Q5bAvpLE+mvX8g== Archived-At: Subject: [Int-area] MPT Network Layer Multipath Library (draft-lencse-tsvwg-mpt-00.txt) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 06:59:55 -0000 Dear INTAREA WG members, I am Gabor Lencse, the first author of a "-00" draft about the MPT Network Layer Multipath Library: https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-00 It was introduced to the INTAREA WG by our co-author Marius Georgescu at IETF 99. I would like to elaborate on the feedback we received during the presentation. Q1 (David, from Apple): What is the motivation, what you are trying to solve? Why are you trying to use multiple interfaces? A1: Throughput aggregation between two sites. (E.g. between data centers) My answer: The problem to be solved is the following. Due to the design of the TCP/IP protocol stack and its socket interface, even if a device has multiple network interfaces, only one of them can be used for a communications session. And it is a serious limitation many times! Example: Somebody is remotely participating at an IETF meeting using Meetecho on his laptop using WiFi connection (to save costs). When he receives permission to ask a question, the WiFi connection brakes. By the time he manages to switch over to LTE, it is too late. -- According to our tests, MPT can do the switchover seamlessly. How common is this situation? I think many people have smartphones, with WiFi and LTE, and uses WiFi when available in order to save costs. Many of them use free video calls (e.g. by Skype, Viber, WhatsApp, etc.) and would be happy if the free WiFi could be backed up by seamless switchover to LTE during the calls. There are a number of multi path solutions, which shows that the problem is real, but I contend that MPT differs from them and MPT can be more suitable for certain purposes than they for different reasons: - MPTCP [RFC6824] is good, but it is "built together" with TCP. Some applications, e.g. DNS resolution or RTP use UDP. (They can work well with MPT.) - Huawei's GRE Tunnel Bonding Protocol [RFC8157] was designed for this very purpose, but it uses GRE, which is filtered out in many networks. (MPT uses GRE-in-UDP, thus MPT behaves as a standard UDP application in the carrier networks.) - BANANA https://tools.ietf.org/html/draft-leymann-banana-data-encap-00 aims to do bandwidth aggregation, but it also uses GRE and not GRE-in-UDP. And I am not sure if it is able to provide a resilient tunnel (that is switching over from a given underlying path to another one). - Load Sharing for SCTP https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14 is also a multipath solution, but it is very specific. MPT provides an IP tunnel, which can be used for any purpose. All in all, I could not find any other solutions that would provide such flexible, multipurpose IP tunnel (providing both IPv4 and IPv6), which is both resilient and can aggregate the transmission capacity of several (even high number of) underlying paths, and which can be used in any networks, where UDP is carried over either IPv4 or IPv6. I would be interested in hearing about any similar solutions. And I would like to receive your feedback about MPT. All your questions, comments, suggestions, etc. Best regards, Gabor From nobody Tue Jul 25 04:03:56 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58F0131BBF for ; Tue, 25 Jul 2017 04:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.1 X-Spam-Level: X-Spam-Status: No, score=-7.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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=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 0NUWUfVnTnf1 for ; Tue, 25 Jul 2017 04:03:50 -0700 (PDT) Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.13]) (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 D63A0124E15 for ; Tue, 25 Jul 2017 04:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500980628; 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=AIF/tqNpXiaqGm/8Oq0qpyw3yLclHqfiqb7wbXg6OHg=; b=2BiBB5NstyEJJYT07necKlCNTVHfPI3mcxeV8HdCCvEZYahnR49HoUUHLKOxWpzf JbMC1SA/L6sYsrbOxT3qLYiaLYic2+UQvGNoZRrxRi7JD2HpACVWNxSXdOkXmuzy /6wizqcORH9EgvsaeH3xMLQQFnMtrq/8SnZERknTSiOXR4d7SvrB89npl6GjMS7S dx2b5446AYgMA4KIegudACBAYve8gwmhTDm/jwwmbt9jf6ARykc/fSS/HyOuUKWg PSdTRTNcwURiTHwitS4zevc5zggzfLKNwOPG9wpkZ84Ja+jk0m5AQ24HCqhv4Gt8 0Kow7nQJMGdZ+NTQ+X74gg==; Received: from 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-in3.euro.apple.com (Symantec Mail Security) with SMTP id 4D.99.07437.49527795; Tue, 25 Jul 2017 12:03:48 +0100 (BST) X-AuditID: 1148940d-ed6789c000001d0d-0b-597725944472 Received: from crk-phonehomebzp-sz03.euro.apple.com ( [17.72.133.83]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id F4.37.07255.39527795; Tue, 25 Jul 2017 12:03:47 +0100 (BST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4PFMS95WW9ZkbhXzAXW+pA)" Received: from pc14.home (ABordeaux-651-1-87-179.w90-5.abo.wanadoo.fr [90.5.130.179]) by phonehome3.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OTN002X782AVL30@phonehome3.euro.apple.com>; Tue, 25 Jul 2017 12:03:47 +0100 (IST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <3ADAA55B-AED3-47E1-8BF9-A69700F40006@apple.com> Date: Tue, 25 Jul 2017 13:03:34 +0200 In-reply-to: <4515c18c-b2f7-a5c8-8471-299422092e43@is.naist.jp> Cc: int-area@ietf.org, Szilagyi Szabolcs , Marius Georgescu , Fejes Ferenc To: Gabor Lencse References: <4515c18c-b2f7-a5c8-8471-299422092e43@is.naist.jp> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42IRdDLn0Z2iWh5p8O8As8WEtnfsFk+X/GC3 uDHrJovF86v3mCxOLv7M7sDqsWTJTyaPdx0/2D3e3X7I4vHmxFI2j2VHFjAHsEZx2aSk5mSW pRbp2yVwZTy538dWsD2nYuqkLcwNjL+juhg5OSQETCSW7f/H3sXIxSEksIhJ4sDXpcxdjBxg iVnbKiHihxgl3k1cywLSwCsgKPFj8j0wm1kgTKL/7lxmEFtIYAuTxIl2RhBbWEBaouvCXVaQ OWwCWhIH1hiBmLwCNhI9n7QgKmIl1k95BDaFRUBVYvH2F2CdnAL2EheXrmABWcsssIRRYvGD g2AJEQE1ieddT5ggVtlJtO44yAxxv6zErdmXmEEaJASus0ns+TeVaQKj0Cwkp85CciqErSXx /VErUJwDyJaXOHheFiKsKfHs3id2CFtb4sm7C6wLGNlWMYrnJmbm6GbmGeullhbl6yUWFOSk 6iXn525iBEWTxxTeHYzXDxoeYhTgYFTi4ZVh844UYk0sK67MBQYbB7OSCO9LpvJIId6UxMqq 1KL8+KLSnNTiQ4zSHCxK4rwmpfKRQgLpiSWp2ampBalFMFkmDk6pBkaVd5M+VYSzKXR/Fl/x 56KcifJ6y6mTuSZfyNSVDO8IZp3z/5/I1z2rpgpYWp/8s/qzZfqCgrWn4vZ8twt2Tt5wTdr9 zpMFRtVN4iwiLYyNk3jcAl2evNEITihg7ZHZMufDrhVZbuF/nC9YrDBm2cbb+1Evx3+btWPc ZS81U9+Ht3kvvRQvXqnEUpyRaKjFXFScCADVMnxUogIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUi6NEarDtZtTzSoGGnjcWEtnfsFk+X/GC3 uDHrJovF86v3mCxOLv7M7sDqsWTJTyaPdx0/2D3e3X7I4vHmxFI2j2VHFjAHsEZx2aSk5mSW pRbp2yVwZTy538dWsD2nYuqkLcwNjL+juhg5OCQETCRmbavsYuTiEBI4xCjxbuJali5GTg5e AUGJH5PvgdnMAmES/XfnMoPYQgJbmCROtDOC2MIC0hJdF+6ygsxhE9CSOLDGCMTkFbCR6Pmk BVERK7F+yiOwKSwCqhKLt78A6+QUsJe4uHQFC8haZoEljBKLHxwES4gIqEk873rCBLHKTqJ1 x0GwtRICshK3Zl9insDIPwvJdbOQXAdha0l8f9QKFOcAsuUlDp6XhQhrSjy794kdwtaWePLu AusCRrZVjKJFqTmJlUZ6qaVF+XqJBQU5qXrJ+bmbGEHB72TOs4Px1UHDQ4wCHIxKPLxrRcsj hVgTy4orc4HhxMGsJML7kgkoxJuSWFmVWpQfX1Sak1p8iFGag0VJnHdudmGkkEB6Yklqdmpq QWoRTJaJg1OqgZFzOu+H6pudYbcfvr8/6/7U/0emhAvv0W7ec+foSalT5ZUCn8Xuia1+vutw y5a7JYyXFjNXli+Zx/xToi7y6BbdFpUf6d1fDCW/+GYcy62brrsl9zlHgfH/fKFFa6rdVb74 9kvva3pU4Me/8Fh/1c1zs3fOaytTsz9dw7qk+caPD7usrj9Xyp2sxFKckWioxVxUnAgAl8Kp GnoCAAA= Archived-At: Subject: Re: [Int-area] MPT Network Layer Multipath Library (draft-lencse-tsvwg-mpt-00.txt) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 11:03:55 -0000 --Boundary_(ID_4PFMS95WW9ZkbhXzAXW+pA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Gabor, I don't think the problem space is quite as simple: 1) Many content providers will return different DNS results based on where you're querying from. For this reason you need to perform DNS and your transport protocol on the same interface to be efficient. 2) Congestion properties can differ greatly per link, for that reason you'll need to have separate per-link congestion control to avoid starving one link or risking congestion collapse on the other. For these reasons, transport-layer solutions like MPTCP or MPQUIC are preferable: you perform DNS on your favorite link and connect there, the server provides you with extra addresses and the client host can then open up different paths via link selection or source address selection. Don't get me wrong, in general I'm a very big proponent of using IP as our narrow waist to allow innovation at the above and below layers. However, in this case I don't think you can build a safe and efficient solution exclusively at the IP layer, because what you're trying to improve is transport-layer performance (again the only motivation I see in the draft is "throughput" and "resilience" [Abstract] which I don't see as main goals for a networking stack, latency is still the first priority [1]. You may have solved these issues, but I couldn't find that in the draft. For example, in draft-lencse-tsvwg-mpt-00 section 5.2, you mention that "(E.g. WiFi is used for Torrent traffic and LTE is used for VoIP calls.)" without specifying how the IP layer can differentiate these various types of traffic. And when it comes to per-packet mappings, sending a percentage of packets on various links and then adding delay to reorder at the MPT server will add buffer bloat to match the worst link. I may be missing something, but after reading the draft I think this proposal will be harmful to users as it exclusively focuses on throughput at the expense of many other priorities. While it's commonly assumed we can solve any problem by introducing an extra level of indirection or IP headers, I don't think tunnels are the solution to all woes. [1] http://www.stuartcheshire.org/rants/latency.html Thanks, David Schinazi > On Jul 25, 2017, at 08:59, Gabor Lencse wrote: > > Dear INTAREA WG members, > > I am Gabor Lencse, the first author of a "-00" draft about the MPT Network Layer Multipath Library: https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-00 > > It was introduced to the INTAREA WG by our co-author Marius Georgescu at IETF 99. > > I would like to elaborate on the feedback we received during the presentation. > > Q1 (David, from Apple): What is the motivation, what you are trying to solve? Why are you trying to use multiple interfaces? > > A1: Throughput aggregation between two sites. (E.g. between data centers) > > My answer: > > The problem to be solved is the following. Due to the design of the TCP/IP protocol stack and its socket interface, even if a device has multiple network interfaces, only one of them can be used for a communications session. And it is a serious limitation many times! > > Example: Somebody is remotely participating at an IETF meeting using Meetecho on his laptop using WiFi connection (to save costs). When he receives permission to ask a question, the WiFi connection brakes. By the time he manages to switch over to LTE, it is too late. -- According to our tests, MPT can do the switchover seamlessly. > > How common is this situation? I think many people have smartphones, with WiFi and LTE, and uses WiFi when available in order to save costs. Many of them use free video calls (e.g. by Skype, Viber, WhatsApp, etc.) and would be happy if the free WiFi could be backed up by seamless switchover to LTE during the calls. > > There are a number of multi path solutions, which shows that the problem is real, but I contend that MPT differs from them and MPT can be more suitable for certain purposes than they for different reasons: > > - MPTCP [RFC6824] is good, but it is "built together" with TCP. Some applications, e.g. DNS resolution or RTP use UDP. (They can work well with MPT.) > > - Huawei's GRE Tunnel Bonding Protocol [RFC8157] was designed for this very purpose, but it uses GRE, which is filtered out in many networks. (MPT uses GRE-in-UDP, thus MPT behaves as a standard UDP application in the carrier networks.) > > - BANANA https://tools.ietf.org/html/draft-leymann-banana-data-encap-00 aims to do bandwidth aggregation, but it also uses GRE and not GRE-in-UDP. And I am not sure if it is able to provide a resilient tunnel (that is switching over from a given underlying path to another one). > > - Load Sharing for SCTP https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14 is also a multipath solution, but it is very specific. MPT provides an IP tunnel, which can be used for any purpose. > > All in all, I could not find any other solutions that would provide such flexible, multipurpose IP tunnel (providing both IPv4 and IPv6), which is both resilient and can aggregate the transmission capacity of several (even high number of) underlying paths, and which can be used in any networks, where UDP is carried over either IPv4 or IPv6. I would be interested in hearing about any similar solutions. > > And I would like to receive your feedback about MPT. All your questions, comments, suggestions, etc. > > Best regards, > > Gabor > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Boundary_(ID_4PFMS95WW9ZkbhXzAXW+pA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi Gabor,

I= don't think the problem space is quite as simple:

1) Many content = providers will return different DNS results based on where you're = querying from. For this reason you need to perform DNS and your = transport protocol on the same interface to be efficient.
2) Congestion properties can differ greatly per link, for = that reason you'll need to have separate per-link congestion control to = avoid starving one link or risking congestion collapse on the = other.

For = these reasons, transport-layer solutions like MPTCP or MPQUIC are = preferable: you perform DNS on your favorite link and connect there, the = server provides you with extra addresses and the client host can then = open up different paths via link selection or source address = selection.

Don't= get me wrong, in general I'm a very big proponent of using IP as our = narrow waist to allow innovation at the above and below layers. However, = in this case I don't think you can build a safe and efficient solution = exclusively at the IP layer, because what you're trying to improve is = transport-layer performance (again the only motivation I see in the = draft is "throughput" and "resilience" [Abstract] which I don't see as = main goals for a networking stack, latency is still the first priority = [1].

You may = have solved these issues, but I couldn't find that in the draft. For = example, in draft-lencse-tsvwg-mpt-00 section 5.2, you mention that = "(E.g. WiFi is used for Torrent traffic and LTE is used for VoIP = calls.)" without specifying how the IP layer can differentiate these = various types of traffic. And when it comes to per-packet mappings, = sending a percentage of packets on various links and then adding delay = to reorder at the MPT server will add buffer bloat to match the worst = link.

I may be = missing something, but after reading the draft I think this proposal = will be harmful to users as it exclusively focuses on throughput at the = expense of many other priorities.
While it's = commonly assumed we can solve any problem by introducing an extra level = of indirection or IP headers, I don't think tunnels are the = solution to all woes.

[1] http://www.stuartcheshire.org/rants/latency.html

Thanks,
David Schinazi


On Jul 25, 2017, at 08:59, Gabor Lencse <gabor-l@is.naist.jp>= wrote:

Dear INTAREA WG members,

I am = Gabor Lencse, the first author of a "-00" draft about the MPT Network = Layer Multipath Library: https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-00

It was introduced to the INTAREA WG by our = co-author Marius Georgescu at IETF 99.

I = would like to elaborate on the feedback we received during the = presentation.

Q1 (David, from Apple): What = is the motivation, what you are trying to solve? Why are you trying to = use multiple interfaces?

A1: Throughput = aggregation between two sites. (E.g. between data centers)

My answer:

The = problem to  be solved is the following. Due to the design of the = TCP/IP protocol stack and its socket interface, even if a device has = multiple network interfaces, only one of them can be used for a = communications session. And it is a serious limitation many times!

Example: Somebody is remotely participating at = an IETF meeting using Meetecho on his laptop using WiFi connection (to = save costs). When he receives permission to ask a question, the WiFi = connection brakes. By the time he manages to switch over to LTE, it is = too late.  -- According to our tests, MPT can do the switchover = seamlessly.

How common is this situation? I = think many people have smartphones, with WiFi and LTE, and uses WiFi = when available in order to save costs. Many of them use free video calls = (e.g. by Skype, Viber, WhatsApp, etc.) and would be happy if the free = WiFi could be backed up by seamless switchover to LTE during the = calls.

There are a number of multi path = solutions, which shows that the problem is real, but I contend that MPT = differs from them and MPT can be more suitable for certain purposes than = they for different reasons:

- MPTCP = [RFC6824] is good, but it is "built together" with TCP. Some = applications, e.g. DNS resolution or RTP use UDP. (They can work well = with MPT.)

-  Huawei's GRE Tunnel = Bonding Protocol [RFC8157] was designed for this very purpose, but it = uses GRE, which is filtered out in many networks. (MPT uses GRE-in-UDP, = thus MPT behaves as a standard UDP application in the carrier = networks.)

- BANANA https://tools.ietf.org/html/draft-leymann-banana-data-encap-00<= /a> aims to do bandwidth aggregation, but it also uses GRE and not = GRE-in-UDP. And I am not sure if it is able to provide a resilient = tunnel (that is switching over from a given underlying path to another = one).

- Load Sharing for SCTP https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-1= 4 is also a multipath solution, but it is very specific. MPT = provides an IP tunnel, which can be used for any purpose.

All in all, I could not find any other = solutions that would provide such flexible, multipurpose IP tunnel = (providing both IPv4 and IPv6), which is both resilient and can = aggregate the transmission capacity of several (even high number of) = underlying paths, and which can be used in any networks, where UDP is = carried over either IPv4 or IPv6. I would be interested in hearing about = any similar solutions.

And I would like to = receive your feedback about MPT. All your questions, comments, = suggestions, etc.

Best regards,

Gabor


_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

= --Boundary_(ID_4PFMS95WW9ZkbhXzAXW+pA)-- From nobody Tue Jul 25 20:56:46 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83866128AB0 for ; Tue, 25 Jul 2017 20:56:44 -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 d_PSO0KJk6Jc for ; Tue, 25 Jul 2017 20:56:41 -0700 (PDT) Received: from mailrelay32.naist.jp (mailrelay32.naist.jp [IPv6:2001:200:16a:d26::152]) by ietfa.amsl.com (Postfix) with ESMTP id 409F1126557 for ; Tue, 25 Jul 2017 20:56:40 -0700 (PDT) Received: from mailpost32.naist.jp (mailscan32.naist.jp [163.221.12.157]) by mailrelay32.naist.jp (Postfix) with ESMTP id 11A195FE; Wed, 26 Jul 2017 12:56:38 +0900 (JST) Received: from [IPv6:2001:200:16a:1010:ec23:f810:1955:42af] (unknown [IPv6:2001:200:16a:1010:ec23:f810:1955:42af]) by mailpost32.naist.jp (Postfix) with ESMTPSA id F187B5FC; Wed, 26 Jul 2017 12:56:37 +0900 (JST) To: int-area@ietf.org References: <4515c18c-b2f7-a5c8-8471-299422092e43@is.naist.jp> <3ADAA55B-AED3-47E1-8BF9-A69700F40006@apple.com> Cc: David Schinazi , Gabor Lencse , Szilagyi Szabolcs , Marius Georgescu , Fejes Ferenc From: Gabor Lencse Message-ID: <18bbeaa7-a7a9-60f4-090d-bc0ca4b1670c@is.naist.jp> Date: Wed, 26 Jul 2017 12:56:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3ADAA55B-AED3-47E1-8BF9-A69700F40006@apple.com> Content-Type: multipart/alternative; boundary="------------76928BA6FD7CC4B43EF6DFDF" X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1808-8.1.0.1062-23218.003 X-TM-AS-Result: No--20.256-7.0-31-10 X-imss-scan-details: No--20.256-7.0-31-10 X-TMASE-MatchedRID: tRcutRVVeFmhMED/6x0ppshGzBIb6Jpryjcw+jQixVhF0vHVf0FWQDMV Y5itbDoDLVdieW1lpmcwPc056E+qJnGGEKfcJAliJoswqQpTupzx5KZMlKYS/dIv4RV84lHTV6K WY8jugmXcv5ZWOrA+iskedzoet6eP5pZ/l0Abezm6lIBLPjRk6Res/RxhysDblxClX9Ey45Ztv4 +aU05V+/rGSMtEVYY9tyJkrp9ElhMcXqYXbVvibWwvoWYqMw6Bk3rl+MaNgxDSde/CNbaZJe5an ar5bqNu4NbWfxcgpeXFxDoHLv3qJDkKSFihQCWxXmtgg1SwHyMAKzYLecaUGCTbbsi+pqSFBNbO kII96c0UQ7CeFrI30YXxGAZtNHQZdgvRpLBFObDpUhdxxt+sdQPZZctd3P4Bgs2Y99lqecyna6U 74e0+qG0LQpmjB9pjPavUKmAA72f2EY6UlCIXig9FV6kNYiPHMSjlkes0Ka/NUTeBBPKQKg2Y8x yy93kWuEworDHWZ6b1oMtVOTRE4ppdRSjt6VGPn7/cTzCWv4OFtdXfaNUsul7OZ6hrwwnzleulF 3zlkFg3ufkyVLUl7YM0UI/wsMx+x2fPo79As2C+DiWkn7vel0j2sPWKvtn0ojQrbrPpzzphugTj /RcylqtYXNbyT8atVZOEYEsHFBsA/9TZj3+cM/tAPEfr8cPbxZQoGMRGhhOB01driWko20S/boW SGMtdmIwEEdLVZ0ny6jv8ITOMb+XeVMmB/JqBRdfDoOsKexv5wpfrIJDXe8kv13FaE99hM/dZg2 GSzOXzb5kmgp405ST9NCas8YSAD5YpuZ75ik5ccQ8eam5EfRRFJJyf5BJetOt1ofVlaoJ5WX6jI 4oJVxir9Ak4ADTtSQQofLPVHA1nPQAAZZiCoqDmii8RYWYpF5zaa6d2vTb9WfTyK/HCUMyAYCu6 BJNHAJ2WJuKZfv0QRFSW+P8kjQ== Archived-At: Subject: Re: [Int-area] MPT Network Layer Multipath Library (draft-lencse-tsvwg-mpt-00.txt) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 03:56:44 -0000 This is a multi-part message in MIME format. --------------76928BA6FD7CC4B43EF6DFDF Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear David, Thank you very much for your answer. Please find my answers inline. On 7/25/2017 8:03 PM, David Schinazi wrote: > Hi Gabor, > > I don't think the problem space is quite as simple: > > 1) Many content providers will return different DNS results based on > where you're querying from. For this reason you need to perform DNS > and your transport protocol on the same interface to be efficient. You are completely right. Unfortunately the deployment scenarios are completely missing from the draft. I plan to include them into version "-01". As for the current examples, I would call the applicable scenario as "MPT service provider scenario", which is the following: - The client side MPT server is executed on my laptop (or smartphone). - The service provider side MPT server is executed by an "MPT service provider". (*) - An MPT tunnel is set up between the two above MPT servers using all the available paths (WiFi, LTE) - Client software (in our case Meetecho, Skype, Viber, etc.) uses the tunnel IP for all communication (both for sending DNS queries and VoIP data). (*) In my case it would be an MPT server at NAIST. In general, there are two conditions: (1) it should be close to the client (2) it should have high speed Internet connection Of course, what I can achieve is not as good as if I would sit in my room at NAIST and use the Gigabit Ethernet connection, but the reliability of the solution is better than that of using WiFi only, and the price of the solution is less than that of using LTE only. In general, an "MPT service provider" can be an independent provider or some ISPs also may provide this service. Multipath resilience and throughput aggregation apply only to the section between the two MPT servers. This is the most problematic part by means of unreliability and cost. Other possible scenarios would include MPT servers at data center sites interconnected by several independent high speed paths... > 2) Congestion properties can differ greatly per link, for that reason > you'll need to have separate per-link congestion control to avoid > starving one link or risking congestion collapse on the other. Yes, this is another issue, which has not been addressed yet. I add this also to the "ToDo" list. > For these reasons, transport-layer solutions like MPTCP or MPQUIC are > preferable: you perform DNS on your favorite link and connect there, > the server provides you with extra addresses and the client host can > then open up different paths via link selection or source address > selection. The problem with this solution is that MPTCP provides only TCP. Its retransmission mechanism is probably disadvantageous for real-time traffic. (Sometimes loss may be better than very long delay, which applies for all the following data.) > Don't get me wrong, in general I'm a very big proponent of using IP as > our narrow waist to allow innovation at the above and below layers. > However, in this case I don't think you can build a safe and efficient > solution exclusively at the IP layer, because what you're trying to > improve is transport-layer performance (again the only motivation I > see in the draft is "throughput" and "resilience" [Abstract] which I > don't see as main goals for a networking stack, latency is still the > first priority [1]. Whereas I agree with the main message of [1], I would say that Delay, Throughput and Resilience (or Reliability) are all important and none of them may be neglected. (Since the time when we used modems, there was a huge development in the transmission rates, and it has its results: currently about 75% of the Internet traffic is video and it is increasing. -- I could not dream of video calling of my wife from Japan to Hungary without this development.) > You may have solved these issues, but I couldn't find that in the > draft. For example, in draft-lencse-tsvwg-mpt-00 section 5.2, you > mention that "(E.g. WiFi is used for Torrent traffic and LTE is used > for VoIP calls.)" without specifying how the IP layer can > differentiate these various types of traffic. Section 5.2 is still "Under construction". Our idea is that the usual 5-tuple (source IP address, source port number, destination IP address, destination port number, and protocol number (TCP or UDP)) could be used for the identification of the flows. (Yes, this method uses more than just IP layer header information. Perhaps calling MPT as "Network Layer Multipath" solution is questionable. By calling MPT so, we would like to emphasize that we use a tunnel IP layer over which both TCP or UDP may be used.) But the details are missing. (E.g. how to describe the flows, how they can be efficiently identified, etc.) > And when it comes to per-packet mappings, sending a percentage of > packets on various links and then adding delay to reorder at the MPT > server will add buffer bloat to match the worst link. Our experience shows that it is worth aggregating only the capacity of the links with similar speeds and delay. Otherwise it is worth sending the traffic through the better link and use the other link as "spinning reserve" for resiliency purposes, if the better link fails. > I may be missing something, but after reading the draft I think this > proposal will be harmful to users as it exclusively focuses on > throughput at the expense of many other priorities. > While it's commonly assumed we can solve any problem by introducing an > extra level of indirection or IP headers, I don't think tunnels are > the solution to all woes. > > [1] http://www.stuartcheshire.org/rants/latency.html > > Thanks, > David Schinazi > Whereas I try to "defend" our draft, and I hope that our conversation will result in a better draft, which will be useful for many people, I also admit, that there may be fundamental flaws in our concept, which we do not see. I honestly thank you for pointing them out in the past and in the future, too. And if the final outcome will be that we shell abandon the draft, I will still be grateful to you for saving us possibly years spent with something unusable. So, I really appreciate your reply and wait for further comments from you and from anyone else interested in our draft. Best regards, Gabor > >> On Jul 25, 2017, at 08:59, Gabor Lencse > > wrote: >> >> Dear INTAREA WG members, >> >> I am Gabor Lencse, the first author of a "-00" draft about the MPT >> Network Layer Multipath Library: >> https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-00 >> >> It was introduced to the INTAREA WG by our co-author Marius Georgescu >> at IETF 99. >> >> I would like to elaborate on the feedback we received during the >> presentation. >> >> Q1 (David, from Apple): What is the motivation, what you are trying >> to solve? Why are you trying to use multiple interfaces? >> >> A1: Throughput aggregation between two sites. (E.g. between data centers) >> >> My answer: >> >> The problem to be solved is the following. Due to the design of the >> TCP/IP protocol stack and its socket interface, even if a device has >> multiple network interfaces, only one of them can be used for a >> communications session. And it is a serious limitation many times! >> >> Example: Somebody is remotely participating at an IETF meeting using >> Meetecho on his laptop using WiFi connection (to save costs). When he >> receives permission to ask a question, the WiFi connection brakes. By >> the time he manages to switch over to LTE, it is too late. -- >> According to our tests, MPT can do the switchover seamlessly. >> >> How common is this situation? I think many people have smartphones, >> with WiFi and LTE, and uses WiFi when available in order to save >> costs. Many of them use free video calls (e.g. by Skype, Viber, >> WhatsApp, etc.) and would be happy if the free WiFi could be backed >> up by seamless switchover to LTE during the calls. >> >> There are a number of multi path solutions, which shows that the >> problem is real, but I contend that MPT differs from them and MPT can >> be more suitable for certain purposes than they for different reasons: >> >> - MPTCP [RFC6824] is good, but it is "built together" with TCP. Some >> applications, e.g. DNS resolution or RTP use UDP. (They can work well >> with MPT.) >> >> - Huawei's GRE Tunnel Bonding Protocol [RFC8157] was designed for >> this very purpose, but it uses GRE, which is filtered out in many >> networks. (MPT uses GRE-in-UDP, thus MPT behaves as a standard UDP >> application in the carrier networks.) >> >> - BANANA >> https://tools.ietf.org/html/draft-leymann-banana-data-encap-00 aims >> to do bandwidth aggregation, but it also uses GRE and not GRE-in-UDP. >> And I am not sure if it is able to provide a resilient tunnel (that >> is switching over from a given underlying path to another one). >> >> - Load Sharing for SCTP >> https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14 is >> also a multipath solution, but it is very specific. MPT provides an >> IP tunnel, which can be used for any purpose. >> >> All in all, I could not find any other solutions that would provide >> such flexible, multipurpose IP tunnel (providing both IPv4 and IPv6), >> which is both resilient and can aggregate the transmission capacity >> of several (even high number of) underlying paths, and which can be >> used in any networks, where UDP is carried over either IPv4 or IPv6. >> I would be interested in hearing about any similar solutions. >> >> And I would like to receive your feedback about MPT. All your >> questions, comments, suggestions, etc. >> >> Best regards, >> >> Gabor >> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > --------------76928BA6FD7CC4B43EF6DFDF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Dear David,

Thank you very much for your answer. Please find my answers inline.

On 7/25/2017 8:03 PM, David Schinazi wrote:
Hi Gabor,

I don't think the problem space is quite as simple:

1) Many content providers will return different DNS results based on where you're querying from. For this reason you need to perform DNS and your transport protocol on the same interface to be efficient.

You are completely right. Unfortunately the deployment scenarios are completely missing from the draft. I plan to include them into version "-01".

As for the current examples, I would call the applicable scenario as "MPT service provider scenario", which is the following:
- The client side MPT server is executed on my laptop (or smartphone).
- The service provider side MPT server is executed by an "MPT service provider". (*)
- An MPT tunnel is set up between the two above MPT servers using all the available paths (WiFi, LTE)
- Client software (in our case Meetecho, Skype, Viber, etc.) uses the tunnel IP for all communication (both for sending DNS queries and VoIP data).

(*) In my case it would be an MPT server at NAIST. In general, there are two conditions:
(1) it should be close to the client
(2) it should have high speed Internet connection

Of course, what I can achieve is not as good as if I would sit in my room at NAIST and use the Gigabit Ethernet connection, but the reliability of the solution is better than that of using WiFi only, and the price of the solution is less than that of using LTE only.

In general, an "MPT service provider" can be an independent provider or some ISPs also may provide this service. Multipath resilience and throughput aggregation apply only to the section between the two MPT servers. This is the most problematic part by means of unreliability and cost.


Other possible scenarios would include MPT servers at data center sites interconnected by several independent high speed paths...

2) Congestion properties can differ greatly per link, for that reason you'll need to have separate per-link congestion control to avoid starving one link or risking congestion collapse on the other.

Yes, this is another issue, which has not been addressed yet. I add this also to the "ToDo" list.

For these reasons, transport-layer solutions like MPTCP or MPQUIC are preferable: you perform DNS on your favorite link and connect there, the server provides you with extra addresses and the client host can then open up different paths via link selection or source address selection.

The problem with this solution is that MPTCP provides only TCP. Its retransmission mechanism is probably disadvantageous for real-time traffic. (Sometimes loss may be better than very long delay, which applies for all the following data.)

Don't get me wrong, in general I'm a very big proponent of using IP as our narrow waist to allow innovation at the above and below layers. However, in this case I don't think you can build a safe and efficient solution exclusively at the IP layer, because what you're trying to improve is transport-layer performance (again the only motivation I see in the draft is "throughput" and "resilience" [Abstract] which I don't see as main goals for a networking stack, latency is still the first priority [1].

Whereas I agree with the main message of [1], I would say that Delay, Throughput and Resilience (or Reliability) are all important and none of them may be neglected. (Since the time when we used modems, there was a huge development in the transmission rates, and it has its results: currently about 75% of the Internet traffic is video and it is increasing. -- I could not dream of video calling of my wife from Japan to Hungary without this development.)

You may have solved these issues, but I couldn't find that in the draft. For example, in draft-lencse-tsvwg-mpt-00 section 5.2, you mention that "(E.g. WiFi is used for Torrent traffic and LTE is used for VoIP calls.)" without specifying how the IP layer can differentiate these various types of traffic.

Section 5.2 is still "Under construction".

Our idea is that the usual 5-tuple (source IP address, source port number, destination IP address, destination port number, and protocol number (TCP or UDP)) could be used for the identification of the flows. (Yes, this method uses more than just IP layer header information. Perhaps calling MPT as "Network Layer Multipath" solution is questionable. By calling MPT so, we would like to emphasize that we use a tunnel IP layer over which both TCP or UDP may be used.) But the details are missing. (E.g. how to describe the flows, how they can be efficiently identified, etc.)

And when it comes to per-packet mappings, sending a percentage of packets on various links and then adding delay to reorder at the MPT server will add buffer bloat to match the worst link.

Our experience shows that it is worth aggregating only the capacity of the links with similar speeds and delay. Otherwise it is worth sending the traffic through the better link and use the other link as "spinning reserve" for resiliency purposes, if the better link fails.

I may be missing something, but after reading the draft I think this proposal will be harmful to users as it exclusively focuses on throughput at the expense of many other priorities.
While it's commonly assumed we can solve any problem by introducing an extra level of indirection or IP headers, I don't think tunnels are the solution to all woes.


Thanks,
David Schinazi


Whereas I try to "defend" our draft, and I hope that our conversation will result in a better draft, which will be useful for many people, I also admit, that there may be fundamental flaws in our concept, which we do not see. I honestly thank you for pointing them out in the past and in the future, too. And if the final outcome will be that we shell abandon the draft, I will still be grateful to you for saving us possibly years spent with something unusable.

So, I really appreciate your reply and wait for further comments from you and from anyone else interested in our draft.

Best regards,

Gabor


On Jul 25, 2017, at 08:59, Gabor Lencse <gabor-l@is.naist.jp> wrote:

Dear INTAREA WG members,

I am Gabor Lencse, the first author of a "-00" draft about the MPT Network Layer Multipath Library: https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-00

It was introduced to the INTAREA WG by our co-author Marius Georgescu at IETF 99.

I would like to elaborate on the feedback we received during the presentation.

Q1 (David, from Apple): What is the motivation, what you are trying to solve? Why are you trying to use multiple interfaces?

A1: Throughput aggregation between two sites. (E.g. between data centers)

My answer:

The problem to  be solved is the following. Due to the design of the TCP/IP protocol stack and its socket interface, even if a device has multiple network interfaces, only one of them can be used for a communications session. And it is a serious limitation many times!

Example: Somebody is remotely participating at an IETF meeting using Meetecho on his laptop using WiFi connection (to save costs). When he receives permission to ask a question, the WiFi connection brakes. By the time he manages to switch over to LTE, it is too late.  -- According to our tests, MPT can do the switchover seamlessly.

How common is this situation? I think many people have smartphones, with WiFi and LTE, and uses WiFi when available in order to save costs. Many of them use free video calls (e.g. by Skype, Viber, WhatsApp, etc.) and would be happy if the free WiFi could be backed up by seamless switchover to LTE during the calls.

There are a number of multi path solutions, which shows that the problem is real, but I contend that MPT differs from them and MPT can be more suitable for certain purposes than they for different reasons:

- MPTCP [RFC6824] is good, but it is "built together" with TCP. Some applications, e.g. DNS resolution or RTP use UDP. (They can work well with MPT.)

-  Huawei's GRE Tunnel Bonding Protocol [RFC8157] was designed for this very purpose, but it uses GRE, which is filtered out in many networks. (MPT uses GRE-in-UDP, thus MPT behaves as a standard UDP application in the carrier networks.)

- BANANA https://tools.ietf.org/html/draft-leymann-banana-data-encap-00 aims to do bandwidth aggregation, but it also uses GRE and not GRE-in-UDP. And I am not sure if it is able to provide a resilient tunnel (that is switching over from a given underlying path to another one).

- Load Sharing for SCTP https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14 is also a multipath solution, but it is very specific. MPT provides an IP tunnel, which can be used for any purpose.

All in all, I could not find any other solutions that would provide such flexible, multipurpose IP tunnel (providing both IPv4 and IPv6), which is both resilient and can aggregate the transmission capacity of several (even high number of) underlying paths, and which can be used in any networks, where UDP is carried over either IPv4 or IPv6. I would be interested in hearing about any similar solutions.

And I would like to receive your feedback about MPT. All your questions, comments, suggestions, etc.

Best regards,

Gabor


_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


--------------76928BA6FD7CC4B43EF6DFDF-- From nobody Wed Jul 26 16:06:21 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FAD131EAD; Wed, 26 Jul 2017 16:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mVgQlofpNdJP; Wed, 26 Jul 2017 16:06:17 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 37390131EB4; Wed, 26 Jul 2017 16:06:17 -0700 (PDT) X-AuditID: c6180641-bd7ff70000001788-28-5978da07720a Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 1B.B5.06024.70AD8795; Wed, 26 Jul 2017 20:05:59 +0200 (CEST) Received: from [155.53.28.151] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.80) with Microsoft SMTP Server id 14.3.352.0; Wed, 26 Jul 2017 19:06:15 -0400 From: Wassim Haddad Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-ID: <75B7D166-B440-4FE5-98AF-DD450342A1B6@ericsson.com> Date: Wed, 26 Jul 2017 16:06:17 -0700 CC: Wassim Haddad , To: "int-area@ietf.org" X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZXLrHT5f9VkWkQedfaYsbs26yWMx+4OXA 5LFkyU+mAMYoLpuU1JzMstQifbsEroy3h76yFRxgrFi7qp+tgXESYxcjB4eEgInE1ClBXYxc HEICRxklvr49wdzFyAnkrGOU2Hk7B8RmEzCQ+Lr8LCuIzSygI7Fg9yc2CFteYvvbOWD1vAL6 Eq92/2QHsYUFlCT+7+1ig4jbSyw//ZgZZBeLgKrEg5U5EK2eEu2/vrOA2CIC2hL7nxwAsyUE ZCVuzb4EdYK6xJRbE1gmMPLNQrJ5FpLNs5BsXsDIvIqRo7S4ICc33chwEyMweI5JsDnuYNzb 63mIUYCDUYmHt31aRaQQa2JZcWXuIUYJDmYlEd7JIpWRQrwpiZVVqUX58UWlOanFhxilOViU xHnflV+IEBJITyxJzU5NLUgtgskycXBKNTDKp+3jW6O9daOWpRLPnOQwB9u/6TkyAtOFviVN LDvAeHNLxrvmGym38zuzRBhfXz23VPv8ocv+DIrnLD84+k5mditYwFR+4OydyXVrJrFN8f7d OueO6/r9Rfo/v6n1rPy2/LpiSv3c+fUPuuISbTbdFuBX+9TSwbJva/6naZumWZ+PN5gV8UlL iaU4I9FQi7moOBEA5kVeABoCAAA= Archived-At: Subject: [Int-area] [Intarea] Meeting Minutes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 23:06:19 -0000 Hi, The intarea meeting minutes are available at: https://datatracker.ietf.org/doc/minutes-99-intarea/ Many thanks to Erik Kline for taking notes! Regards, Wassim H. From nobody Fri Jul 28 00:02:29 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D791296C9 for ; Fri, 28 Jul 2017 00:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 h4Q5KrIcBZMA for ; Fri, 28 Jul 2017 00:02:24 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57E3126DCA for ; Fri, 28 Jul 2017 00:02:23 -0700 (PDT) Received: from [10.228.32.53] (unknown [173.38.220.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 531B556498D; Fri, 28 Jul 2017 09:02:19 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Pierre Pfister In-Reply-To: <150122473336.25278.1146602212195692419.idtracker@ietfa.amsl.com> Date: Fri, 28 Jul 2017 09:02:18 +0200 Cc: Eric Vyncke , Tommy Pauly , "dschinazi@apple.com" , Basile Bruneau Content-Transfer-Encoding: quoted-printable Message-Id: <95C5FF14-6B8F-4157-8B2A-7D2BDC255F1F@darou.fr> References: <150122473336.25278.1146602212195692419.idtracker@ietfa.amsl.com> To: "int-area@ietf.org" X-Mailer: Apple Mail (2.3273) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Jul 28 09:02:19 2017 +0200 (CEST)) Archived-At: Subject: Re: [Int-area] New Version Notification for draft-bruneau-intarea-provisioning-domains-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 07:02:28 -0000 Hello all, We have just published a new version of the intarea-provisioning-domains = draft. This new version includes changes based on the feedback received during = the IETF hackathon, the int-area session, as well as in a few other = working groups such as capport and 6man. You can find major changes with respect to the previous version in the = changelog section, in the appendix. Since the room hummed in favour of adopting this draft during the last = IETF int-area session, we would also like to kindly request the chairs = to confirm the adoption based on this new version. Thanks, - Pierre >=20 >=20 > A new version of I-D, = draft-bruneau-intarea-provisioning-domains-02.txt > has been successfully submitted by Pierre Pfister and posted to the > IETF repository. >=20 > Name: draft-bruneau-intarea-provisioning-domains > Revision: 02 > Title: Discovering Provisioning Domain Names and Data > Document date: 2017-07-28 > Group: Individual Submission > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-bruneau-intarea-provisioning-do= mains-02.txt > Status: = https://datatracker.ietf.org/doc/draft-bruneau-intarea-provisioning-domain= s/ > Htmlized: = https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-bruneau-intarea-provisioning-d= omains-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-bruneau-intarea-provisioning-dom= ains-02 >=20 > Abstract: > An increasing number of hosts and networks are connected to the > Internet through multiple interfaces, some of which may provide > multiple ways to access the internet by the mean of multiple IPv6 > prefix configurations. >=20 > This document describes a way for hosts to retrieve additional > information about their network access characteristics. The set of > configuration items required to access the Internet is called a > Provisioning Domain (PvD) and is identified by a Fully Qualified > Domain Name (FQDN). This identifier, retrieved using a new Router > Advertisement (RA) option, is associated with the set of information > included within the RA and may later be used to retrieve additional > information associated with the PvD by the mean of an HTTP request. >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Fri Jul 28 08:06:33 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55947131EDD; Fri, 28 Jul 2017 08:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=WbEHVjlO; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=OWGrDtNM 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 ci6e36br3aB9; Fri, 28 Jul 2017 08:06:29 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 5E168131D24; Fri, 28 Jul 2017 08:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1501254389; x=1532790389; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VaeCD8T4ihSTkJohjoMr1jpnBSlTMdX5qlaLa2gDK98=; b=WbEHVjlO75UVID8ojGz+rz2AF1ha99O46AE8R1IQ6DDBooYy11eqiqnD C9MSgs23mh4DRGzkM+H0Xvl837tV3nBT1e1QRmr+QAjWRGpQ0QdMGwL4r KkhrirKL1X2XmWE883hIKyrMu1LmPRO/GHtMqmz2MQ6Lnjgcyvf/dGJS3 c=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 10:06:28 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 21:06:02 +0600 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6SF6NiD010679 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Jul 2017 11:06:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v6SF6NiD010679 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1501254386; bh=3SNeK+SkXRfP6mvDuyaZuinyDWk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=OWGrDtNMH/qiUp7ASGB47d1uyADZw44b4/ohuIUGTe6w39zO58WbARMGAYVBqtlVm lus8sNIRZVG7zO4wXqLwHtCXZVI6m4lov0xbfWp0oSSvghOU5WchpgbfeLYt9HJdi8 mlFInzt53mDJ6g6Jrw3ig24zgEljGB/cxHOAsUrs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v6SF6NiD010679 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Fri, 28 Jul 2017 11:05:49 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6SF69iA011094 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 28 Jul 2017 11:06:09 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0352.000; Fri, 28 Jul 2017 11:06:09 -0400 To: Wassim Haddad , "int-area@ietf.org" CC: "intarea-chairs@ietf.org" Thread-Topic: [Int-area] [Intarea] Meeting Minutes Thread-Index: AQHTBmPR/1v54iFAikK+6Rf21dSgDaJpWL1A Date: Fri, 28 Jul 2017 15:06:08 +0000 Message-ID: References: <75B7D166-B440-4FE5-98AF-DD450342A1B6@ericsson.com> In-Reply-To: <75B7D166-B440-4FE5-98AF-DD450342A1B6@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Int-area] [Intarea] Meeting Minutes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:06:31 -0000 Small correction in this section: [ Congestion Notification Across IP Tunnel Headers Separated by a Shim ] Bob Briscoe [... snip ...] OLD * David Black * we're going to last call this where it is NEW=20 * David Black * we're going to last call this draft where it is in TSVWG and will ann= ounce that WG Last Call to the intarea list Thanks, --David > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Wassim > Haddad > Sent: Wednesday, July 26, 2017 7:06 PM > To: int-area@ietf.org > Cc: intarea-chairs@ietf.org > Subject: [Int-area] [Intarea] Meeting Minutes >=20 > Hi, >=20 > The intarea meeting minutes are available at: >=20 > https://datatracker.ietf.org/doc/minutes-99-intarea/ >=20 > Many thanks to Erik Kline for taking notes! >=20 >=20 > Regards, >=20 > Wassim H. >=20 >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jul 28 08:10:28 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B8713211B for ; Fri, 28 Jul 2017 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=google.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 aI-XamSGLOd0 for ; Fri, 28 Jul 2017 08:10:25 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 10273132037 for ; Fri, 28 Jul 2017 08:10:25 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id d29so156396240uai.2 for ; Fri, 28 Jul 2017 08:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ccj3DJcdjNzL98KZmwtVvmQsu3VZ4yLC18WTf+EE1pQ=; b=Mu5FHqrcuNfiLoDPgtbk/inh89dagoU7F+I82PDCMNAWMr68EjCNK9PfUhFR+neoo9 b3p2Dmdynle0tKYP3XyzQs2erjdtbfvmkB/VS/zsdwJNFfqYqU9qBlZXNWzPaIiB6kTR K+dKzjJjwN4e3ut75F7DcsvBS51BG1zJ8UCzNKf48weDmSPuavWoRbkDjLDYknS0fqHr lTG6rMppmxr0xu3fa4x4e+m2mwpNji1mj1dL5NWKFbXuC824tOfDnnWouxRTwVHwTE9L adQSRPAW18J7aA0E+QkBoTA6E5em6ZiuIqRN3DWj2fbJyokWvyRVQJO89ZJiD1wxyPFw p9sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ccj3DJcdjNzL98KZmwtVvmQsu3VZ4yLC18WTf+EE1pQ=; b=URXTEbJWMKyo2Bk48W44hRMAnW7D/1gdQGuHuHwMV+AtSKM98fjDX1NfJQ02p1EtfW w6SgL1HGQ9oe0+wecG2URZQ0/WxQ56EDU191GR6nzuDptzFMapsfHCKNib64f0viiLSC BFbkQhTyPNmJM0eztAqvxGdWzc11kzjqqIRLVZqIBxVFQk35Q4/Sy7LCmZTFwOCP1WLT fX3yB7ErXdnmQ8R4sv6JeCoK/umlftIdAHBM/WzkchDtkg2XGdBniyklJ1uMy4nYSo+J FTUi2JZOHCa46fhdxuGUsTa2AU1+V5hV5HD+2b7xQQxWBrnMkCUUw+PFFumRApDdZeeQ azeg== X-Gm-Message-State: AIVw111NKLJlzWAO7yY+AZqb50pmAZqu3ueQ1wLPt7imtsmk1GFPBDug OsdEhGcoMaTS572EyA9GcMcjrUogs8AY X-Received: by 10.176.85.70 with SMTP id u6mr5766402uaa.114.1501254623938; Fri, 28 Jul 2017 08:10:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.4 with HTTP; Fri, 28 Jul 2017 08:10:03 -0700 (PDT) In-Reply-To: References: <75B7D166-B440-4FE5-98AF-DD450342A1B6@ericsson.com> From: Erik Kline Date: Sat, 29 Jul 2017 00:10:03 +0900 Message-ID: To: "Black, David" Cc: Wassim Haddad , "int-area@ietf.org" , "intarea-chairs@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045e38aa9a7fd90555621442" Archived-At: Subject: Re: [Int-area] [Intarea] Meeting Minutes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:10:27 -0000 --f403045e38aa9a7fd90555621442 Content-Type: text/plain; charset="UTF-8" My apologies! On 29 July 2017 at 00:06, Black, David wrote: > Small correction in this section: > > [ Congestion Notification Across IP Tunnel Headers Separated by a Shim ] > Bob Briscoe > > [... snip ...] > > OLD > * David Black > * we're going to last call this where it is > NEW > * David Black > * we're going to last call this draft where it is in TSVWG and will announce that WG Last Call to the intarea list > > Thanks, --David > >> -----Original Message----- >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Wassim >> Haddad >> Sent: Wednesday, July 26, 2017 7:06 PM >> To: int-area@ietf.org >> Cc: intarea-chairs@ietf.org >> Subject: [Int-area] [Intarea] Meeting Minutes >> >> Hi, >> >> The intarea meeting minutes are available at: >> >> https://datatracker.ietf.org/doc/minutes-99-intarea/ >> >> Many thanks to Erik Kline for taking notes! >> >> >> Regards, >> >> Wassim H. >> >> >> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --f403045e38aa9a7fd90555621442 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgbpC50Vhq8olWe8RQb93RFM32DKlHi26K M1BBfinKEBEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzI4 MTUxMDI0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADNbMk4jdC8WiRxEVadJ42fxOJcl2LF5fPIHwaDmSX4tGHiPB16w tlhBCrKFCbjhy4lAwIwgel5FhH9ntj54hxqlhat44WLkytFNpeusjvkQfj2LMzKTrv6qLw2wpVpy /UL8muPU4vPmcOwtJ5ExMTfyVt+v4BTziNGROLOetJgwMaCDcwclfAZOvwSs6LnNWBLl7pbHAZjZ ebpQwFdUfjTLPNDawd9t2C/Gx5w3fEQ4JxsKoY6zGsfmZbLqIkYQLYAgjzQ9W9ezSAfsVkoK00dO fgKgGM0oO7BM9gaYJtnN0XJlGSMajnr8IfEJdrbe1Hx9/TBbLIijNDRpZLiGtUM= --f403045e38aa9a7fd90555621442--