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

From: <[email-masked]>
Date: Tue, 11 Apr 2017 08:15:19 +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:[email-masked]] De la part de Martin Thomson
> Envoyé : vendredi 7 avril 2017 05:25
> À : [email-masked]
> 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.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2017 09:51:14 +0100

Hi Med,

On 11/04/17 09:15, [email-masked] 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;-). When the abstract
says "This document summarizes benefits" then I cannot interpret
that as other than being intended to justify the uses described.

A fairly thorough re-write to aim to describe the pros and cons
would be a different and more useful document. Similarly a draft
that strives to neutrally describe existing reality could maybe
be useful (*) but one that only describes middlebox friends with
"benefits" is not IMO beneficial ;-)

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:-)

---

From: <[email-masked]>
Date: Tue, 11 Apr 2017 11:47:48 +0000

Hi Stephen, 

Please see inline.

Cheers,
Med

> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : mardi 11 avril 2017 10:51
> À : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; [email-masked]
> Cc : [email-masked]
> Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
> mm-wg-effect-encrypt-09)
> 
> 
> Hi Med,
> 
> 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
> 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.   

> 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 https://tools.ietf.org/html/rfc6269 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
> 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).

---

From: Dave Dolson <[email-masked]>
Date: Tue, 11 Apr 2017 12:03:04 +0000

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.

David Dolson
‎
  Original Message
From: [email-masked]
Sent: Tuesday, April 11, 2017 7:48 AM
To: Stephen Farrell; Martin Thomson; [email-masked]
Cc: [email-masked]
Subject: RE: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)

Hi Stephen,

Please see inline.

Cheers,
Med

 When the abstract

 Similarly a draft

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2017 01:33:59 +1200

> 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
objective.

"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.

   Brian

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Apr 2017 12:18:34 -0500

> would be a different and more useful document. Similarly a draft

Documenting the good, the bad, and the ugly, would be much better than
documenting only the good.  Documenting only one half of the story seems
to me like a bad idea on its face.

> "benefits" is not IMO beneficial ;-)

Agreed.

I can think of a number of problems with middle boxes:

 - scalability

   Middle boxes may need to expend much more computational power in
   order to do more than forward packets, and they need to do this for
   as many extant packet flows as will fit on their pipes at full tilt.

   Middle boxes may also have to be stateful, which quickly turns into a
   morass.

 - security

   Middle boxes can get intrusive and require sharing either more
   information with the public at large, or more information with
   "trusted" middle boxes, which in turn requires more complex key
   management and more failure modes.

 - reliability

   More failure modes (see security above).  More middle boxes to
   inspect for diagnostics.  More middleboxes to fix.

 - extensibility

   Want to extend the protocol?  You can't.  You'd have to upgrade all
   the middle boxes first.  You can only get the extensibility that you
   can foresee.  If you screw up the first time, the screw up will take
   15 years to work out of the Internet in the best case, and in the
   worst case you'll never get it out.

I can probably add more later when I have more time for this thread.

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?).  Perhaps we can get some
of the benefits of middle-box-aware protocols without the middle boxes.
Suppose a secure middle-box quench protocol by which nodes under DDoS
can enable DDoS counter-measures in upstream routers...  Suppose a
generic, non-TCP congestion control capable but UDP-like transport with
a reusable header prefix and ICMP-ish messages for QoS and congestion
control...  I'm certain we can do more within the end-to-end model with
minimal middle-box involvement (though never zero; we need at least
packet forwarding middle boxes).

IMO the IETF must not publish draft-dolson-plus-middlebox-benefits as it
is today.

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Tue, 11 Apr 2017 09:31:41 -0800

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:

> 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.

Melinda

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Apr 2017 12:50:20 -0500

> 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 :)

> it's not likely to lead anybody to do anything differently.

I'm not advocating for publishing a more balanced document.  I only
advocate not publishing draft-dolson-plus-middlebox-benefits.  If the
authors come back with a more balanced document, I might be willing to
support it, though I can say right now that I would expect the result to
favor the end-to-end model, and if it ended up advocating middle boxes
much more intelligent than routers then I'd be surprised.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2017 19:26:20 +0100

Hiya,

On 11/04/17 12:47, [email-masked] wrote:
> Hi Stephen,
> 
> Please see inline.
> 
> Cheers, Med
> 
>> -----Message d'origine----- DeÂ : Stephen Farrell
>> [mailto:[email-masked]] EnvoyÃ©Â : mardi 11 avril 2017
>> 10:51 Ã€Â : BOUCADAIR Mohamed IMT/OLN; Martin Thomson;
>> [email-masked] CcÂ :
>> [email-masked] ObjetÂ : Re:
>> draft-dolson-plus-middlebox-benefits (was RE: Review of draft- 
>> mm-wg-effect-encrypt-09)
>> 
>> 
>> Hi Med,
>> 
>>>> 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.
>> 
>>> 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.
>> 
> At IETF97, at a meeting regarding the Path Layer UDP Substrate
> (PLUS) protocol, a request was made for documentation about the
> benefits ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

Well, just because someone asks for something doesn't mean
it's always a good idea to give it to them. I also not that
the quoted text is silent as to whether the downsides ought
also be documented. But regardless of whether or not there
is a desire for this document, in anything like it's current
form, I'd be one voice opposed to publication.

> [Med] I would prefer if we can avoid to "interpret", but raise
> questions to the authors if there is a doubt. 

Mine was a comment not a question. I think both can be valid.

> 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.

I disagree that the above fairly describes the current text.

> [Med] There are already many RFCs that discuss the issues/cons (I can
> cite this RFC I co-authored https://tools.ietf.org/html/rfc6269 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 (*)
> 

If so, I think that the current text is very very far from being
ready.

S.

> [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.
>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2017 19:34:04 +0100

On 11/04/17 13:03, Dave Dolson wrote:
> Regarding "benefits", these devices clearly have perceived benefits

I do not agree that the IETF ought described perceived benefits
as if the claimed benefits accrue as hoped for. That is far too
close to marketing. In a contentious case like this, I can see
why someone may feel that's useful as a form of balance or part
of a larger debate, but in the end I think we need to step back
and take an engineering approach.

S

> 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.
> 
> David Dolson â€Ž Original Message From: [email-masked] 
> Sent: Tuesday, April 11, 2017 7:48 AM To: Stephen Farrell; Martin
> Thomson; [email-masked] Cc:
> [email-masked] 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
>> [mailto:[email-masked]] EnvoyÃ© : mardi 11 avril 2017
>> 10:51 Ã€ : BOUCADAIR Mohamed IMT/OLN; Martin Thomson;
>> [email-masked] Cc :
>> [email-masked] Objet : Re:
> questions to the authors if there is a doubt. The document does not

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 11 Apr 2017 20:54:09 +0200

> seem to be major applications of transport layer snooping.

no, any load balancing which needs to scale needs to be stateless, so
you don't want session based mechanisms handling this.

Nick

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 11 Apr 2017 20:17:51 +0000

On 2017-4-11, at 11:26, Stephen Farrell <[email-masked]> wrote:
> But regardless of whether or not there

+1

I am surprised to see this even being proposed for publication, given the comments after the IETF-98 presentation.

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2017 14:26:35 +1200

> you don't want session based mechanisms handling this.

Server load balancing is often stateful, and even stateless SLB
usually includes transport info in the hash. Or so I learned while
working on RFC 7098. People who know also informed me that ECMP
sometimes (not always) uses transport info (see RFC 6438).

   Brian

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 11 Apr 2017 21:55:49 -0700

Brian,

ECMP and LAG (often same code) in most cases indeed use 5 tuples to populate hashing buckets for per flow load balancing.
Cheers,
Jeff
On 4/11/17, 19:26, "ietf on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    
       Brian

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 06:44:12 +0000

Hi Nico, 

Please see inline.

Cheers,
Med

> De : Nico Williams [mailto:[email-masked]]
> Envoyé : mardi 11 avril 2017 19:19
> À : Stephen Farrell
> Cc : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; [email-masked]; draft-
> [email-masked]

[Med] The point is there are RFCs that describe the issues of middleboxes. The initial intent of draft-dolson was to describe the expected functionality (called benefit in the draft) for enabling some of these functions. Superior solutions may exist but these solutions need to understand first what is the expected service; hence the need for a reference (this document) to understand the trade-offs.
 
The draft can be updated with a section that identifies issues but I'm afraid that text won't be original compared to what was already documented in, e.g., RFC3234 or in specific documents such as RFC6269.

>    worst case you'll never get it out.

[Med] This is a fair list (even if some of the items are implementation-specific and/or are valid for some middleboxes not every middlebox). I can add another important item for an operator:  their cost. 

The important question then is: Why given the operational hurdles (reliability, diagnostic, ..) and costs to deploy and operate them, these functions are (still) enabled in operational networks? 

> IMO the IETF must not publish draft-dolson-plus-middlebox-benefits as it

[Med] This is not a frozen document. It can be updated to include comments. Your inputs are more than welcome.

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 07:09:19 +0000

Hi Melinda, 

Please see inline. 

Cheers,
Led

> De : ietf [mailto:[email-masked]] De la part de Melinda Shore
> Envoyé : mardi 11 avril 2017 19:32
> À : [email-masked]
> 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
> 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**.

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 07:49:50 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : ietf [mailto:[email-masked]] De la part de Nico Williams
> Envoyé : mardi 11 avril 2017 19:50
> À : Melinda Shore
> Cc : [email-masked]

[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.

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 08:13:58 +0000

Hi Stephen,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 11 avril 2017 20:34
> À : Dave Dolson; BOUCADAIR Mohamed IMT/OLN; Martin Thomson; [email-masked]
> as if the claimed benefits accrue as hoped for.

[Med] I'm afraid it is hoped for some functions. For example, the IETF specified in the past many functions to provide specific services (called benefit in draft-dolson) such as NAT64 (IPv4 service continuity).

If you don't perceive that function as a "benefit", can you please answer the following: 

* Because your operator is running out of IPv4 addresses, it decides to give you an IPv6 prefix without enabling any function in the network. Won't you call the hotline of that operator to claim that you don't access to most of Internet resources and that something is to be fixed otherwise you will unsubscribe?

* When you are attending an IETF meeting, I assume you are using IPv6-only SSID. Do you volunteer to opt-out from NAT64 in the coming meeting?

 That is far too
> and take an engineering approach.

[Med] Fully agree. This is why we need to understand the intended usage to have a reference for any engineering approach.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Apr 2017 09:35:27 +0100

Hiya,

On 12/04/17 09:13, [email-masked] wrote:
>> 20:34 Ã€Â : Dave Dolson; BOUCADAIR Mohamed IMT/OLN; Martin Thomson;
>> [email-masked] CcÂ :
>> I do not agree that the IETF ought described perceived benefits as
>> if the claimed benefits accrue as hoped for.
> 
> [Med] I'm afraid it is hoped for some functions. For example, the
> IETF specified in the past many functions to provide specific
> services (called benefit in draft-dolson) such as NAT64 (IPv4 service
> continuity).

I'm not sure that s/benefits/services/g in the document text
would work, so I don't accept that argument. If you meant
something else, I'm not sure what.

> * Because your operator is running out of IPv4 addresses, it decides
> to give you an IPv6 prefix without enabling any function in the
> network. Won't you call the hotline of that operator to claim that
> you don't access to most of Internet resources and that something is
> to be fixed otherwise you will unsubscribe?
> 
> * When you are attending an IETF meeting, I assume you are using
> IPv6-only SSID. Do you volunteer to opt-out from NAT64 in the coming
> meeting?

I did not argue that no middlebox ever provided any benefit
to anyone so I don't know how answering the above questions
would help.

But in case it does help: yes, firewalls have provided some
benefits over the years. I suspect those are now diminishing
but could be wrong. I don't know if it's gotten to the point
that firewalls are more of a benefit or a scourge today. (Having
just had the fun of installing a stun/turn server to get two
browsers to chat with one another, I can freshly attest to the
"pointless scourge" aspect as I didn't have to ask the f/w
admins anything to get around the useless barrier they were
in this particular case;-)

It might be possible to do studies and produce data that'd help
the community decide that question (f/w utility vs. scourge) and
that could be a useful activity, if done objectively. That last
(objectivity) seems hard though, as it seems there are many folks
who find being objective in this space difficult (on all sides).
I've no idea if similar studies and data could help with
(re-)evaluating other aspects of middlebox deployment claimed
utility.

And again, I see no utility at all in a statements along the
lines that "firewalls are beneficial because they can do X."

S.

> 
> 
> That is far too
>> close to marketing. In a contentious case like this, I can see why
>> someone may feel that's useful as a form of balance or part of a
>> larger debate, but in the end I think we need to step back and take
>> an engineering approach.
> 
> [Med] Fully agree. This is why we need to understand the intended
> usage to have a reference for any engineering approach.
> 
>> 
>> S
>> 
>>> 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.
>>> 
>>> David Dolson Ã¢â‚¬Å½ Original Message From:
>>> [email-masked] Sent: Tuesday, April 11, 2017 7:48
>>> AM To: Stephen Farrell; Martin Thomson; [email-masked] Cc: 
>>>> [mailto:[email-masked]] EnvoyÃƒÂ© : mardi 11 avril
>>>> 2017 10:51 Ãƒâ‚¬ : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; 
>>>> [email-masked] Cc : 
>>>> [email-masked] Objet :
>>>> Re: draft-dolson-plus-middlebox-benefits (was RE: Review of
>>>> draft- mm-wg-effect-encrypt-09)
>>>> 
>>>> 
>>>> Hi Med,
>>>> 
>>>>>> 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.
>>>> 
>>>>> 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):
>>> 
>>> benefits
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that
>>> might be provided by permitting middleboxes to have some 
>>>> says "This document summarizes benefits" then I cannot
>>>> interpret that as other than being intended to justify the uses
>>>> described.
>>> 
>>> 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
>>> https://tools.ietf.org/html/rfc6269 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
>>> [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:-)
>>>> 
>>>> 
>>>> 
>>> 
>

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 09:03:22 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 12 avril 2017 10:35
> À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Martin Thomson; [email-masked]

[Med] Cool. This is not what I understood from your initial comment: "...if the claimed benefits accrue as hoped for"
                                                                                                          ^^^^^^^^^^
> to anyone so I don't know how answering the above questions

[Med] I helps to understand what we can call "beneficial" or not. Having concrete examples is helpful. 

> who find being objective in this space difficult (on all sides).

[Med] Yes, that's a collective effort to be made by all. In the meantime, we need to remember that IETF is supposed to do ENGINEERING.

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Apr 2017 13:33:50 +0200

Hi Lars, hi all,

this document is not proposed for publication at this time. This thread involved out of some comments on draft-mm-wg-effect-encrypt which is currently under IESG reveiew.

Further, this document was discussed and presented in the tsv-area meeting at IETF-98. My summary is that there was good discussion about this document and not all comments were negative. I would even say that there is interest on further working on this document. However, this document is not part of any working group and as such it solely depends on the authors to incorporate comments and drive this forward. Further note that this document is in an early state and therefore is still work in process. Comments, feedback, and contributions are more than welcome, I believe. The comment that the document should be more neutral was already made during the presentation and was probably well-understood by the authors. Please also see my next mail as reply to another comments that were made in this thread regarding the intention of this draft.

Mirja

> Am 11.04.2017 um 22:17 schrieb Eggert, Lars <[email-masked]>:
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Apr 2017 13:52:02 +0200

Hi Nico, hi Stephen, hi all,

replying to this mail because that seems to be the right point to comment on the intent of the draft (and maybe also why it was presented in tsv-area).

Yes, this draft could be phrased in a more neutral way, however, this draft is in an early state and the author received this feedback already in tsv-area. I’m sure they will incorporate this in the next version.

But more important to say is that the intent is not to describe the good and the bad or the pros and the cons. This would be a completely different document. The intent of this document is actually to describe the benefits in the sense of why do operator deploy those middleboxes. Deploying and operating middleboxes costs money (and induces complexity, as described below in this mail) but there are still perceived benefits for operators otherwise the would not go through the hassle. Understanding these benefits is the first step to have a discussion on how to replace current practices as performed by middleboxes today with either end-to-end schemes, or at least middleboxes that are less intrusive or maybe find a way to provide in-network services with user consensus, or whatever… This document can be seen as input from operators to the IETF community. Again, I agree that any language that indicates any request to the IETF community to support any of these current practices should be removed. But I also believe it’s easy to misinterpret the current text if that’s what you already have in mind when you read the doc. And again, this is work in progress and that is not the indention.

Further, regarding the points listed below on problems with middbleboxes. This would be a completely different document, which could be valuable as well. However, here the focus would be providing information to the operators and I really wouldn’t want to mix this up. Also I believe especially for such a document the current document could be good input as a basis to refer to when discussing specific problems of specific functions. 

The more constructive next step I would like to see, where this document from my point of view also provides the basis for the needed input, is to talk about mechanisms that realize the same benefits in an encrypted world, hopefully with less middbleboxes, and then point the operators at these documents, rather then just saying: what you do is bad, please stop.

Mirja

> Am 11.04.2017 um 19:18 schrieb Nico Williams <[email-masked]>:
>

---

From: Matthew Ford <[email-masked]>
Date: Wed, 12 Apr 2017 14:29:16 +0100

> On 12 Apr 2017, at 12:52, Mirja Kühlewind <[email-masked]> wrote:
> 
> describe the benefits in the sense of why do operator deploy those middleboxes.

Then don’t call them ‘benefits’ - they aren’t universally of benefit. Call them ‘motivations’ or something, but I think a lot of people are reacting to the use of the word ‘benefit’ as that tends to imply something that is necessarily good. Beauty is in the eye of the beholder.

Mat

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Apr 2017 15:39:31 +0200

Sure, I also figured in the mean time that using a different word could help. However, from the operators perspective there has to be something good which provides an actual positive value for them, otherwise it would not justify the costs. 

However, I strongly agree that "benefits provided to the Internet“ is completely overstated. Maybe this should be "benefits provided to the network“ or "benefits for the network operator“ but I also do believe that the operators do this because they want to improve „the Internet“ and doing something within their own network is the only handle the (currently) have. Or, as you say, we just don’t use the word benefit at all if that helps!

Mirja

> Am 12.04.2017 um 15:29 schrieb Matthew Ford <[email-masked]>:
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 10:33:33 +1000

> do support publication (apparently in disagreement with Martin in

Taking a break from email is so refreshing...

I would very much like to see a document like this that captures these
use cases and practices.  The problem I have with it are simple: it
isn't particularly coherent, and it makes statements that I disagree
with.  Those statements are particularly bad because they are also
unnecessary (see Brian Carpenter's comments about facts).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2017 02:16:57 +0100

On 19/04/17 01:33, Martin Thomson wrote:
> isn't particularly coherent, 

Hmm. Two things to consider there: 1) the editors have AIUI tried
hard to collate offered text from various folks and that's fairly
likely to end up less coherent, so we shouldn't insist on a level
of perfection here that we'd not ask from something with which we
might more "natively" agree.

But possibly more interestingly: 2) I think it's arguable that
coherently arranging the set of descriptions here is hard, and I
think that may tell us something about the underlying logic of
the situation.

For me the lesson of that innate incoherence is that the set of what
are now shown (in 20:20 hindsight) to be somewhat "lazy" practices
are being demonstrated as problematic via the re-assertion of the
e2e argument using confidentiality mechanisms, even where those latter
confidentiality mechanisms aren't in fact deployed "fully" e2e. And
that argument is quite close to the ossification one that transport
folks seem to like. The incoherence of the argument as to why
confidentiality is "problematic" seems to me more a fundamental
weakness in that argument against confidentiality rather than a
failure of exposition in this particular draft.

> and it makes statements that I disagree
> unnecessary 

I do agree that the draft ought not be recommending things or to
be saying that such-and-such a practice is "necessary." But I did
think we'd gotten rid of those. Mopping up remaining statements of
that sort would be good, I agree. There were a lot of them in the
contributed text that the editors already excised. (In saying that
I did not go through your detailed review checking stuff - now that
I've escaped the IESG I'm fine that someone else does that:-) And
of course, the fact that you or I only "disagree" isn't really a
good criticism, we need an argument that those statements aren't
well grounded or similar, but I guess that's what you meant.

Cheers,
S.

> (see Brian Carpenter's comments about facts).
>