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

[Nico Williams <[e-mail]>]

On Tue, Apr 11, 2017 at 09:51:14AM +0100, Stephen Farrell wrote:
> On 11/04/17 09:15, [e-mail] 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
--