An OSI layer model for the 21st century (2014)
davidad.github.io
davidad.github.io
The problem with the ISO/OSI model is less how to fit real network protocols into it, it's more that it actually was proposed as a model for real network implementations, but TCP/IP, which does not fit well into the model, grew and displaced most other protocols and became the de facto standard for networking. This happened for multiple complex reasons that are not all technical.
If you ever spend any time with more than your standard wifi + NAT connection understanding L2 vs L3 vs L4 becomes very handy.
"This reference model provides a common basis for the coordination of standards development for the purpose of systems interconnection while allowing existing standards to be placed into perspective within the overall reference model."
It always made sense to me that the OSI model should be used to guide the development of internet standards. I have always doubted the second half of that statement, about understanding existing standards from an OSI perspective and I believe that is the mental gymnastics of which you speak.
Despite the mental gymnastics, out in the real world, me and my co-workers still find ourselves using OSI vocabulary to reason and talk about the networks we're working on.
If I'm told that some random black box is a "layer 3 switch" I already have a basic understanding of what it does and how to use it, even if I'm not familiar with the vendor. That's value for money right there, in my opinion.
The OSI protocol stack never gained much traction. Some of them were repackaged on top of TCP/IP--X.500 became adapted into LDAP, and SSL certificates are derived from X.509. X.400 is the OSI competitor to SMTP, and still sees some niche usage (just not for email). There may be some other ones floating about in terms of the telephone network infrastructure.
You can see a list of all 25 series (“W” is not assigned) and download most of the documents (including Rec. ITU-T A.12, Identification and layout of ITU-T Recommendations, which defines the letters) on the ITU’s website: https://www.itu.int/pub/T-REC
For a time, in the late 1990s, some regional ISPs effective ran over X.25 --- they leased shared "backbones" running Frame Relay (which is OSI stack); this is sort of like the phone company runs a backbone that you and some of your competitors buy and run IP over for your ISP customers. There are probably still some offices and retail chains that use frame and thus the X.25 stack.
My handle (twitter, email, whatever) comes from X.25. If you were a kid growing up on the mean streets of dial-up Internet in the 1990s, X.25 was a big deal. :)
https://en.wikipedia.org/wiki/TM_Forum#OSI/Network_Managemen...
And here:
https://books.google.com/books?id=k9sFgIM-z6UC&lpg=PT152&ots...
I've recently been working with LoRaWAN at a low level, and it's a great example of a standard that could have used the OSI layer to make it suck less for implementers. Lots of the encryption and checksum pieces mix up which layer they're working on. Building a nice clean layer cake for LoRa is a disaster, and I've resigned myself to just having a single big state machine that takes care of everything.
> Data Link and Physical layers For our purposes today, the Data Link and Physical layers are a black box (perhaps literally), to which we have an interface (the “network interface”) which looks like a transmit queue and a receive queue. These queues can store “payloads” of anywhere from 1 to 1280[1] octets (bytes).
1) The physical layer and data link layer almost always have different size and structure
2) Data link layer queues aren't defined by network layer payloads
3) IPv6 specifies a MINIMUM payload of 1280 octets
4) For most of the internet and private systems ~1500 is the standard payload limit due to the Ethernet standard.
> We would like a received payload to self-evidently be the same payload which was sent. Although the Data Link layer is supposed to provide such an assurance, various kinds of attacks on the system might invalidate this assumption. Integrity protocols mitigate these attacks: - 1 Thermal noise, cosmic rays checksum hash TCP Checksum CRC-32C
1) TCP Checksums are not part of and do not validate the data link layer headers.
2) Ethernet aleardy includes the FCS (CRC) as a form of check (as most data link layers have).
3) Physical layers also commonly have forms of integrity checking
> 2 Deliberate corruption cryptographic hash SHA-1 BLAKE2b 3 Spoofing of trusted contacts keyed hash HMAC-SHA1 SipHash 4 Spoofing of strangers public-key signature of cryptographic hash SHA-1 + RSA BLAKE2b + Ed25519
1) I'm not sure where these "common implementations" are comming from on the data link/physical layers, AES encryption via DTLS/MACsec or encryption via DTLS are the standards here.
> A fully implemented Availability layer should provide unicast (deliver to a unique endpoint authenticated by a given public key, wherever it may be), anycast (deliver to nearest endpoint authenticated by a given public key), and multicast (a.k.a. pub/sub: route to all endpoints who have asked to subscribe to a given ID, and provide a subscription method).
1) Multicast sounds great until you consider the billions of devices across untold number of paths on the internet and look at the line that started the paragraph "We would like networked endpoints to be available to receive packets from other endpoints in a way that is robust to unannounced changes in network topology.". It's hard enough today to announce and learn unicast paths between network aggregated endpoints and the author wants to add multicast paths/typologies to the mix while throwing out the abstraction of the port in favor of service based networking?
2) [personal opinion] moving more "work" from ports (which are supposed to be an inside the END NODE thing cough ipv4 NAT cough) into "the network" almost never seems to sell me on being a sustainable/worthwhile tradeoff. The less your layer needs to know to deliver something the more flexible and upgradable communication becomes.
> Confidentiality layer Ideally, we would like to not transmit any information to anything other than the destination endpoint(s). This ideal is not in general achievable on a public network, but some types of mitigation are possible: ...
1) A layer has to be more than "this is the encryption algorithm we use".
2) Encryption should not be a layer high up the stack, it should be something available at any point and able to be performed multiple times to allow levels of trust or defense in depth
3) Is there anything the author doesn't like about existing solutions for this layer like IPsec other than AES is most commonly used rather than ChaCha and similar variants?
> Non-Repudiation and/or Repudiation layer > We would like for a receiver to be sure that a message they receive was sent by a given sender, and we would like for a sender to be sure that a given message was successfully received. Sometimes, we would also like for a receiver to be unaware of the location a message was sent from
1) This layer needs to be fully option as
a) many real-time messages don't want confirmation information to bog things down
b) repudiation of origin needs to be optional unless society agrees it's more important than performance (it won't)
> Transactions layer
[personal opinion] this needs to be part of the application layer functionality to prevent the ossification of implementations and protocols.
General comment on the topic - The OSI model wasn't meant to be viewed like it is today and as a result spends a lot of time defining how to stratifying things that don't need to be stratified in the modern world. One thing I'd like to tell EVERYONE about network is "stop thinking of network models as a set of 1 dimensional abstractions".
I'm not knowledgeable enough to understand a lot of the complexities or issues with this, but from what I do understand it seems like he's thought through a lot of issues and provided cool solutions for them.