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

<mohamed.boucadair@orange.com> Tue, 11 April 2017 08:15 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 880DA1292FD for <ietf@ietfa.amsl.com>; Tue, 11 Apr 2017 01:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 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, 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 nn8vlgB8FSzp for <ietf@ietfa.amsl.com>; Tue, 11 Apr 2017 01:15:23 -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 08935129408 for <ietf@ietf.org>; Tue, 11 Apr 2017 01:15:23 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 24428C05E4; Tue, 11 Apr 2017 10:15:21 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id F0420C0079; Tue, 11 Apr 2017 10:15:19 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 10:15:19 +0200
From: mohamed.boucadair@orange.com
To: Martin Thomson <martin.thomson@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
CC: "draft-dolson-plus-middlebox-benefits@tools.ietf.org" <draft-dolson-plus-middlebox-benefits@tools.ietf.org>
Subject: 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: AdKym8EY4i6VvDHuQjir6aepfU3ztw==
Date: Tue, 11 Apr 2017 08:15:19 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E4B818@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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/ietf/QIBhtT1WPXQQZYPyhke-Uxlq0AU>
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: Tue, 11 Apr 2017 08:15:24 -0000

Hi Martin, all, 

I have a comment about this particular part of your review.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : ietf [mailto:ietf-bounces@ietf.org] De la part de Martin Thomson
> Envoyé : vendredi 7 avril 2017 05:25
> À : ietf@ietf.org
> Objet : Review of draft-mm-wg-effect-encrypt-09
> 
> 
> I hope that the IETF never publishes draft-dolson-plus-middlebox-benefits;
> it
> makes claims about the benefits of specific solutions for different use
> cases
> with the goal of justifying those solutions.

[Med] I'm afraid this is speculating about the intent of draft-dolson. Assured this is not the purpose of that document. The motivation is to document current practices without including any recommendation or claiming these solutions are superior to others. There is a need to understand the motivations why operators need to enable some of these features. For example, means to help on-path devices executing their service are needed for network operation purposes (e.g., protect a network, detect cover channels, help selecting the portion of traffic to be filtered rather than directing all the traffic to a black hole during attacks, etc.). 

Of course, authors of draft-dolson understand there are deployment cases where middleboxes may not be required at all. Their presence may even be a source of trouble if badly tweaked, for example. That’s an evidence. 

Authors of draft-dolson does not claim middleboxes is the only way to meet the technical objectives listed in the draft, but they are documenting sample features that are needed to be supported at the network side. 

Solution designers can refer to draft-dolson to explicit how they solve a particular problem without requiring services from an on-path device.


  At the same time, it fails
> to
> recognize the existence of alternative,

[Med] It does not do so because it is out of scope. Before discussing alternatives, we need first to understand the goals that motivated current practices. Future documents can refer to draft-dolson to describe alternatives.  

 often superior,

[Med] I don't see how you ended to such conclusion as a general statement without even looking at the needs! It may be tempting to ask, for example, what are these superior alternatives to help operators detect and mitigate DDoS, but as mentioned above, it is early at this stage to discuss these alternate solutions.   

 solutions for
> those use
> cases.  In other words, it has many of the same issues as this document.
>