The OSI Model is a referencing model that outlines how communication goes from one device to another. It is a 7 layered model where each layer has its own functions. To learn more about the OSI and TCP/IP models, click here.
Part 1: Examining HTTP Traffic
In this section, we use a simulated environment between a web server and a web client. This model was provided to CyberShujaa students for the assignment. The objectives in this task were to send a HTTP request from the web client to the web server and analyze how the data flows between them. To do this, we need to go into simulation mode on packet tracer, show HTTP traffic only using the filters available, go onto the browser of the web client and type in www.osi.local and let the magic happen.
Once the request is sent, there are 4 events that will be recorded in the event list pane of packet tracer. We will inspect each of these events to learn more. Some terms that are useful to know for this exercise are PDU, Outbound PDU, Inbound PDU, OSI Model, IP address and MAC address.
In the first event where the request originates from the client, the PDU contains different information for the different layers of the OSI model. At Layer 7 (Application Layer), we can see the HTTP request itself specifying the host name of the server. At Layer 4 (Transport Layer) we can see
the mention of connection protocol is specified as TCP, the source and destination ports are also mentioned. In layer 3, the source and destination IP addresses are shown. The destination IP address is found using DNS resolution which is not covered in part one of the exercise. In layer 2 we can see that the source and destination MAC addresses are added to the data. This is found using ARP scanning in the network and since the destination is in the same subnet, its MAC address can be found in the ARP table. After this the data is encapsulated and formed into a frame. At layer 1, the data is prepared to be sent out by using buffers, at this point the data is in bits.
In the next event in the list, the data is sent out to the web server from the web client through the client’s buffers. The size of the data being sent is usually decided upon when setting up the connection. It can be referred to as the window size.
The third entry in the event list shows the data being received by the server. If you compare the first instance and the third instance, you will see that the inbound PDU of at the third instance is the same as the outbound PDU in the first instance. This is because this is the same data being sent out
by the client but now being received by the server. This allows the server to cross examine the destination IP, port and MAC details to its own and validate that it is the one being spoken to. The server then sends out a reply to the client. In this response, the server is now the sender/source of
the information and the client is the receiver/destination of this data. Therefore, the source IP, port and MAC is that of the server and the destination IP, port and MAC is that of the client.
The fourth entry in the event list signifies the inbound PDU that came from the web server in event 3. This PDU contains the HTTP response together with the destination IP, port and MAC address for validation by the client as the data is decrypted and goes up the layers of the OSI model. The next
few images show the PDU details captured from the 1st to the last event in this exercise.
Part 2: Display Elements of the TCP/IP Protocol Suite
In this activity we will be using the same model provided, but we will be showcasing all the protocols that the client and server use to establish a successful communication. To do this we use the show all/none filters button and ensure that all the filters are selected. Performing the same steps as the previous part and letting the communication establish itself, we can see a couple of new entries into the event list. These entries have labels like DNS, TCP and HTTP. We shall inspect these further.
DNS stands for Domain Name System and its function is to provide the corresponding IP address for a hostname. In our case, the hostname is www.osi.local and the DNS requests resolve this name and provide the client with an IP address which is 192.168.1.254. By clicking on the first DNS event, we see the DNS query in the Outbound PDU under PDU format. This query has mention of the hostname but no IP address in the query sent to port 53 which is a DNS port at the server side. In the second event which shows what goes on at the web server, click on the outbound PDU and notice how the DNS query now has an IP address field in it. This information is now sent to the client and it tells the client that hostname: www.osi.local resides at IP address 192.168.1.254.
After this, the client and server need to establish a connection that allows them to communicate. This is done using a three-way handshake using TCP. This is what is being performed in the 1st three TCP events in the event list, the 4th TCP event that comes after the 1st HTTP event establishes the connection on the server side thus allowing data to be sent according to the parameters set during the three-way handshake. The three-way handshake is a model where the client sends a TCP SYN request. The server then responds with a SYN-ACK segment after which the client responds back with a TCP ACK segment confirming that both parties have accepted parameters of communication. These parameters include the window size and maximum segment size for the data.
Once the HTTP response has been received by the client, the client attempts to close the connection. This is also a 3-step process where the client sends a FIN+ACK segment to the server on port 80. The server receives this request and responds with a TCP FIN+ACK segment while setting the connection status to CLOSE_WAIT signifying that it is awaiting acknowledgement of this request from the client. The client then sends out a TCP ACK segment which signifies that it has accepted the closure of the
connection and sets its connection status as CLOSING. The server receives this TCP ACK and now sets the connection status to CLOSED. This signifies the closing of the communication channel between the client at 192.168.1.1 port 1026 and server at 192.168.1.254 at port 80. If the client wants to communicate with the server again in the future, a three-way handshake has to be performed to re-establish the connection.
