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

Joe Touch <touch@isi.edu> Wed, 19 July 2017 19:41 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 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 <vladimir.olteanu@cs.pub.ro>, Dragoș Niculescu <dragos.niculescu@cs.pub.ro>
Cc: 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> <0f8dd648-d89f-50ee-716a-7547ee34885a@isi.edu> <f7121225-ce5f-4002-d3cf-202dcdd11f04@cs.pub.ro>
From: Joe Touch <touch@isi.edu>
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: <f7121225-ce5f-4002-d3cf-202dcdd11f04@cs.pub.ro>
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/iqDpGQcr2NXGfUjPfPEPLH98BII>
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 19:41:20 -0000


On 7/19/2017 12:23 PM, Vladimir Olteanu wrote:
> I think there's a misunderstanding here. SOCKSv6 runs strictly on top
> of TCP. 
OK, so to clarify - TCP is between the two SOCKS endpoints.
The user data travels over SOCKS.
Can you confirm that's correct?

> The "user data" to which we're referring is data meant to be relayed
> by the proxy to the server. The SYN's payload (both SOCKS request and
> said user data) is irrevocably part of the client-proxy data stream
> and we do not change it retroactively after learning that the proxy
> does not support TFO.
If the above is correct, then it would be useful to NEVER speak of
"putting data in the SYN payload". You simply don't have that control.
The interface to TCP *allows* pending "user" (as in TCP user, which in
this case is the SOCKS layer) data to be placed in the SYN, but never
requires it.

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

Joe