Re: [multipathtcp] q about off-path proxy (explicit mode)

<mohamed.boucadair@orange.com> Mon, 27 March 2017 19:32 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 7DE8A12956E for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 12:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 7xZ33dsfS0aC for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 12:32:23 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED75A129570 for <multipathtcp@ietf.org>; Mon, 27 Mar 2017 12:32:21 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 88ACD1C050F; Mon, 27 Mar 2017 21:32:20 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 6A55416006C; Mon, 27 Mar 2017 21:32:20 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 21:32:20 +0200
From: <mohamed.boucadair@orange.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
CC: multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] q about off-path proxy (explicit mode)
Thread-Index: AQHSpybncggiujcUY0ebYXfWdz7o6KGpEIvg
Date: Mon, 27 Mar 2017 19:32:19 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E41571@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CAO249yc3MOaPjBsmYqsZgW3AaxKmpA_wr2TxvgLZLwP6rf9dwA@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009E41157@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAO249ydXsYv7TDXcfAF0gXxrDQocT_jqt2kRC5VVjFrik4CrqA@mail.gmail.com>
In-Reply-To: <CAO249ydXsYv7TDXcfAF0gXxrDQocT_jqt2kRC5VVjFrik4CrqA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E41571OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Fro3pCM0PKUJtEOjMHFcCuwMWRk>
Subject: Re: [multipathtcp] q about off-path proxy (explicit mode)
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, 27 Mar 2017 19:32:27 -0000

Re-,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Envoyé : lundi 27 mars 2017 13:21
À : BOUCADAIR Mohamed IMT/OLN
Cc : Yoshifumi Nishida; multipathtcp
Objet : Re: [multipathtcp] q about off-path proxy (explicit mode)

Hi Olivier, Med,

Thanks for the response. I have been thinking that it would be better if we can classify our use cases so that we can have clear vision for what to solve. Things I may want to classify is:
   a) solutions requires changes in only MPTCP or in TCP general
   b) solutions requires proxies to be on-path or solutions that work with off-path proxy.

We can think about the solutions for a) if we think it's necessary, but I am thinking that the proper venue for the discussion might not be this WG.

I think the approach Med mentioned requires the proxy to be on-path, so I would like to classify it as an on-path solution.
[Med] I’m not sure to follow you here. What I described is aligned with the target dual proxy case (https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#section-4.2): the first proxy is embedded on a CPE. There is no technical problem there to intercept the traffic to be proxyied given that the CPE sees all the traffic.

I had some hard time to comprehend the proxy drafts and I think one reason for that is it somehow mixes up on-path and off-path cases. I start thinking separating docs for on-path and off-path solutions might be helpful.
[Med] There are a lot of commonalities between these two modes. The main difference is how to make involve the MCP into a connection.
--
Yoshi

On Mon, Mar 27, 2017 at 8:06 AM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Yoshi,

Olivier already answered to many of your points. There are other communication scenarios not included in your list that we want to cover.

Below some additional comments.

Cheers,
Med

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org<mailto:multipathtcp-bounces@ietf.org>] De la part de Yoshifumi Nishida
Envoyé : samedi 25 mars 2017 08:08
À : multipathtcp
Objet : [multipathtcp] q about off-path proxy (explicit mode)

Hello,
Now, I am trying to understand off-path (explicit mode) scenarios.
In explicit mode, we need to tell the final destination to the proxy through MP_Convert Information Element. But, this requires mptcp connections. In order to clarify which cases can use this mode, I have drawn the following 7 cases.
I am wondering if we can support case 3) 4) 5) with explicit mode or not. Also, supporting case 6), 7) seems to be a bit unclear.
It would be great if some folks could clarify this.

-----------------------------------------------------------------------------


     C ... client,   S ... Server,  P ... Proxy,  MCIE ... MP_Convert Information Element
   ====   ... mptcp connection
   ----   ... tcp connection


single proxy cases

1)   C ========== P -------- S         : C tells S's addr to P by MCIE
2)   C ========== P ======== S         : C tells S's addr to P by MCIE
3)   C ---------- P ======== S         : How C tell S's address to P?
[Med] The communication between C and P relies on TCP. C does not need to supply any information to P for case 3. The client is not even aware about the presence of P in this case.

double proxy cases

4)   C -------- P1 ======== P2 ------- S  : How C tell S's address to P1?
[Med] S is the destination IP address of the packets sent from C to P1. There is no need for an object to supply that information.

5)   C -------- P1 ======== P2 ======= S  : How C tell S's address to P1?
[Med] S is the destination IP address of the packets sent from C to P1.

6)   C ======== P1 ======== P2 ------- S  : C tells S's addr to P1 by MCIE and P1 forwards it to P2?
[Med] No. S is the destination IP address of the packets sent from C to P1.  MCIE is not needed in the C-P1 leg.

7)   C ======== P1 ======== P2 ======= S  : C tells S's addr to P1 by MCIE and P1 forwards it to P2?
[Med] No. S is the destination IP address of the packets sent from C to P1.