CS 725/825 Computer Networks, IT 725 Network Technology

Assignment 4

---

Due: Wednesday, November 20, 2024, 2:10 pm (start of the class)

Problems:

1. (10 points) This question focuses on the concept of Autonomous System (AS) and Autonomous System Number (ASN). Find a tool (an online one is fine, it does not have to be a command line utility) that allows you to retrieve AS information and answer the following questions:
1. What is the ASN of the University of Maine System (maine.edu)?
2. List the IPv4 and IPv6 prefixes that are included in the University of Maine System's AS.
3. Which ASs is the University of Maine System AS connected to?
4. Does University of Maine System serve as a transit AS for some other AS?
2. (10 points) Run traceroute from a computer on the UNH network (e.g., agate) to www.maine.edu. List the ASs and their ASNs encountered along the way. (traceroute will not be able to get all the way to the node that serves www.maine.com but you will get close enough to answer the question)
3. (20 points) Consider the trace https://www.cloudshark.org/captures/1ba313f24b41 that captures an HTTPS session, and answer the questions below. The trace captures encrypted traffic, so normally you would not be able to see the application layer payload. The HTTPS request captured in the trace was made by command line utility curl with the environment variable SSLKEYLOGFILE set to make curl output the session key to a file. As a side note, many browsers and networking libraries can be made to output session keys for network traffic debugging purposes. If you are curious, see this article for more details (the method that they describe works for most standard application, including curl). The session key was then uploaded to CloudShark together with the trace to enable payload decryption. If you are curious how the same trace looks without access to the key, check https://www.cloudshark.org/captures/1fd27530326b.
1. What is the version of TLS used in the HTTPS transaction captured in the trace?
2. How many packets does it take to establish the TLS session (i.e., past 3-way handshake all the way to the packet that carries the HTTP HEAD request)?
3. Draw and annotate a ladder diagram showing the packets used to establish the TLS session.
4. Which packets contain the server certificate(s)?
5. Does the server support HTTP/3? How is that indicated?
6. In which packet does the client notify the server that the TLS connection is being closed?
4. (10 points) The UNH Cybersecurity Training Module (see two screenshots below) makes the following dangerously wrong claims regarding sites served using HTTPS:





Outline answers to the following questions:

1. What protection does HTTPS actually provide?
2. Why is a site served using HTTPS not guaranteed to be "secure" or "legit"?
3. What additional steps do you have to make to ascertain legitimacy of a site served using HTTPS?
4. Outline how one would set up a malicious site that would be considered "secure" or "legit" based on the UNH Cybersecurity Training?

Programming assignment:

5. (50 points) The goal of this assignment is to study the latency overhead introduced by various protocols. The assignment focusses on a simple request/response transaction implemented using various protocols and, specifically, on the question of how many network round-trip times (RTTs) does it take to complete such a transaction. While other components contribute to the overall transaction latency, RTT tends to dominate, and it is typically out of our control. This question can be answered by analyzing the protocols in question, however, in this assignment you are expected to study it experimentally. You will implement a system consisting of a client making a simple request to a server, the server responds with some arbitrary data, the client receives it, and measures, as precisely as possible, the time the entire transaction took, i.e., including, if applicable, the time it took to establish and close the connection.

Experiment with five protocols: ICMP, UDP, TCP, TLS, HTTP, and HTTPS. Both request and response should be no more than a few tens of bytes in length, not including the protocol overhead. For all protocols except for ICMP (use ping for that), you need to write both client and server side. It is fine to use libraries for TLS/HTTP/HTTPS. For the HTTP/HTTPS server you may want to consider using node.js or Flask but other libraries are perfectly fine. TLS and HTTPS experiments require that you generate your own self-signed (not backed by a recognized CA) certificate (see Question 5 in the previous assignment). Most HTTPS client libraries will require extra steps to confirm that it is fine to accept a self-signed certificate. Ignore internet posts that state that accepting self-signed certificates in your program is wrong. They are correct with respect to production code, however, here we are dealing with experiments in a closed environment.

To run your experiment, use rb1.cs.unh.edu and rb2.cs.unh.edu. Besides connectivity to the department network, the servers are connected via five links that carry no other traffic than the one produced by the experiments. Each of the links is configured so that traffic experiences different link delays. The extra delays added to the inherent delay of a directly connected link are set as follows:

Interface	Added round-trip delay (ms)
enp2s0f0	5
enp2s0f1	20
enp2s0f2	80

The links are configured with private IP addresses, make sure that you send your test traffic over them and not over the public interfaces rb1.cs.unh.edu and rb2.cs.unh.edu. Standard development tools are installed there. Accounts are being set up for all students in the course with the same username as you have on Agate but with a different password. Your username and password has been stored in your home directory on Agate in file cs725.info, cs825.info, or it725.info, depending on the course you are registered for. The servers do not mount your Agate filesystem. The best way to keep your code in sync between your development environment and both machines is to use git and create multiple clones of your repository.



How exactly you set up the experiments is up to you. You do not have to run the experiment on all links but the choices that you make should not be arbitrary. Your submission should include a brief justification of the experiment design decisions. Each of the experiments must be repeated a sufficient number of times so that the collected results are statistically significant.

Deliverables

1. Include a brief outline of the approach that you took and a sample run in your assignment submission. You must show representative runs of your programs together with appropriate explanations. Important: by showing an execution of your program, you are making a statement that your program, as submitted, works as shown. An attempt to "fake" a run, for example by writing a program that ignores input and just prints answers regardless of input, will be considered as cheating. You may be asked to give a demo of your program. If your program does not implement fully the required functionality or does not work, you have to make it clear in the report.
2. Commit the source code to your course Git repository (see instructions). Add brief instructions on how to compile/run the code to the assignment's README.md. Do not commit data, graphs, documents, etc. into the repository. Don't forget to tag the commit as a4.

Submission instructions:

Upload your submission as a single PDF file using myCourses (mycourses.unh.edu). Any source code used in the assignment must be committed to the course Git repository. More details can be found in the standard assignment submission instructions.