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

Brian E Carpenter <> Tue, 11 April 2017 13:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86291129BC1 for <>; Tue, 11 Apr 2017 06:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qnu5Jy71O_6X for <>; Tue, 11 Apr 2017 06:34:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4429129BA5 for <>; Tue, 11 Apr 2017 06:34:05 -0700 (PDT)
Received: by with SMTP id t68so2094812iof.0 for <>; Tue, 11 Apr 2017 06:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aLsyKDSvjtLcA+MMneOxmd26Lk+RymQS/H8jyPy/Dnc=; b=OO2NCL8iMcP2inJtQYtTMztNxgZ5GH+w0SeDgLFnhFgoNxSEudZFElsI8ioi7gTIXw UGQ83ghz/rZja1LVnWrTlVjMVS23z7Z+i5dEm7nJojywcqpG4u57xMyldcDtVM3oxKpL 4ApPMWt4xAVb/KSrKshcIrngxAlQD6uVB23fNkD+b49dEIhTIpWKCPzndrXQGbMeIHvg SiRF0qbKgG4rbfSxP1Ntjj22NeAYiKR3mrLINZ56ShD2bAtf34B4+rL5y/rgYOG7lx3A DjgFpTeqE7cyt4SxzMvxhNVUipPS6FDDMTSSIPrsZM1g2fuFGZMbpFMhhTDq3qqkMqz7 ljfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=aLsyKDSvjtLcA+MMneOxmd26Lk+RymQS/H8jyPy/Dnc=; b=tiaTw+nhtpDVg7Kq0vxyjVSjtmy27BPIy/o/4waPPgga/nRvCSrTOKMUIea9rk5DWX h/4HWrFKKVhPQHVLsVyoGYFsSC1xz6h6AZoo+hLgHNVKyoZNdfHunP7r+b22/MBdWaD8 G/Llo90/szYRmki/tVd5LJmnoAy2k618qlVzwCcj7vReCkwKLf2M4C68duTDrxUA+QrG WndUasujMG/o6+oaPGg6t21otCoTkE0xSoSaiXp7VckXK3k3qKNZAxend/f52eSx0eGW 5Z1QcKDFWEDn/ZeYZSSZYUVCGM2pkJFo9b0/c0+Ww6zdTYFNJzKx6CY1RReGDbmpR/Rk rS+w==
X-Gm-Message-State: AN3rC/5BIzQEHt/iEOC1YLTzINzvVeJqkIn2If6xG5PjvjtHvyWnRmPaMPuztNF1UrFv+A==
X-Received: by with SMTP id q198mr1176951iod.99.1491917645077; Tue, 11 Apr 2017 06:34:05 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o72sm899260ite.10.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 06:34:04 -0700 (PDT)
Subject: Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)
To: Dave Dolson <>, "" <>, Stephen Farrell <>, Martin Thomson <>, "" <>
References: <787AE7BB302AE849A7480A190F8B933009E4B818@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E4B953@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <>
Cc: "" <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 12 Apr 2017 01:33:59 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Apr 2017 13:34:08 -0000

On 12/04/2017 00:03, Dave Dolson wrote:
> Regarding "benefits", these devices clearly have perceived benefits to those who deploy them. My view is that the document should explain that perspective for readers who lack the operator perspective.
> The intent was not to mandate or recommend deployments.

I'm not against facts, which was one of the reasons that I co-authored
RFC 3234. But in that document we worked hard to be as neutral as
possible. Revisiting the topic 15 years later seems like a good idea,
and focussing on transport-layer snooping is fine. But the tone would
need to be very neutral and the draft would need to present pros
and cons for this to be published by the IETF, I think. The topic is
one of the major ongoing tussles and the IETF needs to be completely

"This document advocates for transport connections to be measured and
managed by the network..."

That's opinion. We may describe, but we shouldn't advocate. Give the
doucment a good scrub to eliminate all advocacy, perhaps, and mention
the downsides for each upside?

One downside that doesn't seem to be mentioned is *finding* the transport
layer information. That will become increasingly difficult in future.

BTW I don't see ECMP or load balancing listed in section 3. Those
seem to be major applications of transport layer snooping.


> David Dolson
> ‎
>   Original Message
> From:
> Sent: Tuesday, April 11, 2017 7:48 AM
> To: Stephen Farrell; Martin Thomson;
> Cc:
> Subject: RE: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)
> Hi Stephen,
> Please see inline.
> Cheers,
> Med
>> -----Message d'origine-----
>> De : Stephen Farrell []
>> Envoyé : mardi 11 avril 2017 10:51
>> À : BOUCADAIR Mohamed IMT/OLN; Martin Thomson;
>> Cc :
>> Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
>> mm-wg-effect-encrypt-09)
>> Hi Med,
>> On 11/04/17 09:15, wrote:
>>>> 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.
>> Just to note that I completely agree with Martin's interpretation
>> of the thrust of this draft and I totally fail to see how your
>> argument above can be justified given that draft title, abstract
>> and even filename (and also the content;-).
> [Med] "beneficial" is derived from the initial request that motivated this draft (excerpt from the abstract):
>    At IETF97, at a meeting regarding the Path Layer UDP Substrate (PLUS)
>    protocol, a request was made for documentation about the benefits
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    that might be provided by permitting middleboxes to have some
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    visibility to transport-layer information.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  When the abstract
>> says "This document summarizes benefits" then I cannot interpret
>> that as other than being intended to justify the uses described.
> [Med] I would prefer if we can avoid to "interpret", but raise questions to the authors if there is a doubt. The document does not provide a recommendation or claims this is the only way to achieve the technical goals. It does only reflect some deployment reality together with some motivations.
>> A fairly thorough re-write to aim to describe the pros and cons
>> would be a different and more useful document.
> [Med] There are already many RFCs that discuss the issues/cons (I can cite this RFC I co-authored for the CGN case). What is needed IMHO is something else: understand the requirements that led to deploy some of these functions.
>  Similarly a draft
>> that strives to neutrally describe existing reality could maybe
>> be useful (*)
> [Med] This is the intent of draft-dolson.
>  but one that only describes middlebox friends with
>> "benefits" is not IMO beneficial ;-)
> [Med] The intent is not to "sell something" but to understand the technical needs so that hopefully we can have a reference for future solution-oriented discussions.
> If a given function can be provided without involving an on-path device, this would be great for operators (optimize CAPEX/OPEX is our motto).
>> Cheers,
>> S.
>> (*) That is the argument for draft-mm-effect-encrypt, for which I
>> do support publication (apparently in disagreement with Martin in
>> that case:-)