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:49 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 B9318128896 for <ietf@ietfa.amsl.com>; Wed, 12 Apr 2017 00:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.4
X-Spam-Level:
X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 2s3fAxJrzpib for <ietf@ietfa.amsl.com>; Wed, 12 Apr 2017 00:49:53 -0700 (PDT)
Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82A3128854 for <ietf@ietf.org>; Wed, 12 Apr 2017 00:49:52 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 2BF4C402EA; Wed, 12 Apr 2017 09:49:51 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id EEE2D20074; Wed, 12 Apr 2017 09:49:50 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 09:49:50 +0200
From: mohamed.boucadair@orange.com
To: Nico Williams <nico@cryptonector.com>, Melinda Shore <melinda.shore@gmail.com>
CC: "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+AgAAFNgCAAQDqoA==
Date: Wed, 12 Apr 2017 07:49:50 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E4C1A6@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> <20170411175019.GB23461@localhost>
In-Reply-To: <20170411175019.GB23461@localhost>
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/zUbYuMDbMxI0wrbT3M6G7HAR08Y>
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:49:55 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : ietf [mailto:ietf-bounces@ietf.org] De la part de Nico Williams
> Envoyé : mardi 11 avril 2017 19:50
> À : Melinda Shore
> Cc : ietf@ietf.org
> Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
> mm-wg-effect-encrypt-09)
> 
> On Tue, Apr 11, 2017 at 09:31:41AM -0800, Melinda Shore wrote:
> > 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, and for the moment it looks like
> > anything that requires changes to middleboxes along those
> > lines is unlikely to be successful.  That said:
> 
> Sure, but if we wanted to have an Informational RFC describing all the
> goodness and badness and history of middle-box-aware protocools, that
> might not be bad, and we could detail all those protocols that failed to
> get traction and why.  I think such a document would end up favoring
> end-to-end protocols, even if it didn't start out with that as a goal :)
> 

[Med] This may be applicable for some cases under some conditions ... but I'm afraid this may not be applicable to all of them. This is why it is important to understand the intended usage (draft-dolson) before going further in the discussion (e.g., whether it makes sense to call for a generic recommendation, standardize a given network-located function a la BEHAVE, etc.).   

For example, an operator will need to detect and mitigate DDoS attacks without interfering with legitimate traffic issued/send to customers. "Something" is to be done at the network side to that aim. We are investigating how endpoints can help to achieve that goal.