IETF Logo Mail Archive

Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 19 April 2017 01:12 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 383E2129462 for <multipathtcp@ietfa.amsl.com>; Tue, 18 Apr 2017 18:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 e5Fknk9N5M4W for <multipathtcp@ietfa.amsl.com>; Tue, 18 Apr 2017 18:12:54 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1E21292F5 for <multipathtcp@ietf.org>; Tue, 18 Apr 2017 18:12:53 -0700 (PDT)
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 37531279BBD for <multipathtcp@ietf.org>; Wed, 19 Apr 2017 10:12:52 +0900 (JST)
Received: by mail-oi0-f52.google.com with SMTP id x184so11516601oia.1 for <multipathtcp@ietf.org>; Tue, 18 Apr 2017 18:12:52 -0700 (PDT)
X-Gm-Message-State: AN3rC/60InPCfoLoX6UWxSu5cG6YvR1zAXvtQV3uRfqqdnOTy168n6zr Qk99AUbnhWtYlAaVeJzzoU6F6gN0Og==
X-Received: by 10.157.15.172 with SMTP id d41mr137047otd.34.1492564370903; Tue, 18 Apr 2017 18:12:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.132 with HTTP; Tue, 18 Apr 2017 18:12:50 -0700 (PDT)
In-Reply-To: <8cd97018-1104-c647-45fc-9135097e7420@isi.edu>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <CAO249ye4Yz2Fgf5=XG5F3JkODym1AXrZV3pXyVLgG-h2iVhLVw@mail.gmail.com> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Tue, 18 Apr 2017 18:12:50 -0700
X-Gmail-Original-Message-ID: <CAO249ycQqVweB5TaQNa2s8uFvQhSQrESrNmF1+8a8_ZO+Yqkyg@mail.gmail.com>
Message-ID: <CAO249ycQqVweB5TaQNa2s8uFvQhSQrESrNmF1+8a8_ZO+Yqkyg@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="001a113dd77621dbed054d7ab970"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/2zO9AsEcafklpITtKDdmbVQmyRs>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
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 Apr 2017 01:12:56 -0000

Hi Joe,

On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <touch@isi.edu> wrote:

>
>
> On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote:
> > Hi Joe,
> >
> > It's not tunneling. The proxy converts a tcp connection into a mptcp
> > connection and converts it back to a tcp connection (if necessary)
> > So, it won't be tcp over tcp.
> OK, but that's not proxying either.
>
> That's (at best) connection hijacking.
>

I won't deny it as I'm not 100% sure whether proxy is a good name or not.
But, I am thinking you might want to call NAT hijacking as well.

> MPTCP will convey control data for application (proxy) in payload.
> > But, MPTCP of course doesn't care the contents of payload.
> > It just carries data and app will parse the data. Putting data in SYN
> > is trying to reduce the latency and no other meaning as far as I
> > understand.
>
> MPTCP is TCP. Putting the data in the SYN of a TCP connection is
> hazardous. The goal is irrelevant.


In TCP, we already have a precedence such as TFO.
I think what the solution does won't exceed what TFO does.
Data in SYN will be used between the proxies and won't be sent to random
destinations.
--
Yoshi

v2.23.0 | Report a Bug | By Email