On Jul 30, 2013, at 3:23 PM, Noel Chiappa wrote:
From: Roland Bless <roland(_dot_)bless(_at_)kit(_dot_)edu>
we probably need to do something on reducing the number of _broken_
middleboxes (or their implementations respectively) - I'm not focusing
on NAT boxes here.
...
I think it's clear that we will not get rid of them, but if I hear
about boxes that try to do "clever optimization" or "security" by
re-writing TCP sequence numbers ... bundling segments and so on, I'm
wondering who actually engineered those boxes; aren't the
vendors/engineers participating in the IETF? Who buys and deploys such
boxes
...
What could be IETF efforts to get a better situation for the deployment
of future innovations or do we simply accept that (a few) broken
middleboxes dictate the future level of innovation in the Internet?
I hear you, but... this is not a simple problem.
I think we need to start by understanding what drives the creation and
deployment of these devices. I think the answer to that has to be that some
people have needs that aren't being met by the IETF, and so there's an
opportunity for private entities to create and sell 'solutions'.
The IETF doesn't have a police force, or any enforcement mechanism.
That's true, but people do sometimes cite IETF specifications as requirements
for equipment procurement. And in many cases it is possible to test equipment
for conformance to specifications.
If we're
going to head off these boxes, the only tool we have to do that is to build
better mousetraps - i.e. design stuff that does what people want, is more
cost-effective, and is better than these local 'point deployment' boxes.
That's not the "only tool" (see above), but to the extent we're failing to
address legitimate needs, we need to identify those needs and see what we can
do to address them. And we need to do this as early as possible, ideally before
we've gone down a particular path so far that there's too much deployment of a
protocol that can't be retro-fitted to address those needs. We have no
structure at all for doing this now.
Sadly, the IETF has a long history of being hard-headed about 'my way or the
highway', and not carefully listening to what the 'customers' are telling us
about these various aspects of a successful design.
I suspect it's worse than that. We don't even know who our customers are.
(The most noteable example of this being NAT - which was going to be ugly
anyway, but as a result of the IETF refusing to create an architected NAT
solution - apparently on the theory that if we stuck our fingers in our ears
and went la-la-la-la loud enough, it would Just Go Away - we now have NAT that
is both ugly _and_ brittle [because it's not part of an architected _system_],
difficult to work with because it [mostly] lacks any external control
interface, etc.)
It's ridiculous to say that we have NAT because we didn't architect NAT. NAT
has never been a good idea from any long-term point of view. The only
justifications that have ever existed for NAT were short-term hacks. Our
mistake, in hindsight, was in not specifying NAT in such a way that they
provided a transition path away from NATs. (perhaps something like PCP in
conjunction with v4/v6 NAT, though there's a huge privacy/security problem with
that kind of approach that I've never figured out how to address, so I'm
inclined to think that PCP makes things still worse.)
Though of course an underlying problem is that no vendor wants to sell hardware
that will obsolete itself, unless of course it obsoletes itself by requiring
the customer to purchase even more expensive hardware than it replaces. It's
hard to see how IETF could fight against vendors who were making good money by
making the network more complex, less reliable, and less flexible.
Keith