IETF Logo Mail Archive

Re: [multipathtcp] [Int-area] SOCKS 6 Draft

<mohamed.boucadair@orange.com> Thu, 06 July 2017 13:02 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B79131721; Thu, 6 Jul 2017 06:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZakN6PyorVt; Thu, 6 Jul 2017 06:02:35 -0700 (PDT)
Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B5E12EC40; Thu, 6 Jul 2017 06:02:35 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 72AA41803C1; Thu, 6 Jul 2017 15:02:33 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 345E84005B; Thu, 6 Jul 2017 15:02:33 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 15:02:32 +0200
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>, David Schinazi <dschinazi@apple.com>
CC: multipathtcp <multipathtcp@ietf.org>, "Int-area@ietf.org" <Int-area@ietf.org>
Thread-Topic: [multipathtcp] [Int-area] SOCKS 6 Draft
Thread-Index: AQHS9a08Y4IlRnpvi0+MgNkwp3/CEKJFUyCAgAFwI6A=
Date: Thu, 06 Jul 2017 13:02:32 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A001A21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <c215bf9d-5313-3a4b-ac47-dd34cb22766f@cs.pub.ro> <F42011E7-0F81-44DF-9DFC-A211B615DD33@apple.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> <AE3FC07A-DE86-4765-9D1F-00640942B4E4@apple.com> <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000764@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <b33e4726-f255-75f7-5203-9e30faa36659@cs.pub.ro> <787AE7BB302AE849A7480A190F8B93300A000D16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <a922a59f-2670-8d50-f3c5-99e1c29848ca@cs.pub.ro> <ec8cae81-dbeb-ed92-33ca-678bb2b5efeb@isi.edu>
In-Reply-To: <ec8cae81-dbeb-ed92-33ca-678bb2b5efeb@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_787AE7BB302AE849A7480A190F8B93300A001A21OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/xwC8GYGvnCUHz0Tin2H_-yOgB6A>
Subject: Re: [multipathtcp] [Int-area] SOCKS 6 Draft
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 13:02:37 -0000

Hi Joe,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 5 juillet 2017 18:59
À : 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 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.
[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.


Joe

v2.23.0 | Report a Bug | By Email