Re: [multipathtcp] SOCKS 6 Draft

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Mon, 10 July 2017 07:00 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 C52E4127286 for <multipathtcp@ietfa.amsl.com>; Mon, 10 Jul 2017 00:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, 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 rWechyEPWY20 for <multipathtcp@ietfa.amsl.com>; Mon, 10 Jul 2017 00:00:13 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E3A126DED for <multipathtcp@ietf.org>; Mon, 10 Jul 2017 00:00:13 -0700 (PDT)
Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DD850278223 for <multipathtcp@ietf.org>; Mon, 10 Jul 2017 16:00:09 +0900 (JST)
Received: by mail-lf0-f43.google.com with SMTP id b207so51972361lfg.2 for <multipathtcp@ietf.org>; Mon, 10 Jul 2017 00:00:09 -0700 (PDT)
X-Gm-Message-State: AIVw110qqEQL7mcvKnyqBXz1Xy75EEVEp8q1eWU78IhkVeobez3rWJTi OUybAdIrsKqviGEEuiTgKpdOiMIhyw==
X-Received: by 10.25.67.5 with SMTP id q5mr627270lfa.109.1499670007674; Mon, 10 Jul 2017 00:00:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.35.87 with HTTP; Mon, 10 Jul 2017 00:00:07 -0700 (PDT)
In-Reply-To: <96151c77-fd31-f6ca-dca0-bffb9780f89f@cs.pub.ro>
References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <96151c77-fd31-f6ca-dca0-bffb9780f89f@cs.pub.ro>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 10 Jul 2017 00:00:07 -0700
X-Gmail-Original-Message-ID: <CAO249yf3Jt8SdC9+1aZTbtTJ_iu+TkoHdqTu+NSxuXoS+0pUTA@mail.gmail.com>
Message-ID: <CAO249yf3Jt8SdC9+1aZTbtTJ_iu+TkoHdqTu+NSxuXoS+0pUTA@mail.gmail.com>
To: Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>
Cc: multipathtcp <multipathtcp@ietf.org>, Dragoș Niculescu <dragos.niculescu@cs.pub.ro>
Content-Type: multipart/alternative; boundary="f403045ea4ca1680330553f12234"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/cE33xI3t_K5J15tJ376GDJ0OENU>
Subject: Re: [multipathtcp] 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: Mon, 10 Jul 2017 07:00:21 -0000

Hi Vlad and Dragos,

I really appreciate you for preparing the draft and brought it to here.
As you might know, we have been exploring solutions for proxying mptcp
sessions.
We've had lots of discussions on plain mode and other solutions, but
because we didn't have concrete proposals other than plain mode, it was
difficult to compare the pros and the cons properly. But, now I believe we
have a good chance to advance this.

BTW, as I'm curious about this approach to use with mptcp, I have some
questions for a certain scenario. In the WG, one use case we discuss is
using two proxies like below.

          client ---- proxy1 ============= proxy2 ---- server

In this scenario, we presume using TCP for client-proxy1 and proxy2-server,
while using mptcp for proxy1-proxy2.
The draft says it supports TFO, but I still think it takes some RTTs with
approach although I miss something. It would be great if you could clarify
the following points.

1:  How will the connection between proxy1 and proxy2 set up? Does proxy1
need to negotiate proxy2 for authentication, etc? If so, it might add
another delays before clients can send data.

2: Do clients need to wait a response for CONNECT request? If not, how it
handles an error case?

Thanks,
--
Yoshi


On Thu, Jun 29, 2017 at 5:02 AM, Vladimir Olteanu <
vladimir.olteanu@cs.pub.ro> wrote:

> Hello,
>
> We have submitted a draft describing a new version of the SOCKS protocol,
> which could help in the deployment of MPTCP. You can find the abstract and
> a link to the draft below.
>
> Best,
> Vlad and Dragoș
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
> Date: Wed, 28 Jun 2017 22:01:16 -0700
> From: internet-drafts@ietf.org
> To: Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>
> <vladimir.olteanu@cs.pub.ro>, Dragos Niculescu
> <dragos.niculescu@cs.pub.ro> <dragos.niculescu@cs.pub.ro>
>
> A new version of I-D, draft-olteanu-intarea-socks-6-00.txt
> has been successfully submitted by Vladimir Olteanu and posted to the
> IETF repository.
>
> Name:		draft-olteanu-intarea-socks-6
> Revision:	00
> Title:		SOCKS Protocol Version 6
> Document date:	2017-06-28
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
> Htmlized:       https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00
>
>
> Abstract:
>    The SOCKS protocol is used primarily to proxy TCP connections to
>    arbitrary destinations via the use of a proxy server.  Under the
>    latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
>    authentication is used) before data can flow between the client and
>    the server.
>
>    This memo proposes SOCKS version 6, which reduces the number of RTTs
>    used, takes full advantage of TCP Fast Open, and adds support for
>    0-RTT authentication.
>
>
>
>
> 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
>
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>