Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Olivier Bonaventure <olivier.bonaventure@tessares.net> Wed, 19 July 2017 15:51 UTC

Return-Path: <olivier.bonaventure@tessares.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267E812F3CB for <int-area@ietfa.amsl.com>; Wed, 19 Jul 2017 08:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com
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 6qVafNMVDnki for <int-area@ietfa.amsl.com>; Wed, 19 Jul 2017 08:51:24 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0BA131D70 for <int-area@ietf.org>; Wed, 19 Jul 2017 08:51:21 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id w126so2811167wme.0 for <int-area@ietf.org>; Wed, 19 Jul 2017 08:51:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=qsHtHCz0luExy7y+wpnfzy3w3KCLVr58LUahyTINlpw=; b=jKGpZYcY7iTAx2yaxO2eSqt0zH5KGrRhRYdgpFRuJHAznwTRqYSAGx2mdeEimbg3cy uhMDGQR7P5Eu9qD0NJIwbbh25bE79QXTNxeAdg6qe7A1+NC8xMYxWoaQi2EPqgaKzbun nHco5lVsrwiV2+2U7W7oUCNIP/l/RtFf8RIe0hIvdFft/hU01jAjevR+rI3YCXlpD9ou 8OkURRh8Ow5uoER1CIfUKl7w89EVKboi7aCvTFCbQS28SmIvvx7Fhjq/pLS5UnMMsuJ/ 0TD2zmZtPPI0NHsOYL9KPXgGbib5nf5clNaYeqIU7DIk9b6QZl8WJ1DCNKgyeF2LMeqz 7NNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qsHtHCz0luExy7y+wpnfzy3w3KCLVr58LUahyTINlpw=; b=qnOE0mi849Cytx+0uLXYFw1v9+zrlrewfRU1xpXUMIhUor9RZRUwbRI9iSKRaDjwix iNAiEltzJiQF23wHPU5L4Meg5RR+h9fW1xkEQTnlj1P1YyOoyBP/vPQ5xY16b1WX9VMA cbta/3FtOQiwkb2SlKtueL/6jzcQHvlMsLyu0BaUwiSGbsClzaI59m+BaqJfH4N2ifcl 1SUlzg8ctKqzN27o4elGWHN6NSFoKIwcuQbpLtQAigE32SAwEI/Ruyc21k1bzTA/gs15 nO7lX9KW98TbRlxcz/7vdQDwgwUWDwv3hHpg1IkAyvdxOvOf7qsLXtQ38jR0PAxpyPQS Ps1w==
X-Gm-Message-State: AIVw111ZQyS8ZrUpisF2gf/8QAK8ovPbyKf1JKHuI55LkVDgy2ftACgT vGOuN4GQep9NtIXZJ6t2a1gtNHAJJXliDAr6w0crY1Xa296dVhIY7JjU+gTnNWowjYct+FWmgNQ =
X-Received: by 10.28.172.4 with SMTP id v4mr335707wme.72.1500479479745; Wed, 19 Jul 2017 08:51:19 -0700 (PDT)
Received: from dhcp-88fc.meeting.ietf.org ([2001:67c:370:128:8ce6:5c6:330:a26f]) by smtp.gmail.com with ESMTPSA id l22sm253442wmi.48.2017.07.19.08.51.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 08:51:18 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, mohamed.boucadair@orange.com
Cc: Internet Area <int-area@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>
References: <fe384d2b-a0ba-9444-2ee9-cd0de6d24b7c@tessares.net> <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <CALx6S35LpE=Z8DhanPuVcN9sVR2rkxtFPUZMd6Z4v1PHsnzF0w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CALx6S34SicdYJj662qwu3CMHrU_ZDg2qsEQFQwnSW4y-H87FCA@mail.gmail.com>
From: Olivier Bonaventure <olivier.bonaventure@tessares.net>
Message-ID: <70ccfd9e-e6eb-6f84-856f-fb5912fc0517@tessares.net>
Date: Wed, 19 Jul 2017 17:51:17 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CALx6S34SicdYJj662qwu3CMHrU_ZDg2qsEQFQwnSW4y-H87FCA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Language: fr-classic
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Az_ba1OTwNNDQvn8c39tuZ56Xm0>
Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 15:51:26 -0000

Tom,
>>
>> Do you have in mind such use cases when you referred to the "stateful firewalls model"?
> 
> One of the problems with stateful firewalls (as well as transparent
> proxies) is that they require all packets for a flow to consistently
> traverse the same middlebox device. The middlebox is not addressed by
> the packet, so the assumed requirement is that packets for the flow go
> though the same network node by virtue of routing. 

The proposed converter has one IP address and a reserved port number. 
Packets follow norm routing path towards this address.

> For a firewall in a
> single-homed site to the Internet this works because the firewall is
> the only egress/ingress point to the network. If a site is
> multi-homed, then the hope is that routing of packets in both
> directions will go through the same point. But there is absolutely no
> requirement that network layer packets for a flow are always routed
> the same way, and if routing does change and packets need to flow
> through different points the session breaks. >
> If I'm reading the draft correctly, then it has the same property of
> maintaining transport state in the network so it implies the same
> requirement that all packets for a flow follow the same path.
> Personally,  would find it ironic that a a protocol to allow muli-path
> transport would require the network layer to be single path.

The motivation for the proposed converters is that the destination does 
not support MPTCP. To enable the client to leverage the benefits of 
MPTCP (e.g. in the access networks) the MPTCP connection is terminated 
on the converter. The client uses the different paths between it and the 
converter.


Olivier

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.