On Jul 30, 2013, at 3:23 PM, Noel Chiappa wrote: >> From: Roland Bless <roland.bless@xxxxxxx> > >> 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