Network 101: Making the Connection

Published: 2024-09-29
Updated: 2024-10-01


I want to provide a bit of a broad, mixed bag overview of how computers communicate. To do that, we're going to use a few leading questions that you've probably heard or thought at one point or another. We'll start very simple and get more complex throughout this article.

The first is an age old question, often asked by family members once they learn that we work with computers, either as a job or as a hobby.

"Why can't my computer connect to the internet?"

To guide answering this question, and the other questions I'll be posing, I am going to use the Open Systems Interconnection (OSI) Model.

The OSI Model

Many people have heard of her, but very few have gotten to know her. Some may argue that the OSI Model is a little too abstract and kind of pointless, but I believe it is fundamental to actually understanding how computers communicate with each other, and useful in categorizing and describing the moving parts.

00-OSIModel.png OSI Model - Wikipedia

The nitty gritty specifics of the OSI model don't really matter for the purpose of answering our first question, but we can use it- specifically the Media Layers- to work our way through the troubleshooting process step by step to find a solution to our problem.

In terms of answering our question the first two layers go hand in hand, The Physical and Data Link layers. Chances are if you have The Physical, you have Data Link. Determining this is simple:

  • Is the computer plugged into a network?
  • Is your device connected physically to a Switch that is connected to a Router?
  • If there is no switch, is it directly connected to the router?

The Physical Layer also encompasses Wireless. Some devices connect to a network via a Wireless Access Point and achieve Data Link wirelessly. As long as at some point in the daisy chain of devices you reach a Router of some sort.

Network

Next is the Network Layer. Does your device pull an Internet Protocol (IP) address? Just because you're connected to another device and information is flowing, doesn't mean you've been addressed properly in the network. This is where something called Dynamic Host Configuration Protocol (DHCP) may come into play.

DHCP

90% of devices use this protocol to obtain a valid IP address from a Router (that in most cases run DHCP servers). Not all devices do this though, there are cases where a network can require you assign an IP to yourself because your router isn't handing out addresses. This won't be the case in most Residential households, as this is more prone to happen in Business and Enthusiast settings. DHCP consists of 4 steps:

  1. DHCPDISCOVER: The Client Discover message (or Packet, hereafter) is sent by a Client when it first connects to a new network
  2. DHCPOFFER: When a DHCP Server receives a Discover Packet, it will allocate an IP address for the Client, and send back an Offer Packet. This is Offer contains the IP that’s been allocated, the Netmask which determines the Network and Host segments of an IP, among other information for the prospective client.
  3. DHCPREQUEST: In response to the Offer, the Client will send back a Request to the server, requesting the offered address.
  4. DCHPACKNOWLEDGE: When the server gets this Request, they finish the configuration of tying the client to the IP it offered, and sends back an Acknowledgement.

01-DHCP.png DHCP in Wireshark

These are all done via Broadcast. When something is sent Broadcast, the Client sends out a message to EVERY Host on the network, terminated at the Router (or the Network Edge) so these messages don't bleed out into the Internet.

There's a bit more to the process. Since this is all done via Broadcast, there's the possibility that one or more DHCP servers may respond to a Discovery. So they use Client and Server IDs to identify each other, and the Client will only select one Server Offer to respond to by putting that Server's ID in its Request message. The other possible DHCP servers will see this, and drop the rest of the process and release the IP it may have allocated for their particular Offer.

But, what is my IP address?

There are a variety of ways to check this:

  • On Windows there's ipconfig or Get-NetIPAddress.
  • On Linux there's ip a.
  • On Macbooks there's ifconfig (although you might want to use ipconfig getipaddr en(0|1)).
  • And on most mobile devices there's a screen in settings that will tell you what IP you have.

If it's an IP from any of the valid Private ranges (192.168.x.x, 172.16.x.x, 10.x.x.x, most households will roll a 192.168.0.x address space), then you have successfully joined the local network.

We can verify this further with something called Address Resolution Protocol (ARP).

ARP

ARP is something a device will do automatically after joining a network, associating Data Link Layer addresses (MAC Addresses/Hardware Addresses) with their Network Layer Address (typically IPv4), using Broadcast messages just like DHCP (terminated at the Network Edge). We can see our devices ARP table in Windows and in Linux using arp -a.

02-ARPWireshark.png 02-ARPWindows.png ARP in Wireshark and in Windows

From here there's one more thing we can check. We want to make sure that we can reach other networks outside the local one. We can use a Network Layer protocol called Internet Control Message Protocol (ICMP) to verify a successful connection is being made to the outside.

ICMP

ICMP is pretty simple to explain. Essentially, it's the way network devices verify data transmission by indicating success or failure when communicating with another device. When in Error, it will usually tell you why the transmission is failing. This is very useful for troubleshooting connectivity between two hosts once you've established that you've successfully joined a network.

This is done with a utility I'm sure everyone is familiar with called ping. For simplicity sake, I like to try to ping the Google Primary DNS Server, which is 8.8.8.8. If you get a successful ping back from them, it's a pretty good indication you have a valid uplink to the Internet.

03-PingWireshark.png 03-PingWindows.png Ping in Wireshark and in Windows

If the computer is unable to receive a reply from Google's Primary DNS Server, then something might be wrong with your Router's uplink. From here, we can try rebooting the router to see if regains that uplink. If it does not this might be an Internet Service Provider (ISP) issue outside the scope of our local network. Time to make a phone call.

At this point we've likely finally answered our first question, fixed it, and can connect to the Internet. From here I want to pivot to my next question:

"What does a connection look like?"

This is where the rest of the OSI Model comes into play for understanding how computers communicate with each other. For the sake of brevity for these next few parts, I'm going to collapse Session, Presentation, and Application. Like the diagram from before refers to their Protocol Data Unit, we're just going to call it the Data. Traditionally, all that's going to matter when looking at network traffic is the Transport protocol and the Application protocol, or Data.

If we go back to when we were looking DHCP, and the communication that was taking place between the server and the client, we can see in the packet capture that this is all done via something called UDP. This is the Transport protocol of the connection, meaning that the two parties- Server and Client- will follow the rules dictated by this protocol.

Transport

There are more Transport protocols that exist besides just TCP and UDP, but I'm going to focus on just them because they are the most common.

TCP

Transmission Control Protocol (TCP) is a connection oriented protocol. Meaning that the Client and Server first must establish communication with each other and agree how they will communicate application data.

This is typically done via something call the "Three Way Handshake".

  1. SYN: A Server will listen for SYN request from a Client to SYNchronize.
  2. SYN-ACK: The Server will respond with a SYN-ACK back to the client with an ACKnowledgement of the Client's SYN request, and its own request to SYNchronize with the Client.
  3. ACK: The Client will then respond to the Servers SYN with its own ACKnowledgement.

After this is complete, the client and server can then move on to transmitting Data to each other.

Data

Let's use HTTP as an example.

  1. The Client will then send an HTTP Request Message to the server. For longer messages, Data can be sent in multiple packets, and those packets are sent ordered by a Sequence Number, which is then arranged by the Server in the proper order in case of mishaps during communication by that Sequence Number.
  2. The Server then sends back an Acknowledgement of every Sequence Numbered Packet it gets, ensuring the Client knows if something was lost in transit and if it has to retransmit some data. This ensures reliability in transmission, making this ideal for something like HTTP where data integrity is MUCH preferred. Once the transfer is complete and the Client has no more data to send, The Client can send a PSH or Push to the Server to indicate that it has completed sending and that anything the Server has received should be pushed to the Server Application.
  3. The process repeats with the Server response, the Server will send the Client back a response sent ordered by a Sequence Number, and the Client will then arrange it in the proper order, and Acknowledge every Sequence Numbered Packet it gets.

04-HTTPStart.png Start of an HTTP Connection with Data

When the Client has nothing more to request, it will close the TCP connection by:

  1. FIN-ACK: Sending the Server a FIN-ACK to FINish this connection.
  2. ACK: The Server will respond with an ACKnowledgement, and send its own FIN-ACK to finish to the client, which the Client will then ACKnowledge.

This is done in a Four Way Handshake rather than a Three Way, to allow either the Server OR the Client to initiate a Finish (where it's only possible for a Client to initiate a Synchronize). So it ends up looking like this, with the ACK and FIN being sent back by the Server in two different messages. But be aware that the two sides could be flipped, and the result would be the same, as illustrated below.

05-HTTPFinish.png Full HTTP Connection with FIN ACK part highlighted

UDP

User Datagram Protocol or UDP is a connectionless protocol. So that whole business with the SYNs the ACKs and the FINs, throw that all out. Responses are totally dependent on the Application at hand. The old joke goes "I'd tell you a joke about UDP but you might not get it" for a reason. It doesn't concern itself with Acknowledging anything that is sent over it.

But this is ideal for some applications where they don't necessarily want to go through the dance of SYNing and ACKing and retransmitting lost packets, where speed might be an important factor. This makes UDP ideal for things like Gaming, VoIP, or Streaming. This also makes it ideal for purely transactional messaging, like you find with Applications such as DNS or Domain Name Services, and DHCP. DNS is completely transactional, being handled in 2 packets. DHCP handles its business in 4 packets. Any TCP connection already goes through 3 packets just to get started on Application Data.

06-DNS.png DNS In Wireshark

So while TCP could be described as Reliable and Ordered, it can also be described as Overly Verbose, because it takes at least 3 packets to even start a full two way connection. But this comes with the benefit of ensuring the Integrity of the data being transmitted.

However, if you don't necessarily care about data integrity, if you just want speed and handle integrity via your Application, or if you just want to get your message out and get a response in as few packets as possible, then UDP is ideal.

If we look back at DHCP:

01-DHCP.png DHCP in Wireshark again

Being connectionless also means it can handle Broadcast messages, or messages sent to every host on a subnet. We see this in the DHCP packet capture because it sends its message to 255.255.255.255. This allows a Client to quickly send out its DHCPDISCOVER to all devices nearby, and wait for a Server to respond.

To wrap up, I want to tie all this back to Security. For our final question, we ask:

"How do I know that a Threat Actor can't read my connection?"

Encryption is how we take Data and make it unreadable to anyone who might be listening to or capturing our connections.

If we look back at our HTTP capture

07-HTTPFullTrimmed.png 07-HTTPFullFollow.png Full HTTP Connection

We see that the Client Request, and the full text of the Server Response are fully readable. This is problematic for a variety of reasons, but most of all say I send a request to a Server with a username and password, and that Server is not running HTTPS. Suddenly anyone on my network or the destination network can see it in plaintext.

To mitigate this, we have TLS or Transport Layer Security.

TLS

TLS is a part of the TCP protocol process, and it adds a few more steps in the establishment of a connection. It starts after the establishment of a connection, after the SYN SYN-ACK ACK. The general process will go like this.

  1. ClientHello: The Client will send a ClientHello which specifies the highest version of TLS the application on the Client side will support, suggested ciphers, and suggested compression.
  2. ServerHello: The Server responds with a ServerHello (shocker) containing the chosen TLS version, the cipher, and the compression method. The Server will also send its Certificate, which the Client will verify against its own Certificate Authority Chain. Every Browser used on the modern web comes with a package of Trusted Certificate Authorities that dictate which Certificates it will accept based on the Signing CA.
  3. ClientKeyExchange: The Client will then, based on the selected Cipher, send its Public Key back in a ClientKeyExchange message, and a ChangeCipherSpec message, which indicates that the conversation from then on will be authenticated and encrypted, along with an encrypted Finished message. All this in one packet.
  4. NewSessionTicket: Server responds NewSessionTicket, and its own ChangeCipherSpec and encrypted Finish. Likewise, all in one packet. From there the Encrypted Data will flow.

We went from 3 Packets to start a plaintext TCP connection, to 7 to start a TLS 1.2 connection.

08-HTTPSFullTrimmedTLS12.png 08-HTTPSFullFollow.png Full HTTPS Connection (TLS 1.2)

Now in the last 6 years TLS 1.3 has been adopted and has streamlined this process down quite a bit. After a SYN SYN-ACK ACK, they just do the ClientHello which INCLUDES the Public Keys of all its supported Ciphers, the Server can then select and send back a ServerHello with the selected Cipher with ChangeCipherSpec, its Certificate, and Finish all in one message. The Client then sends its own ChangeCipherSpec, and encrypted first message. This means it starts sending encrypted Application Data quicker than before, as illustrated below.

08-HTTPSFullTrimmedTLS13.png Full HTTPS Connection (TLS 1.3)

I mention TLS 1.3 simply to illustrate that even though we've all been using the internet for a long time, changes and optimizations are still constantly being made.

December 2013, just 11 years ago, the Google Transparency Report of Chrome Page Loads showed just 48% of worldwide web traffic was encrypted.

As of January 2024 its well over 90%

We've come a long way from the days of casually leaking data on Public Wi-Fi. In the last decade we've even had proposals for a new Transport Layer Protocol called QUIC, which rolls Encryption into the creation of a connection, and is established in fewer packets than even TLS 1.3. It's adoption in the connections for HTTP applications is starting to be supported by Browsers and Web Servers as we speak.

09-QUIC.png Comprison of TCP, TCP TLS 1.3, and QUIC

With changes and optimizations, however, can come unforeseen consequences. We never know how one day some changes may blow up in our faces. And especially with the growth of the internet and the sheer size of social media platforms of today, we never know when the next major security incident could occur.

In this writeup I hope to have imparted some Network knowledge to you that you can use to understand the Jargon used by Networking Personnel at your job. I also implore you to dig into tools like Wireshark and really dissect different Application data, using some of the information I've shared here as a foundation for gaining a wider understanding of computer networking.

Special Thanks to vert1cal and cosmicgumbo for offering edits and proofreading this article.


Tags: technology