This post should give you enough google ammunition to find out whatever you need to explain the OSI model in interviews and not be stumped by things that you may encounter in the day-to-day.
The OSI model is a way to explain network communication. At work, you will come into contact with several (if not all) layers of the OSI model, so having it in your mind will help you work faster. Take some time to get a grasp of this, it will be useful all throughout your career.
This is the cable/air and signal running through it. Layer 1 describes how computers should send, receive, and interpret raw bits (ones and zeroes) coming in as pulses of electricity.
The series of bits and bytes sent over the wire are interpreted by network interface controllers (NICs) and need to adhere to certain standards based on what communication is going on, but you can think of physical as ones and zeroes over a cable or through the air (in the case of WiFi).
Most layer 1 protocols are not of much use without layer 2/3 protocols.
The second layer of the OSI model can be summed up as “the frames that contain all the information.” The bits sent through layer 1 need to have some sort of order to them, that is where layer 2 comes in.
A data frame contains information in basically two parts: One part corresponds to the data we are sending (this will be interpreted by layer 3) and where/how to send the data (using layer 1).
One thing that you may come into contact with a lot is MAC addresses. You may have seen this before, it is a unique identifier of the network interface controller, shown as 6 bytes shown in hexadecimal (AB:CD:EF:12:34:56). The delimiters can be either colons, or dashes.
If you see six bytes split by dashes or colons, that is a MAC address. As attackers, we may want to change it, as defenders, we can get valuable information and keep a list of MAC addresses. These addresses are unique to a device, however the first three bytes denote the manufacturer. The last three bytes are used to uniquely identify a machine. Manufacturers have several three-byte sets to use as the first half of a MAC address. There are lookup tables you can use to find out which code belongs to which manufacturer, and from there, you may use this information to your advantage.
Going up from data frames, the network layer describes how frames should be routed to reach their destination. Since we can only get a MAC address of a device that is directly in contact with ours (where the cable is connected / a device that transmits its MAC over the air), we need an address that will help navigate anything more complex than 2 computers with a wire between them.
The Internet Protocol gives us one such address… an IP address.
The way these work in real applications is that each computer gets its own IP address. Each IP address is linked to a MAC address. Then, when you want to communicate over several intermittent devices (such as a router, switch, etc.), the switch takes our packet, looks at a table where IP addresses and MAC addresses are shown together, and ba-da-bing, ba-da-boom, the switch has a MAC address it should send the information to.
As for IP addresses, there are two different types: public (such as 188.8.131.52, 184.108.40.206 or 220.127.116.11) and private (such as 192.168.1.230, 10.0.2.5 and 172.16.20.1). Public and private IPs cannot overlap. Private IP ranges are used in inside networks, public IP addresses are accessible from anywhere on the Internet. Therefore, from my home network in the IP range 192.168.2.0, I cannot send a packet addressed to your internal IP address if you are on a different network. That is where network address translation, or NAT, comes in. IPv6 tries to solve this, but we can discuss that in a later post specifically on NATing.
Now that we have a physical medium to send data, a physical address to send data to and an IP address that will resolve to MAC addresses in more complex networks, we need a method to ensure our packets to arrive in the order that we sent them in. The transport layer does this and much more!
Two types of transport protocol you may hear about most often are TCP and UDP. These are abbreviations for Transmission Control Protocol and User Datagram Protocol, respectively. While there are others, just knowing about TCP and UDP will help you along your way.
TCP: The Transmission Control Protocol is built around reliability when sending packets. The TCP protocol checks errors in transmission, and a connection must be established before sending any data packets - known as the three-way handshake.
First, we send a SYN packet, asking the other machine to open a connection. If the server wants to accept, it sends a SYN/ACK packet, saying it is okay to start sending/receiving data. To finalize the connection, we send an ACK packet, completing a connection and allowing the server and client to talk to each other.
Once we do start a data transfer, there are multiple packets sent to make sure a packet was received correctly. This adds some overhead on top of the data itself, but ensures that once we send something, we are almost guaranteed that it has arrived correctly.
UDP: Where TCP is like a carefully handled package with receipts about how it was sent and received, UDP is like picking up a basketball and throwing it in a dark room. Fuck checksums, fuck checking if the packet arrives at all, we just send data and we don’t care if it arrives safely.
Compared to TCP, where we want reliability at the cost of speed, UDP goes the other way. We send packets quickly, and if one or two get lost, they just get skipped. If you want a great example of UDP, think of Skype calls, VoIP calls, or any other live voice transmission. Videochats work the same way, however something like YouTube does not. With voice chats, if we lose a packet or two, the connection will miss a few syllables or words, but it will continue. Moreover, UDP does not require any checks, and so can withstand lost packets at the low cost of a choppy voice connection.
Although there are other protocols for the transport layer, these are the two you may use most often in cybersecurity. Everything else, you may google if you come across it ;-)
With TCP handling in the Transport layer, we have basically taken care of the session. With other transport protocols, this may not be as easy. This is where the Session layer comes in.
The session layer establishes, as it would seem, a session. A session makes it possible for us to take breaks or checkpoint our transmission without losing valuable data and having to resend. These communications can be full-duplex (both sides receive and send data at once), half-duplex (one side talks OR the other side talks) or simplex (only one side can talk in a given communication).
Think of them this way: Full-duplex is a phone call. You can both talk at the same time. Half-duplex is a walkie-talkie, you cannot talk and listen at the same time. Simplex is like listening to the radio, the communication goes only from the radio tower to your receiver, you cannot talk to the radio station.
The session layer contains methods for authentication, authorization, and session management (I know, too many session words at once)
The last-but-one layer is Presentation. This layer ensures that our data is encrypted and what format the data is actually in. It ensures that whatever message we send, the receiving party knows what to do with it. It handles compression and encryption, and prepares data for transmission by the underlying layers. A good example of this is SSL (or TLS, if we want to be more up-to-date).
Unfortunately, my OSI model knowledge is not deep enough, but GeeksForGeeks has a more detailed explanation.
We’ve come all this way, but it’s almost over! The last layer on our list is the application layer. This is the layer we actually interact with and use. The data received from the underlying layers is shown to us, and data we send is shipped off the other way back down. The application layer interprets data and based on how it is set up, it shows us this data.
Basically, you are now reading the result of these 7 layers working together to bring you the text in a format that an application understands and interprets. This site works on the HTTPS application protocol, but there are others you may know (and probably should learn about in the future):
There are too many to name, but these may be some we will discuss in more depth in the future.
I hope you have found this helpful. Below, you will find a vocabulary, but it is by no means exhaustive. If at any point you didn’t understand something, feel free to google further for it, the article should give you enough keywords, if nothing else.
- MAC address
- IP address
- [LAYER] protocols
- Network Address Translation (NAT)
- Three-way handshake
- TCP vs. UDP
- Applicaiton layer protocols