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

<mohamed.boucadair@orange.com> Wed, 19 July 2017 18:39 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 07782131B9B; Wed, 19 Jul 2017 11:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 XkPVu6wUoXsA; Wed, 19 Jul 2017 11:39:26 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5CD131B3E; Wed, 19 Jul 2017 11:39:26 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 2A4BFC055A; Wed, 19 Jul 2017 20:39:25 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id E3C6720071; Wed, 19 Jul 2017 20:39:24 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 20:39:24 +0200
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>, Erik Kline <ek@google.com>
CC: Tom Herbert <tom@herbertland.com>, Internet Area <int-area@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>
Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP
Thread-Index: AQHTAK0hByPMqBya7E2aRTfcerPMC6JbeiqA
Date: Wed, 19 Jul 2017 18:39:24 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F3A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <CAAedzxqqNM-oc85HLXTQtkQ4Sh+VE=Jsd7wQMjab99ib37_8YQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <d09aee1c-1fad-d96b-63ed-664ba4476387@isi.edu>
In-Reply-To: <d09aee1c-1fad-d96b-63ed-664ba4476387@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/S4VMPHBs_uwcGrZEVzJs32XnCDM>
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 18:39:28 -0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:touch@isi.edu]
> Envoyé : mercredi 19 juillet 2017 18:36
> À : BOUCADAIR Mohamed IMT/OLN; Erik Kline
> Cc : Tom Herbert; Internet Area; tsv-area@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> 
> 
> On 7/19/2017 1:46 AM, mohamed.boucadair@orange.com wrote:
> > So making use of MPTCP to grab more resources (when available) or to
> provide better resiliency (when a network attachment is lost) will require
> both endpoints to be MPTCP-capable.
> That is both correct and appropriate.
> 
[Med] OK. 

> Doing tricks to demonstrate that an attacker (i.e., something that
> modifies TCP segments on path) can do otherwise should not be considered
> a viable alternative.

[Med] We are defining an application proxy that assist the user to maximize the use of its available network resources. The proxy relies on IETF defined BCPs (defined by behave and tsvwg) to relay TCP packets. 

> Joe