IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Wed, 19 July 2017 18:26 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 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: Dragoș Niculescu <dragos.niculescu@cs.pub.ro>
Cc: Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>, mohamed boucadair <mohamed.boucadair@orange.com>, David Schinazi <dschinazi@apple.com>, multipathtcp <multipathtcp@ietf.org>, int-area <Int-area@ietf.org>
References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <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> <1459306318.3890958.1499330475778.JavaMail.zimbra@cs.pub.ro> <c15031f3-95cf-d341-2ddb-0b3850a74d76@isi.edu> <53068639.4279258.1500018250846.JavaMail.zimbra@cs.pub.ro>
From: Joe Touch <touch@isi.edu>
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/nx5_B69Lhjgq4ETaC_ahnIwZTjk>
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: Wed, 19 Jul 2017 18:26:51 -0000


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

v2.23.0 | Report a Bug | By Email