RE: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)

<mohamed.boucadair@orange.com> Wed, 12 April 2017 07:09 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B43124BFA for <ietf@ietfa.amsl.com>; Wed, 12 Apr 2017 00:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 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] 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 T4LbhI0eYY7E for <ietf@ietfa.amsl.com>; Wed, 12 Apr 2017 00:09:22 -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 61554126B72 for <ietf@ietf.org>; Wed, 12 Apr 2017 00:09:22 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7EE17C0621; Wed, 12 Apr 2017 09:09:20 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 527B44005B; Wed, 12 Apr 2017 09:09:20 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 09:09:20 +0200
From: mohamed.boucadair@orange.com
To: Melinda Shore <melinda.shore@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)
Thread-Topic: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)
Thread-Index: AQHSsuepcxG3Gt+qPke8vqYsnz4RHKHAS5+AgAD/ByA=
Date: Wed, 12 Apr 2017 07:09:19 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E4C16E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B933009E4B818@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11843452-d76d-50e3-c162-155f4d1621e2@cs.tcd.ie> <20170411171831.GA23461@localhost> <54be4f24-352e-5248-a9fb-f040d4f07fb9@gmail.com>
In-Reply-To: <54be4f24-352e-5248-a9fb-f040d4f07fb9@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.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rYJZ4vszsnd-tkjXAmFjZZYn8ug>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Apr 2017 07:09:24 -0000

Hi Melinda, 

Please see inline. 

Cheers,
Led

> -----Message d'origine-----
> De : ietf [mailto:ietf-bounces@ietf.org] De la part de Melinda Shore
> Envoyé : mardi 11 avril 2017 19:32
> À : ietf@ietf.org
> Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
> mm-wg-effect-encrypt-09)
> 
> On 4/11/17 9:18 AM, Nico Williams wrote:
> > One could give a lot of advice for design of protocols with
> > "friendly" middle boxes.  Merely saying "hey, they are good" is not
> > enough.  We might want to revisit end-to-end protocol design as well
> > (e.g., maybe ICMP isn't working so well; what can we do?).
> 
> There have been a number of efforts to provide mechanisms for
> applications to communicate explicitly with middleboxes.  None
> has gotten any traction,

[Med] I'm not sure "None" and "any" reflect the deployment realty I'm aware of:
* The BEHAVE recommendations for TCP(RFC5382)/UDP(RFC4787)/ICMP(RFC5508) and CGNs (RFC6888) are widely followed by CGN vendors. 
* The NAT64 (RFC6146)/DS-Lite CGN (RFC6333) specifications that is aligned with IETF BEHAVE recommendations are deployed in many networks with default behaviors that are friendly to applications.
* Our customers are making use of PCP (RFC6887) to interact with CGNs.
* Applications that make use of UPnP-IGD interact with an CGN server by means of a IGD/PC IWG (RFC 6970)
* Applications embedded on the CPE can interact with a local PCP client.

Sometimes the problem is not on the network side but elsewhere.       

 and for the moment it looks like
> anything that requires changes to middleboxes along those
> lines is unlikely to be successful.  That said:
> 
> > IMO the IETF must not publish draft-dolson-plus-middlebox-benefits as
> > it is today.
> 
> No, clearly not.  I'm actually not sure I see a lot of benefit
> to publishing a more balanced document, either, in the sense that
> it's not likely to lead anybody to do anything differently.

[Med] I disagree with this position. Many times the IETF decided to not hide a problem but to deal with it, interesting solutions are proposed with concrete deployments. Of course, resistance to some proposals may have consequences on some operators plans that are obliged to deploy **mature solutions they had at hand**. 

> 
> Melinda