Re: [multipathtcp] Consensus call on potential MPTCP proxy work
<mohamed.boucadair@orange.com> Thu, 27 April 2017 06:54 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 A41D9126C25 for <multipathtcp@ietfa.amsl.com>; Wed, 26 Apr 2017 23:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 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, T_KAM_HTML_FONT_INVALID=0.01, 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 MhexvnWBYWOQ for <multipathtcp@ietfa.amsl.com>; Wed, 26 Apr 2017 23:53:59 -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 4C6A01294CF for <multipathtcp@ietf.org>; Wed, 26 Apr 2017 23:53:59 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id B431A1204E9; Thu, 27 Apr 2017 08:53:57 +0200 (CEST)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.63]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 8BCD0180065; Thu, 27 Apr 2017 08:53:57 +0200 (CEST)
Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM3F.corporate.adroot.infra.ftgroup ([fe80::e857:81f3:3859:a5de%21]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 08:53:57 +0200
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>
CC: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSvrNkxyRUG64+RkCrxHrjpOgwSKHYr/4w
Date: Thu, 27 Apr 2017 06:53:56 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E5B470@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <d53d6f13-f412-c42f-53a6-04637c7fef9b@isi.edu> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <e96adf18-f116-f424-9067-74b38ced6eee@isi.edu> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <e9bd13e1-908f-deea-f128-e232526015a4@isi.edu>
In-Reply-To: <e9bd13e1-908f-deea-f128-e232526015a4@isi.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E5B470OPEXCNORMADcorp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/P96fYXbN24hT3oXWQZkU0Jk5aVI>
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: Thu, 27 Apr 2017 06:54:03 -0000
Hi Joe, Please see inline. Cheers, Med De : Joe Touch [mailto:touch@isi.edu] Envoyé : mercredi 26 avril 2017 19:34 À : BOUCADAIR Mohamed IMT/OLN Cc : philip.eardley@bt.com; multipathtcp@ietf.org Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work Med, On 4/26/2017 12:11 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote: ... Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself. [Med] NAT64 (RFC6146) is not a patch AFAIK. IMO, it is - it's a patch to help support the deprecation of IPv4 in the global Internet. I don't see that as the role for an MPTCP proxy. [Med] The main point Joe is that the IETF has standard track documents that specify a TCP state machine when NAT is used. We are leveraging that state machine for the MPTCP proxy work. The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP connection. We are adhering to the logic of that RFC but without the drawbacks of SOCKS. Can you clarify where you see split TCP in RFC1928, [Med] I don’t see “split TCP” in RFC1928 in the same way I don’t see “split TCP” in the plain-mode draft. Nothing in RFC1929 talks about translating SYNs [Med] I guess you meant RFC1928. Translating packets is not explicited in the text, but it is hinted. For example, the text says the following: When a TCP-based client wishes to establish a connection to an object that is reachable only via a firewall (such determination is left up to the implementation), it must open a TCP connection to the appropriate SOCKS port on the SOCKS server system. How a connection from a client to a server with DST@=SOCKS_Proxy will be relayed to that remote server without gluing connections in both sides? That “glue” can be seen as translating packets by means of SNAT/DNAT. (side note: I’m sure that RFC1928 will never be published as it is in 2017. I hear from here people that will argue that RFC1928 is underspecified) - it doesn't even mention specific TCP segments at all, but refers only to the standard TCP API, where user data would be available only after the 3WHS between the client and the SOCKS proxy. [Med] That’s also the case for the MPTCP proxy. The user data will be available ONLY once the 3WHS is completed. Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN generating an outgoing SYN before the client SYN/ACK is returned. You don't mention split-TCP (and it has taken more than too long to figure out that's what's going on here), but that is what you show. or are you confusing it with this, which adds split TCP to a SOCKS proxy: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf [Med] Bingo. That is exactly my point. We need to avoid mixing implementation details with base specifications. That is exactly the reason why I said earlier that mptcp proxy documents only describe the external behavior. OK, so keep ALL discussions of SYN (or any segment translation) out of this document - including the figures. [Med] I’m personally fine with your proposal, but I’m sure we will have a lot of comments asking for more details. Figures are not normative; they are provided for illustration purposes. If you can explain this using the existing TCP API, e.g., OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure. But nowhere in that API does TCP tell you when a SYN arrives *before* sending a SYN-ACK. ----- As to your TFO argument, the problem is this: - what happens to the first MPTCP connection from proxy to proxy? [Med] Do you mean the first MPTCP connection that is proxied? Or the first subflow of a proxied MPTCP connection? why do you treat this differently than a typical MPTCP, and what information lets you do so? [Med] Can you please explicit your question? Are you referring to a multipath client, multipath server, or proxy? - No change is required for MPTCP-unaware clients and servers. - MPTCP processing at the MPTCP-aware server follows the base MPTCP specification. - MPTCP processing at the MPTCP-aware client in the dual-proxy case follows the base MPTCP specification. - MPTCP processing at the MPTCP-aware client in the single-proxy case will require to supply the MP_CONVERT in the initial subflow. A part from that, it follows the base MPTCP specification. - MPTCP processing at the proxy will require to process the MP_CONVERT information in order to create a forwarding state for that MPTCP connection. A part from that, it follows the base MPTCP specification. I don't see anything in this doc that qualifies as what TFO calls either a cookie between sessions or any substitute based on authentication or authorization. [Med] I already provided a pointer to the slides where this is discussed. You can also refer to draft-nam-mptcp-deployment-considerations-01#section-5.3<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#section-5.3>: The Network Provider that manages the various network attachments (including the MCPs) may enforce authentication and authorization policies using appropriate mechanisms. For example, a non-exhaustive list of methods to achieve authorization is provided hereafter: o The network provider may enforce a policy based on the International Mobile Subscriber Identity (IMSI) to verify that a user is allowed to benefit from the aggregation service. If that authorization fails, the Packet Data Protocol (PDP) context /bearer will not be mounted. This method does not require any interaction with the MCP. o The network provider may enforce a policy based upon Access Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) to control the CPEs that are authorized to communicate with an MCP. These ACLs may be installed as a result of RADIUS exchanges, for instance ([I-D.boucadair-mptcp-radius<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#ref-I-D.boucadair-mptcp-radius>]). This method does not require any interaction with the MCP. o The MCP may implement an Ident interface [RFC1413<https://tools.ietf.org/html/rfc1413>] to retrieve an identifier that will be used to assess whether that client is entitled to make use of the aggregation service. Ident exchanges will take place only when receiving the first subflow from a given source IP address. o The device that embeds the MCP may also host a RADIUS client that will solicit an AAA server to check whether connections received from a given source IP address are authorized or not ([I-D.boucadair-mptcp-radius<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#ref-I-D.boucadair-mptcp-radius>]). I agree that you're not strictly cloning TFO - IMO, you're trying to reinvent TFO without leveraging the experience the community has developed in that process, and IMO you're repeating some of the mistakes on that journey. [Med] I strongly disagree with this. We are leveraging on the guards as discussed in TFO specification: - Anti-spoofing filters are in place in the access segment. - TFO specification describes a cookie-less scheme if the server is immune. Joe
- [multipathtcp] Consensus call on potential MPTCP … philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… christian.jacquenet
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Stefano Secci
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… David Allan I
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Costin Raiciu
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Markus.Brunner3
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Robert Skog
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Jordan Melzer
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… Sébastien Barré
- Re: [multipathtcp] Consensus call on potential MP… Wouter Cloetens
- [multipathtcp] Increasing usage of MPTCP [was: Co… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… SungHoon Seo
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Matt Sargent
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Meyer, Ullrich, Vodafone DE
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair