The Battle Between Standards: TCP/IP vs. OSI (2003) [pdf]
doc.utwente.nl
doc.utwente.nl
Here are some of my favorite quotes from the book:
"the Internet community—people like Cerf and Kahn and Postel, who had spent years working on TCP/IP—opposed the OSI model from the start. First there were the technical differences, chief among them that OSI had a more complicated and compartmentalized design. And it was a design, never tried."
Not only was OSI "never tried":
"On the OSI side stood entrenched bureaucracy, with a strong we-know best attitude, patronizing and occasionally contemptuous"
“Everything about OSI was described in a very abstract, academic way,” [Vint] Cerf said. “The language they used was turgid beyond belief. You couldn’t read an OSI document if your life depended on it.”
Lastly, what I think is a nice and short summary of why TCP/IP "won":
"[the success of TCP/IP] provided an object lesson in technology and how it advances. “Standards should be discovered, not decreed,” said one computer scientist in the TCP/IP faction. Seldom has it worked any other way."
OSI TP4 eventually could do everything TCP/IP could, and Microsoft included it in NT (NT4 and Windows 2000, I think), so it did ship. But nobody cared much.
If grown-ups know better they should show us by shipping things. If I can't use it it doesn't exist.
IMHO one of the more general anti-patterns in security is to try to secure the network not the device. It's a fool's errand for many reasons, most notably the fact that there is an intrinsic trade-off between the transparency / audit-ability / firewall-ability of network protocols and the security of the protocol itself. A secure protocol is utterly opaque and therefore cannot be inspected at the perimeter. Secure the device. While it's important to pay attention to your network, if your devices are not secure netsec will not save you.
From a security perspective, most issues with modern computer security have absolutely nothing with the TCP/IP protocol. If you take a look at top 10 vulnerabilties (https://www.owasp.org/index.php/Top_10_2013-Table_of_Content...), none of them are directly related to TCP/IP.
It is always easier to look back in hindsight and criticize something knowing what we know today. Saying we should leave design to "grown-ups" is not a fair assessment of TCP/IP and its designers. Engineering is difficult and every design comes with trade-offs.
P.S. If you want to see truly bad protocols, look to ones designed by "professional", "grown-up", organizations. CORBA and anything WS-* are a few that come to mind.
[1] This wouldn't stop attacks, of course, but it would provide strong enough attribution to create a deterrence effect (at least in The Man's mind).
The TCP/IP community had Connectathons, where interoperability was verified between vendors.
I also must point out that the history of spec-ahead-of-time massive bureaucratic network standards efforts is extremely poor. These efforts tend to produce things that are complex, over-engineered, unwieldy, hard to deploy, and generally a mess. In some cases things never progress beyond the discussion phase, or if they do the result is far less interesting than the hype. It's basically the bad form of "waterfall" development.
All the most successful network systems I am aware of are developed first and then specified once the kinks are worked out. Step one is to make it work. Then you optimize it, clean it up, test it in the field, and then you spec it so others can interoperate with it. The result is seldom perfect, but it differs from the byzantine stuff in that it actually exists and people can use it.
Real but imperfect functionality always trumps non-existent perfection.
Byzantine ahead-of-time network standards bodies are part of this whole branch of "enterprise" software "development" that as near as I can tell doesn't actually build anything. I've seen it in action in other spheres too. They pick a big problem, gather specifications liberally, and then jawbone it to death. Sometimes small prototypes are produced (at ridiculous cost) that do tiny subsets of it poorly.
I cannot for the life of me understand why money is actually spent on this stuff. You would get far better results by taking the millions spent on these enterprise towers of babel and using it to hose down AngelList and fund startups doing things that are relevant.
(Edit: but... if you'd asked me I just would have shoved another 32 bits into IPv4 via an extension and done it in such a way that routers/gateways that supported a simple spec could manage that in a backward compatible way. Probably use a new protocol code + the port field + some extension bits to allow "IPv4-64" with /32 being the new /16 or /8. But V6 exists and already has traction so let's just go with it.)
IPSec and IPv6 mobility were great ideas that are poorly executed. In reality they should be closely bound -- you cannot securely or reliably implement endpoint mobility without authentication. But one-bird-one-stone is apparently some kind of dogma in networking circles. IPv6 is also a f'ing mess from an implementation standpoint. It's insanely complex to get set up given the simple thing that it is (or should be), and the language around it seems designed for maximal confusion ("left" and "right?" WTFOMGWHY? Which left? The right left or the left left? KILLMENOW.)
A much bigger disaster is WebRTC: https://www.pkcsecurity.com/blog#webrtc-flow
It's a byzantine mess with tons of acronym-laden moving parts and way too many things required under the same umbrella... and no all those moving parts are not necessary. NAT-t and mobile addressing do not require state diagrams that look like the Paris power grid. As a bonus cherry on top, WebRTC leaves the signaling mechanism unspecified. Batteries not included.
Now there's a simile that came out of nowhere. I'm amused and curious: what is it about the Parisian power grid that makes it stand out as terrible example?
:D
I have been told -- take this at unsubstantiated rumor level only -- that the NSA opposed the idea that all IPv6 stacks would use opportunistic encryption by default, and exerted influence to make sure that did not happen.
I have some folks I'm working with right now who are not super-technical. I need to send them some bank account digits. This is surprisingly challenging. I mean all I want to do is to encrypt a set of very important numbers very securely and send them, and there is no really good user-friendly way to do that. I sometimes wonder if that's accidental.
At the same time though: IPSec is a mess. It's overly complex, hard to deploy, and generally really annoying to use at the implementation level. I suspect that had as much to do with it as any protocol committee maneuvering.
One thing I don't understand about crypto protocol design: why do they end up including every damn algorithm under the sun? I mean, pick a good one at the time of design and use that and include a facility to enable it to be superseded if problems appear. Right now that would be AES+GCM or Salsa/ChaCha+Poly1305. Nothing else is worth using so why would you include it in the spec?
Some of this shit is inherited from SIP, which is a mess from the parsing on up. And people really get... committed ... to the mess they've made, because it's a "standard".
And here's how it shipped: (tcp_input.c)
/*
* TCP input routine, follows pages 65-76 of the
* protocol specification dated September, 1981 very closely.
*/
tcp_input(m0)
struct mbuf *m0;
{
}