ietf
[Top] [All Lists]

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

2017-04-11 12:18:58
On Tue, Apr 11, 2017 at 09:51:14AM +0100, Stephen Farrell wrote:
On 11/04/17 09:15, mohamed(_dot_)boucadair(_at_)orange(_dot_)com 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

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.

that strives to neutrally describe existing reality could maybe
be useful (*) but one that only describes middlebox friends with
"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
-- 

<Prev in Thread] Current Thread [Next in Thread>