The Complexity of Computer Communications Over a Network can be rather Abstract: Wireshark Assignment, UP, Singapore

Introduction

The complexity of computer communications over a network can be rather abstract if one just studies the different types of protocols that drive the many activities on paper. This GBA aims to give the students opportunities to use a software tool to monitor, capture, and analyze actual data flowing through the transmission media. It gives a glimpse of the many activities taking place behind the scene, among nearby computers, servers, and other network components.

Figure 1 shows the structure of a packet sniffer. At the right of Figure 1 are the protocols (in this case, Internet protocols) and applications (such as a web browser or ftp client) that normally run on your computer. The packet sniffer, shown within the dashed rectangle in Figure 1 is an addition to the usual software on your computer and consists of two parts. The packet capture library receives a copy of every link-layer frame that is sent from or received by your computer. In Figure 1, it is assumed that all higher layer protocols such as HTTP, FTP, TCP, UDP, DNS, or IP all are eventually encapsulated in link-layer frames that are transmitted over physical media such as an Ethernet cable. Capturing all link-layer frames thus gives you all messages sent/received from/by all protocols and applications executing on your computer.

The second component of a packet sniffer is the packet analyzer, which displays the contents of all fields within a protocol message. In order to do so, the packet analyzer must “understand” the structure of all messages exchanged by protocols. For example, suppose we are interested in displaying the various fields in messages exchanged by the HTTP protocol in Figure 1. The packet analyzer understands the format of Ethernet frames, and so can identify the IP datagram within an Ethernet frame. It also understands the IP datagram format, so that it can extract the TCP segment within the IP datagram. Finally, it understands the TCP segment structure, so it can extract the HTTP message contained in the TCP segment. Finally, it understands the HTTP protocol and so, for example, knows that the first bytes of an HTTP message will contain the string “GET,” “POST,” or “HEAD”.

Materials Required

The Wireshark protocol analyzer is a widely used software tool for troubleshooting, analyzing, software development, and education on network operations. The same software is also available in another name called Ethereal. Both have similar standard features expected in any protocol analyzer. The software is distributed with open source licenses and runs on all the popular computing platforms including UNIX, Linux, and Windows.

Report format

The GBA report should present answers in accordance and meeting the requirements as stated in the questions. All answers should be explained with reference to screen capture(s) of the relevant display from the protocol analyzer. No mark will be awarded for presenting the screen captures without highlighting and explaining the relevant details.

Procedure

Run the protocol analyzer on the packet-captured file “capture SUSS_trace588.pcap”. You should see 588 packets captured during a conversion between a browser client and a web server.

Questions:

1. In frame 1, the client initiated a TCP connection with the server.

• Provide screen captures to illustrate the sequence of packet transmission between the client and the server in typical three-way handshake operations for establishing the connection.
• Provide a screen capture of the port number on the connection and appraise which application service the client is expected to receive from the server.

2. In frame 4, the client issued a GET message to retrieve a web page from the server.

• Provide a screen capture of the GET message and highlight the relevant information that identifies the domain name of the server.
• Provide a screen capture of the final data frame. Highlight the relevant packet details and verify the size of the reassembled TCP segment.
• Provide screen captures to demonstrate the flow control information seen at the client and the server. Highlight the relevant packet details and verify that the reassembled TCP segment size of the web page received by the client is indeed the total number of bytes sent over the connection from the server. [Hints: Compare the total bytes received by the client and that sent out by the server is consistent with the reassembled TCP segment of Q2(b)]

3. In frame 23, the client issued another GET message to retrieve a file from the server.

• Provide a screen capture of the GET message and highlight the relevant packet details that form parts of an URL. Construct the URL that was used for locating the file on the server.
• Demonstrate retrieving the file using the constructed URL. Provide a screen capture of the file displayed on the browser.
• Provide a screen capture of the final data frame. Highlight the reassembled TCP segment length of the transmitted file and the content-length in the retrieved file. Explain whether there is any discrepancy between them.

4. The client issued two file requests to the server at frame 122 and at frame 130. Illustrate by drawing the timelines for the two requests and verify whether the files were delivered to the client serially or in parallel. Each timeline should begin with the first data frame and end with the final data frame.

5. The protocol analyzer detected frame 223 is a retransmitted frame.  

• Provide screen captures of the original and retransmitted frames and highlight the packet details to verify that frame 223 is indeed retransmission of the original frame.
• Retransmission is activated once the Retransmission Time Out (RTO) is expired. At the same time, RTO should be at least greater than the Initial Round Trip Time (iRTT) of the connection. Provide a screen capture of the packet list showing the timings for the frames involved in the initial connection set up. Calculate the iRTT for the connection using the time-delays in the 3-way handshake. Verify that RTO for frame 223 indeed exceeded the iRTT. [Hint: RTO for the retransmitted frame can be taken equivalently as its delta-time from the original frame]

6. In frame 483, the client initiated a new connection to a remote server with a destination IP address 157.240.7.35 for the first time.

• Provide a screen capture of the relevant packet details to illustrate how the IP address and the common domain name for the server were discovered. [Hint: A Domain Name Server (DNS) maintains a directory of domain names and corresponding IP addresses]
• Provide screen captures to compare the sequence of frames from 483 to 485 with those from frames 1 to 3. Explain the similarity and differences between the two sequences of frames.

7. In frame 486, the client sent a message to negotiate for a reliable end-to-end secure service with the remote server.

• Provide a screen capture of the frame. Highlight the relevant packet details and verify the following:
  • Content-type of the message
  • Major and minor version numbers of the TLS Record layer
  • Length of the message
  • Handshake type

• Provide a screen capture of the messages advertised by the client. Highlight the relevant packet details and verify the following:
  • Session ID for the secure connection
  • A version of the TLS Handshake for information exchange with the server
  • Generic name and attribute value for a reserved cipher suit.

• Provide a screen capture of the relevant message extension sent out from the client. Highlight the relevant packet bytes and verify the name of the server contacted by the client.

8. In frame 488, the server responded to the client with a message. Provide screen captures of relevant packet details/bytes and verify the following:         

• Name and attribute value for the version of the TLS Handshake selected by the server matching those advertised by the client.
• Session ID for the secure connection established at the server matching that advertised by the client.
• Name and attribute value of the cipher suite selected by the server matching one among the list of suites advertised by the client.
• The content of the message that indicates the server has updated its current cipher spec with those in the selected cipher suite.

9. In frame 501, the server transmitted 324 bytes onto the wire to the client. Construct the Ethernet frame and the encapsulation of various protocol layers, including the encryption of its payload. Illustrate clearly the length of each encapsulation header and the encrypted payload within the frame.

10. In frame 558, the client issued another “Client Hello” message to the same server.

• Explain why a repeat message is necessary when the same message has already been sent earlier in frame 486.
• Further, explain whether the client could use an existing secure connection that has already been established with the server in frame 488.