TL;DR: TCP/IP shipped. (Edit: first. Some OSI stuff did ship, as another poster pointed out, but much later and by then it didn't matter.)
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.
"history of spec-ahead-of-time massive bureaucratic network standards efforts is extremely poor"
Do you think this applies to IPv6? I understand the need, but it's still difficult to implement IPv6 even for knowledgable people let alone the 'plug & play' experience of IPv4 with all devices today. But how could it have been developed first then specified?
IPv6 has a bit of this disease. From what I can tell the core of IPv6 is fine, but it has too many extensions and many are half baked or over-engineered. IMHO the core of IPv6 will get adopted and will work just fine and the rest will get left behind. The most important thing is the extension of the IP address space to 128 bits, which gives us plenty of room to do all kinds of interesting real things with addressing.
(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.)
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?
"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."
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?
God WebRTC looks like a clusterfuck. Plus the mandatory encryption... only to punt on the signalling issue. Oops.
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".
Microsoft has already announced that they will do their own 'spin' on WebRTC. Chrome and Mozilla WebRTC are not perfectly compatible in the field from what I hear. I predict failure.
The article misses a big point. The OSI model originally envisioned operating over X.25 connections operated by telcos. Then came local area networks. Most network traffic was, for a long time, local; in business settings, it often still is. TCP/IP worked well both for local and distant networking, and worked through gateway choke points between LANs and larger networks. X.25 over a LAN was a huge mismatch; X.25 was intended for slow links.
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.
The elephant in the corner of the room is that TCP/IP is a bad protocol. That's why hacking is on the front pages of the newspaper every day now. Sometimes it is better to let the grown-ups design things.
TCP/IP is perfectly fine. It's the security of endpoints (OSes, language runtimes, etc.) that sucks and is largely responsible for our perpetual security disaster. Why do we still have buffer overflows in 2015? OSI would not save us from that. If anything, the byzantine complexity of OSI would result in giant blobs of C code that contain even more vulnerabilities. Complexity is a very bad thing security-wise-- a linear increase in complexity always leads to an exponential increase in opportunities for bugs. Bugs in turn are fixed in linear time. Exponential effects always trump linear ones, hence our security nightmare.
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.
By what stretch of the imagination is TCP/IP a bad protocol? It is a 30+ year old standard that is still in wide use today. It has managed to scale from a few networked computers to billions. From an engineering perspective, TCP/IP is a good protocol.
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.
I assume that if the Internet had been designed "correctly" with public-key authentication down to the individual user [1] (with $300 VeriSign certs, natch) then it would have been too expensive and brittle for universities, hobbyists, or home enthusiasts to use and thus a rebel hacker alliance would have created their own "insecure" network (with porn and worms! and rants about "the right to network"). Maybe it would have been some sort of real-time upgrade to FidoNet.
[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).
It may have shipped, but the issue was that there was very little interoperability. Two independent implementations probably could not communicate, which seriously hindered adoption of the OSI model.
The TCP/IP community had Connectathons, where interoperability was verified between vendors.
The book "Where Wizards Stay Up Late" by Katie Hafner has a nice overview of this battle of standards.
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."
Famous last words: A case in point is the lack of space of the Intemet addressing system that emerged in I994 due to an explosive growth of Internet. This may now be solved by replacing IP version 4 (Ipv4) by IPv6, which implementation is underway since about 2000. (p. 173)
22 comments
[ 3.0 ms ] story [ 63.1 ms ] threadI 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)
.... 979 lines ... Thank you Mr. Joy!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.
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."