On the "Glory" of the IP Protocol Suite

After reminiscing on yesterday's post for a while and reading up more on relevant documentation (OSI session layer, presentation layer, application layer, ACSE, CASE, ROSE etc.), I found that many functions were left out of the "IP suite of protocols" as it was back then - they did not deliver a whole toolkit, especially in the 80s and 90s when the big bang of Internet applications, and thus protcols, happened. "Oh wow I can open a TCP connection just like that and chat with my friend! How cool!" (which is probably how IRC got started - and they still have problems adding modern comforts into their protocol). But that's not a fully-working application protocol. The work starts after that you got a network layer connection. I myself wasted large amounts of time on inventing and researching and comparing and finding libraries etc. for solution after solution for the following areas:

• Segmentation of messages and message boundaries
• correlation of requests and responses
• Network layer security (basically VPN)
• Transport layer security (per-connection security as used in HTTPS - SSL/TLS like OpenSSL, LibreSSL etc.)
• Checkpointing, restart, resynchronization
• dead peer detection
• transactions, commitment, rollback
• handling protocol options, at all
• bargaining function units and service parameters, feature sets etc.
• handling versioning of application protocols (APIs)
• handling p2p scenarios
• realtime streaming, handling the specialities of realtime applications like catching up after a few seconds of lost signal
• proper multicasting
• congestion control
• authentication and authorization, certificates etc.
• reliable transfer and signed-off receipts
• reserved bandwidth (QoS)
• multi-homing
• tracking of protocol state and phases (login phase, data transfer phase, release phase) with different primitives allowed for each phase
• multi-user locking, tokens and capabilities
• encoding and decoding - there are gazillions of serialization formats out there, 98% of which are not better than ASN.1 with its various encodings, which range from XML to JSON, human-readable encodings to densely-packed binary formats or quick-to-parse binary formats etc. Also, writing the protocol messages down in ASN.1 format really helps you find holes in your own thinking and makes it easy to write (or generate!) client program libraries for various programming languages at once. How interesting with a 40 year old tech from the OSI effort. Technology which has been gradually updated, of course and is used to specify for example the 3G, 4G, 5G mobile networks how they move voice and mobile data, management, roaming, billing etc. - among many other really prevalent technological comforts we take for granted every day - like stable air traffic, planes not crashing, energy grids with interoperating energy providers, industrial sensor and control systems (today called "IoT" by the IP crowd) and thus keeping our society's underpinnings running.
• monitoring and management
• identifying and handling bad actors/users
• etc.

One might argue that this is not the job of a network protocol suite to do that, but it is definitely the job of a protocol stack when IP claims to have one, and where else than "in the presentation layer, the session layer, the application layer" would you put it? That is what the 4-layer "Internet protocol stack" does not mention, that the tricky part is mostly inside their "application layer". Reformulated, they merged the OSI session, presentation and application layer, into their IP "application layer" and called it quits (or, "out of scope") - data packets delivered, mission success! I would call the IP "application layer" the "not-my-problem" layer.

So I argue that the IP crowd of the 1980s and 1990s glorifying the IP-based Internet:

• cheated and merely delivered a pile of one-off protocols like bananaware, eg. ICMP, IGMP, RSVP, DHCP etc. etc. all are one-off protocols - leading to so many firewall settings and firewall queues like Linux iptables, ip6tables, ebtables, tc, bridge, ethtool, arptables etc. because you need to manage all these one-off protocols! and
• back then did not mention to the eager companies and programmers about the issues of network programming, distributed computing and which building blocks are still missing in their application layer and
• forgetting to mention that so much more was actually needed to deliver a comprehensive set of building blocks for real applications, which make for stable, compatible, secure and efficient-to-build applications.

So they presented "we have a simple solution that works now and it is free" - yes, but you guys forgot implementing a layer or two and stopped at the relatively easy ones - meaning up to TCP and UDP - and then complain that OSI took longer to develop than TCP/IP... Everything else was bolted on afterwards and NOT by the IETF, but in the many companies who developed suitable (again one-off and incompatible) protocols, some of which were brought back into the IETF for the RFC process.

Many of the horrible security problems, instabilities, unreliabilities and sheer incompatibility of network applications came from this incompleteness, because everyone had to develop many of the above-listed bulletpoints anew for his application, creating these aforementioned problems. It created a much bigger attack surface compared to a "do it right once" or toolkit/framework approach that is present in OSI thinking.

So much time was wasted in countless company-paid hours, taxpayer research money, IT nerd's sparetime etc. to explode into this foray of finishing the work of the bananaware that TCP/IP was back then. It was far from a "complete protocol suite".

This is what I dont like about the "glorious history of TCP/IP Internet" as portrayed.

Back to Gemlog