
An OSI layer model for the 21st century (2014) - dgellow
http://davidad.github.io/blog/2014/04/24/an-osi-layer-model-for-the-21st-century/
======
ndnxhs
What is the point of the OSI layers. It feels like some academic come up with
them and everyone has been going through mental gymnastics trying to work out
how to fit the real world on to it. The proposed new model doesn't seem to
make much sense either. How is IP integrity?

~~~
jcranmer
OSI actually developed an entire set of protocols for each of the layers that
adhered to the principles of their design. (Or at least they intended to, I
don't know if they actually got around to tackling all of the layers). It is
an entire networking stack that competes with the TCP/IP model, which was very
much _not_ designed in such a way, and thus does not mesh very well with it.

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.

~~~
chrisseaton
Do you know what the X stood for?

~~~
wsh
_X_ is just the letter prefix identifying the series of ITU-T Recommendations
related to “Data networks, open system communications and security.”

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](https://www.itu.int/pub/T-REC)

~~~
userbinator
Many more people who have never heard of the ITU will certainly be familiar
with the H series ("audiovisual and multimedia systems"), of which the video
codec H.264 is well known.

------
p1esk
The author, David Dalrymple, used to be a “wunderkind” (got into MIT phd
program when he was 14, etc), but lately he disappeared after briefly working
for Twitter. I wonder what is he doing now.

------
dang
Discussed in 2017:
[https://news.ycombinator.com/item?id=15058090](https://news.ycombinator.com/item?id=15058090)

------
zamadatix
This seems to be written by someone who spends a lot of time (and has a lot of
knowledge) about high level application stuff but lacks an understanding of
the existing network technology they are writing about or what purposes real
world networking models need to serve. Apologies for the huge block of text,
I'm not sure how to format this better.

> 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".

------
FridgeSeal
This is super cool.

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.

