IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Thu, 13 July 2017 17:10 UTC

Return-Path: <touch@isi.edu>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B4F12F257; Thu, 13 Jul 2017 10:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qArnJ4dBuT-Z; Thu, 13 Jul 2017 10:10:12 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3F51298BA; Thu, 13 Jul 2017 10:10:12 -0700 (PDT)
Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v6DH9pgs004172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 10:09:53 -0700 (PDT)
To: mohamed.boucadair@orange.com, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>, David Schinazi <dschinazi@apple.com>
Cc: multipathtcp <multipathtcp@ietf.org>, "Int-area@ietf.org" <Int-area@ietf.org>
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> <787AE7BB302AE849A7480A190F8B93300A001A21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <touch@isi.edu>
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Ul32sYwwtm-yA6-ZSJirwKWIfuI>
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, 13 Jul 2017 17:10:14 -0000


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

v2.23.0 | Report a Bug | By Email