I’m posting these here not because they are particularly good (they weren’t) but because I wanted to leave them online after Internet Evolution, the site which originally hosted them, went away.
How Complexity Is Crippling the Internet
Written by David Manheim 1/11/2011
The layering of protocols and the intelligence of the Internet’s users, and attackers, are driving increased complexity.
The idea of having a seven-layer OSI model for networking was great until we realized that we’ve built another half-dozen layers above the session layer — and HTML and the old application layer are being used as a substrate for multilayer systems of their own. And the layers aren’t stable; they interact in complex ways.
The operating systems we use are an example of base complexity on which rests the entirety of our systems. The lines of code supporting the infrastructure of the Internet number in the tens of millions per OS, of which there are many competing versions. The code for each of these has been developed over decades and has been layered in ways that are not clear. Microsoft Corp.(Nasdaq: MSFT) still uses code that was originally in DOS, which was “replaced” by Windows 95, and still hasn’t changed much since then — not since Windows 3.1, 3.0, or possibly even earlier. Do we know what problems exist with that code?
A great example of how code reuse and undiagnosed problems can proliferate is found in the case of Gamma errors in picture scaling. There was a bug in how luminosity was computed for resizing. This was originally a logic bug in how software was implemented, and the color differences were small. The error was copied by almost every major piece of image editing software. It took decades for someone to notice what was wrong. Imagine if something similar happened in a piece of security software: Would anyone notice an extreme case that was included carelessly, or planted maliciously?
Is this surprising? Not really. The question is: How do you know what bugs are getting written into all of our software stacks? When was the last time someone reimplemented the software stack that runs our now-critical infrastructure? Is the TCP/IP stack routinely reimplemented, or is Windows using a very slight variant of what was implemented decades ago? I know that there are dialogue boxes that are essentially unchanged since Windows 3.1, and I would add that in almost every case, no one has rewritten the underlying logic or code; these boxes are still using a version of the same code that was written originally.
Code bases don’t take kindly to removal of code. Software stacks develop badly understood dependencies, which break when parts are replaced or reworked. We haven’t replaced IPv4 yet, originally created in 1981. IPv6 was first standardized more than a decade ago, and 10 years in, the new standard had a less than 1 percent adoption rate. We can’t replace parts that we know limit our existing networks, and we know we need more secure networks. Parts that only compromise network efficiency are even further down the list.
It is unclear how exactly these dependent code bases that exist almost everywhere will be made to work with most changes in complex pieces of code. Testing has grown at speeds exceeding that of the coding itself. According to blogger Larry O’Brien, since Windows 2000, the Microsoft internal testing teams are larger than the development team. Despite this, the code itself is almost unmanageable, and the completeness of testing regimes is approximate at best. We have no idea what will break when we upgrade.
As another possible approach, modularization, already a popular tool, can be utilized more fully. If we can make code bases fully modular, then we only need to worry about requirements changing; when that happens, we are back to the problem of complex dependencies in the code, and kludgy solutions involving compatibility with multiple versions of a protocol.
— David Manheim works as a terrorism insurance modeling specialist at Risk Management Solutions.