您在這裡

Exercises

13 一月, 2015 - 13:02
: media/image131.png
Figure 4.67 
Wireshark : sequence number graph  

A second interesting graph is the round-trip-time graph that shows the evolution of the round-trip-time in function of time. This graph can be used to check whether the round-trip-time remains stable or not. Note that from a packet trace, wireshark can plot two round-trip-time graphs, One for the flow from the client to the server and the other one. wireshark will plot the round-trip-time graph that corresponds to the selected packet in the top wireshark window.

:media/image132.png
Figure 4.68 
Wireshark : round-trip-time graph  

Emulating a network with netkit

Netkit is network emulator based on User Mode Linux. It allows to easily set up an emulated network of Linux machines, that can act as end-host or routers.

Note: Where can I find Netkit?

Netkit is available at http://www.netkit.org. Files can be downloaded from http://wiki.netkit.org/index.php/Download_Official, and instructions for the installations are available here : http://wiki.netkit.org/download/netkit/INSTALL .

There are two ways to use Netkit : The manual way, and by using pre-configured labs. In the first case, you boot and control each machine individually, using the commands starting with a “v” (for virtual machine). In the second case, you can start a whole network in a single operation. The commands for controlling the lab start with a “l”. The man pages of those commands is available from http://wiki.netkit.org/man/man7/netkit.7.html

You must be careful not to forgot to stop your virtual machines and labs, using either vhalt or lhalt.

A netkit lab is simply a directory containing at least a configuration file called lab.conf, and one directory for each virtual machine. In the case the lab available on iCampus, the network is composed of two pcs, pc1 and pc2, both of them being connected to a router r1. The lab.conf file contains the following lines :

pc1[0]=A pc2[0]=B r1[0]=A r1[1]=B 

This means that pc1 and r1 are connected to a “virtual LAN” named A via their interface eth0, while pc2 and r1 are connected to the “virtual LAN” B via respectively their interfaces eth0 and eth1.

The directory of each device is initially empty, but will be used by Netkit to store their filesystem.

The lab directory can contain optional files. In the lab provided to you, the “pc1.startup” file contains the shell instructions to be executed on startup of the virtual machine. In this specific case, the script configures the interface eth0 to allow traffic exchanges between pc1 and r1, as well as the routing table entry to join pc2.

Starting a lab consists thus simply in unpacking the provided archive, going into the lab directory and typing lstart to start the network.

Note: File sharing between virtual machines and host

Virtual machines can access to the directory of the lab they belong to. This repertory is mounted in their filesystem at the path /hostlab.

In the netkit lab (exercises/netkit/netkit_lab_2hosts_1rtr_ipv4.tar.tar.gz, you can find a simple python client/server application that establishes TCP connections. Feel free to re-use this code to perform your analysis.

Note: netkit tools

As the virtual machines run Linux, standard networking tools such as hping, tcpdump, netstat etc. are available as usual.

Note that capturing network traces can be facilitated by using the uml_dump extension available at http://kartoch.msi.unilim.fr/blog/?p=19 . This extension is already installed in the Netkit installation on the student lab. In order to capture the traffic exchanged on a given ‘virtual LAN’, you simply need to issue the command vdump <LAN name> on the host. If you want to pipe the trace to wireshark, you can use vdump A | wireshark -i -k

  1. A TCP/IP stack receives a SYN segment with the sequence number set to 1234. What will be the value of the acknowledgement number in the returned SYN+ACK segment ?
  2. Is it possible for a TCP/IP stack to return a SYN+ACK segment with the acknowledgement number set to 0 ? If no, explain why. If yes, what was the content of the received SYN segment.
  3. Open the tcpdump packet trace exercises/traces/trace.5connections_opening_closing.pcap and identify the number of different TCP connections that are established and closed. For each connection, explain by which mechanism they are closed. Analyse the initial sequence numbers that are used in the SYN and SYN+ACK segments. How do these initial sequence numbers evolve ? Are they increased every 4 microseconds ?
  4. The tcpdump packet trace exercises/traces/trace.5connections.pcap contains several connection attempts. Can you explain what is happening with these connection attempts ?
  5. The tcpdump packet trace exercises/traces/trace.ipv6.google.com.pcap was collected from a popular website that is accessible by using IPv6. Explain the TCP options that are supported by the client and the server.
  6. Thetcpdumppacket trace exercises/traces/trace.sirius.info.ucl.ac.be.pcap Was collected on the departmental server. What are the TCP options supported by this server ?
  7. A TCP implementation maintains a Transmission Control Block (TCB) for each TCP connection. This TCB is a data structure that contains the complete “state” of each TCP connection. The TCB is described in RFC
  8. 793. It contains first the identification of the TCP connection :
    1. localip : the IP address of the local host
    2. remoteip : the IP address of the remote host
    3. remoteport : the TCP port used for this connection on the remote host
    4. localport : the TCP port used for this connection on the local host. Note that when a client opens a TCP connection, the local port will often be chosen in the ephemeral port range ( 49152 <= localport <= 65535 ).
    5. sndnxt : the sequence number of the next byte in the byte stream (the first byte of a new data segment that you send will use this sequence number)
    6. snduna : the earliest sequence number that has been sent but has not yet been acknowledged
    7. rcvnxt : the sequence number of the next byte that your implementation expects to receive from the remote host. For this exercise, you do not need to maintain a receive buffer and your implementation can discard the out-of-sequence segments that it receives
    8. sndwnd : the current sending window
    9. rcvwnd : the current window advertised by the receiver
  9. Using the exercises/traces/trace.sirius.info.ucl.ac.be.pcap packet trace, what is the TCB of the connection on host 130.104.78.8 when it sends the third segment of the trace ?
  10. The tcpdump packet trace exercises/traces/trace.maps.google.com was collected by con taining a popular web site that provides mapping information. How many TCP connections were used to retrieve the information from this server ?
  11. Some network monitoring tools such as ntop collect all the TCP segments sent and received by a host or a group of hosts and provide interesting statistics such as the number of TCP connections, the number of bytes exchanged over each TCP connection, ... Assuming that you can capture all the TCP segments sent by a host, propose the pseudo-code of an application that would list all the TCP connections established and accepted by this host and the number of bytes exchanged over each connection. Do you need to count the number of bytes contained inside each segment to report the number of bytes exchanged over each TCP connection ?
  12. There are two types of firewalls 30 : special devices that are placed at the border of campus or enterprise networks and software that runs on endhosts. Software firewalls typically analyse all the packets that are received by a host and decide based on the packet’s header and contents whether it can be processed by the host’s network stack or must be discarded. System administrators often configure firewalls on laptop or student machines to prevent students from installing servers on their machines. How would you design a simple firewall that blocks all incoming TCP connections but still allows the host to establish TCP connections to any remote server ?
  13. Using the netkit lab explained above, perform some tests by using hping3(8). hping3(8) is a com mand line tool that allows anyone (having system administrator privileges) to send special IP packets and TCP segments. hping3(8) can be used to verify the configuration of firewalls 33 or diagnose problems. We will use it to test the operation of the Linux TCP stack running inside netkit.
    1. On the server host, launch tcpdump(1) with -vv as parameter to collect all packets received from the client and display them. Using hping3(8) on the client host, send a valid SYN segment to one unused port on the server host (e.g. 12345). What are the contents of the segment returned by the server ?
    2. Perform the same experiment, but now send a SYN segment towards port 7. This port is the default port for the discard service (see services(5)) launched by xinetd(8)). What segment does the server sends in reply ? What happens upon reception of this segment ? Explain your answer.
  14. The Linux TCP/IP stack can be easily configured by using sysctl(8) to change kernel configuration variables. See http://fasterdata.es.net/TCP-tuning/ip-sysctl-2.6.txt for a recent list of the sysctl variables on the Linux TCP/IP stack. Try to disable the selective acknowledgements and the RFC1323 timestamp and large window options and open a TCP connection on port 7 on the server by using :manpage:telnet‘(1)‘. Check by using tcpdump(1) the effect of these kernel variables on the segments sent by the Linux stack in netkit.
  15. Network administrators sometimes need to verify which networking daemons are active on a server. When logged on the server, several tools can be used to verify this. A first solution is to use the netstat(8) command. This command allows you to extract various statistics from the networking stack on the Linux kernel. For TCP, netstat can list all the active TCP connections with the state of their FSM. netstat supports the following options that could be useful during this exercises :
    1. -t requests information about the TCP connections
    2. -n requests numeric output (by default, netstat sends DNS queries to resolve IP addresses in hosts and uses /etc/services to convert port number in service names, -n is recommended on netkit machines)
    3. -e provides more information about the state of the TCP connections
    4. -o provides information about the timers
    5. -a provides information about all TCP connections, not only those in the Established state

On the netkit lab, launch a daemon and start a TCP connection by using telnet(1) and use netstat(8) to verify the state of these connections.

A second solution to determine which network daemons are running on a server is to use a tool like nmap(1). nmap(1) can be run remotely and thus can provide information about a host on which the system administrator cannot login. Use tcpdump(1) to collect the segments sent by nmap(1) running on the client and explain how nmap(1) operates.

  1. Long lived TCP connections are susceptible to the so-called RST attacks. Try to find additional information about this attack and explain how a TCP stack could mitigate such attacks.
  2. For the exercises below, we have performed measurements in an emulated 31 network similar to the one shown below.
: media/image133.png
Figure 4.69 
Emulated network  
  1. The emulated network is composed of three UML machines: a client, a server and a router. The client and the server are connected via the router. The client sends data to the server. The link between the router and the client is controlled by using the netem Linux kernel module. This module allows us to insert additional delays, reduce the link bandwidth and insert random packet losses.
  2. We used netem to collect several traces :
    1. exercises/traces/trace0.pcap
    2. exercises/traces/trace1.pcap
    3. exercises/traces/trace2.pcap
    4. exercises/traces/trace3.pcap
  3. Using wireshark or tcpdump, carry out the following analyses :
    1. Identify the TCP options that have been used on the TCP connection
    2. Try to find explanations for the evolution of the round-trip-time on each of these TCP connections. For this, you can use the round-trip-time graph of wireshark, but be careful with their estimation as some versions of wireshark are buggy
    3. Verify whether the TCP implementation used implemented delayed acknowledgements
    4. Inside each packet trace, find :
      1. one segment that has been retransmitted by using fast retransmit. Explain this retransmission in details.
      2. one segment that has been retransmitted thanks to the expiration of TCP’s retransmission timeout. Explain why this segment could not have been retransmitted by using fast retransmit.
      3. wireshark contains several two useful graphs : the round-trip-time graph and the time sequence graph. Explain how you would compute the same graph from such a trace .
      4. When displaying TCP segments, recent versions of wireshark contain expert analysis heuristics that indicate whether the segment has been retransmitted, whether it is a duplicate ack or whether the retransmission timeout has expired. Explain how you would implement the same heuristics as wireshark.
      5. Can you find which file has been exchanged during the transfer ?
  4. You have been hired as an networking expert by a company. In this company, users of a networked application complain that the network is very slow. The developers of the application argue that any delays are caused by packet losses and a buggy network. The network administrator argues that the network works perfectly and that the delays perceived by the users are caused by the applications or the servers where the application is running. To resolve the case and determine whether the problem is due to the network or the server on which the application is running. The network administrator has collected a representative packet trace that you can download from exercises/traces/trace9.pcap. By looking at the trace, can you resolve this case and indicate whether the network or the application is the culprit ?