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 > >
- [multipathtcp] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft mohamed.boucadair
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Dragoș Niculescu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft mohamed.boucadair
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft mohamed.boucadair
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft mohamed.boucadair
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] SOCKS 6 Draft Yoshifumi Nishida
- Re: [multipathtcp] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] SOCKS 6 Draft Yoshifumi Nishida
- Re: [multipathtcp] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Dragoș Niculescu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Vladimir Olteanu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Dragoș Niculescu
- Re: [multipathtcp] [Int-area] SOCKS 6 Draft Joe Touch