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

[<[e-mail]>]

Hi Nico, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Nico Williams [mailto:[e-mail]]
> Envoyé : mardi 11 avril 2017 19:19
> À : Stephen Farrell
> Cc : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; [e-mail]; draft-
> [e-mail]
> Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
> mm-wg-effect-encrypt-09)
> 
> 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.

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

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

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

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

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

> 
> Nico
> --