Hi Nico,
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : Nico Williams [mailto:nico(_at_)cryptonector(_dot_)com]
Envoyé : mardi 11 avril 2017 19:19
À : Stephen Farrell
Cc : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; ietf(_at_)ietf(_dot_)org;
draft-
dolson-plus-middlebox-benefits(_at_)tools(_dot_)ietf(_dot_)org
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, 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.
[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
--