The purpose of this lab is to familiarize you with some of the low level details of network traffic on an Ethernet LAN. More precisely, you will study the TCP protocol and snoop on some of the TCP/IP (and ARP) packets that transit the Ethernet your workstation is attached to. You will also be confronted with a security pithole that is the result of unprotected network traffic.
Important note! To complete this lab you need to run a special program that will be available only during the scheduled lab time. Hence, no late runners will be accepted!
This lab is designed so that it can (and shall) be completed during the lab session. This, however, means that you have to prepare yourself so that you have some basic knowledge of TCP/IP and the IEEE standard 802.3.
Reading the following sections in Tanenbaum's book should be enough:
In order to monitor the network traffic you need to log in on a workstation and run a command line program called snoop. This program controls the network interface on your host workstation and prints out the headers of certain data packets (or complete packets) going to/from your host according to the options you give. The following options are accepted by the program.
snoop [-aenptvx] [-c count] -s host
-a Snoop on ARP packets.
-e Print the link-level header on each dump line.
-n Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
-p Snoop on packets to/from TCP port 7777.
-t Snoop on TCP/IP packets generated by a Telnet session.
-v (Slightly more) verbose output. For example the time to live and type of service information in an IP packet is printed.
-x Print each packet (minus its link level header) in hexadecimal notation.
-c Exit after receiving count packets.
-s Snoop on packets from the host host.
The options -a, -p and -t are mutually exclusive, i.e. only one of them can be used at a time.
OUTPUT (read this section carefully)
If the -e option is given, the link level header is printed out. More specifically, the source and destination addresses, protocol, and packet length are printed.
Arp output shows the type of request and its arguments. The format is intended to be self explanatory.
The general format of a TCP protocol line is: src > dst: flags data-seqno ack window urgent options. Src and dst are the source and destination IP addresses and ports. Flags are some combination of S (SYN), F (FIN), P (PUSH) or R (RST) or a single `.' (no flags). Data-seqno describes the portion of sequence space covered by the data in this packet (the notation is 'first:last(nbytes of user data)'). Ack is sequence number of the next data expected the other direction on this connection. Only the first sequence number in each direction is specified as an absolute number. The sequence numbers for the remaining packets in each direction are specified relative to the first sequence numbers. Window is the number of bytes of receive buffer space available the other direction on this connection. Urg indicates there is `urgent' data in the packet. Options are tcp options enclosed in angle brackets (e.g., <mss 1024>). Src, dst and flags are always present. The other fields depend on the contents of the packet's tcp protocol header and are output only if appropriate. A packet with the IP don't fragment flag is marked with a trailing '(DF)'.
All output lines are preceeded by a timestamp. The timestamp is the
current clock time in the form
hh:mm:ss.frac and is as accurate as the kernel's clock. The timestamp reflects the time the kernel first saw the packet.
When the -x option is given the packet content will be dumped in hexadecimal notation. The content is formated in 16-bit segments, e.g. the hex dump '020a 0802' is four bytes long (with decimal values 2, 10, 8 and 2 respectively).
This will print the contents of all arp packets:
This will print the two first TCP packets on the Telnet port from Veda.DoCS.UU.SE. The printout will include link-level information and addresses will not be converted into names:
/stud/docs/kurs/datakom/snplab/snoop -et -c 2 -s Veda.DoCS.UU.SE
Question 1: What is the host name of your machine, i.e. which machine do you intend to run snoop on?
In this small exercise you are supposed to capture one TCP/IP packet, preferably the first one, from a Telnet session and study its contents.
To accomplish this you need to start snoop with the right options and then remote login on one of the machines in room 1411 - 1412 and, finally, Telnet back to your host (if you have two machines to work with, you can just Telnet directly from one to the other). Make sure that the printout contains the full contents of the packet (use the -x option) so that you can identify the different parts.
Copy the output from snoop into a text file (the hex portion is the important part, you can skip the rest) so that you can answer the questions below later. Figures 5-45 and 6-24 in Tanenbaum's book will probably be helpful when you are trying to answer the questions.
Question 2: Which comes first in the hex dump of the packet contents that snoop produced, the IP header or the TCP header?
Question 3: At which bytes do the headers end? (You can just mark it in your hex dump.)
Question 4: Where can the protocol identifier be found in the IP header and what decimal value does it have in your hex dump?(If you can't manage to find it, you can cheat by looking in IETF's RFC 1700 where the value is listed along with the values for all the other recognized protocols.)
Question 5: Where can the source and destination addresses be found and what values (in the three dot notation, e.g. 126.96.36.199) do they have in your hex dump?
Question 6: What port number (in decimal notation, please) does the Telnet service have, and where do you find it in your dump?
Question 7: TCP provides a byte-stream based service where record boundaries are not maintained between the sender and receiver. How can applications circumvent this so that the records can be restored from the data in the received packets?
You will now study the handshaking which takes place during the setup and release of a TCP connection. Again we use the Telnet service to initiate the connection.
Start by shutting down your previous Telnet session and exit snoop (if it has not done so by itself. If you were wise enough to use the -c 1 option in the previous exercise it should have exited automatically). Start snoop again, but this time without the -x option and then Telnet back to your host. Type Ctrl-D at the login prompt to shut down the Telnet session.
You should now have a printout of the twenty or so packets that were sent by the two hosts in the short Telnet session.
Question(s) 8: Which packets constitute the TCP setup phase? How does the recipient recognize a TCP packet as a connection setup request packet, i.e. what is the recipient's reply in your Telnet session?
Question(s) 9: The sequence numbers are, as you can see from your dump, strictly increasing. Furthermore, if you study the TCP header you find that sequence numbers are represented using 32 bits. Can you think of a potential problem with this? How would you solve it? (Hint: consider a very high bandwidth network and a fast and eager sender.)
Question(s) 10: On some of the packets you can see the letter P, what does it mean? Why are packets usually marked with a 'P' in an interactive session? Is it effective?
Question(s) 11: Some lines may contain the following '. ack seq-nr', what does it mean? By inspecting your printout, how does TCP usually try to send acknowledgements?
Question 12: Refer to figure 6-28 in Tanenbaum's book. Draw your own TCP connection management finite state machine (FSM) for the printout you received. Consequently, you can ignore all the non-setup and non-release packets. You should draw one FSM for the client and one for the server. Include the snoop printout and indicate which lines in the printout correspond to the transitions in your FSMs.
The flow control in TCP is based on a sliding window protocol, which allows the sender to transmit multiple packets before it stops and waits for an acknowledgement. This leads to faster data transfer, since the sender does not have to stop and wait for an acknowledgement after each time a packet is sent.
The sliding window protocol can be visualized as in figure 1.
Figure 1: Visualization of TCP sliding window.
In the figure the bytes are numbered 1 through 11. The window advertised by the receiver is called the offered window and covers bytes 4 through 9, meaning that the receiver has acknowledged all bytes up through and including number 3, and advertised a window size of 6 (i.e. the window size is relative to the acknowledged sequence number). The sender computes its usable window, which is how much data it can send immediately. As data is sent and acknowledged the window moves to the right and the relative motion of the two ends of the window increases or decreases the size of the window.
You should now illustrate how the sliding window for the sender moves in a small one-way transfer of 8192 bytes. You will use a small utility program called sock that can be used as both a client and a server process. Start snoop with the -p option (but preferably without the -x option) and then start the sock program as the server on the host that you remote logged in on by giving the following options:
/stud/docs/kurs/datakom/snplab/sock -i -s 7777
The -i and -s flags tell the program to run as a "sink" server (read from the network and discard the data), and the server's port number is specified as 7777. Finally, start the corresponding client on your host:
/stud/docs/kurs/datakom/snplab/sock -i -n8 hostname 7777
where hostname should be replace with the name of host that you have remote logged in on. This causes sock to perform eight 1024-byte writes to the specified network host on TCP port 7777.
Question 13: Use the output from snoop and draw a figure (analogous to figure 1) showing how the sliding window for the server moves. Indicate which segment (packet) in the snoop output each arrow and box in your figure refers to.
Question(s) 14: The window in question 13 reflects the instantaneous capacity of the receiver. How is the instantaneous capacity of the network represented in TCP? If the network gets congested and packets are dropped, how does TCP react (with respect to its representation of the instantaneous network capacity)?
Question(s) 15: Suppose that loss of packets is not due to congestion (e.g. an overloaded router), but instead due to a highly unreliable medium. How would TCP react to this? For efficiency reasons, how should it react?
Of course, TCP/IP packets are not the only ones that are sent on the Ethernet your host is attached to. Another type is the Address Resolution Protocol (ARP) packet. Any packet sent to your host is actually addressed to a hardware address that is globally unique to the Ethernet interface of your host. This is the MAC-address. If the sender do not know the MAC-address of your host's Ethernet interface, it must broadcast an ARP-packet to get the address before it can send any other packets to you.
The ARP protocol is described in IETF's RFC 826. The following is a small (and slightly edited) excerpt from that RFC.
To communicate mappings from <protocol, address> pairs to 48-bit Ethernet addresses, a packet format that embodies the Address Resolution protocol is needed. The format of the packet follows.
Ethernet packet data:
16.bit: Hardware address space (e.g., 1 for Ethernet)
16.bit: Protocol address space. For Ethernet hardware, this is from the set of type fields ether_typ$<protocol>.
8.bit: byte length of each hardware address
8.bit: byte length of each protocol address
16.bit: opcode (1 for REQUEST, 2 for REPLY)
nbytes: Hardware address of sender of this packet.
mbytes: Protocol address of sender of this packet.
nbytes: Hardware address of target of this packet (if known).
mbytes: Protocol address of target."
Let's snoop on some APR-packet traffic. Start snoop with the options, -nax. Hopefully, you will eventually catch a request and corresponding reply. If you do not succeed to get a request-reply sequence within a few minutes you can abort and simply use one of the (many) request packets.
Copy the output from snoop into a text file (the contents of the request packet is enough).
Question 16: What is the MAC-address of the host who made the ARP-request?
While you are at it, figure out a way to find the MAC-address for the Ethernet interface of your host using snoop.
Question(s) 17: Which address did
you obtain and how did you do it? Did your idea work? Reason?
(If your idea failed you can always fall back on the -e option for snoop.)
Now, try the following, start snoop with just the -a option. Study the printout for a while then exit snoop with Ctrl-C.
Question 18: Why is the ARP traffic quite moderate even though the network traffic probably is quite busy?
Those of you who have a malicious mind may have already figured out that snoop can be used for other, less noble, purposes. For instance, recall the Telnet session examined earlier. If you had completed the login and typed your username along with your password while, at the same time, someone else were snooping your network traffic, you would have been in trouble. Your username and password would have been out in the open. Snatching your partner's password is exactly what you will do in this exercise.
Note! We do remind you that this kind of behaviour is highly unethical under normal circumstances. Consider this exercise an illustration of how hazardous unencrypted network traffic can be in the hands of people with harmful intent.
Before you start, the person (you or your lab-partner), whose password is to be cracked, should change password to a tempory one (or, alternatively, change into a new password after this lab). Then, snoop on the packets during the telnet login procedure so that you can figure out the password.
The details? You figure it out (it is not difficult).
The report for this lab shall consist of the answers to the exercise questions and the outputs generated by snoop, which your answers are based on. A printout of the packets (including their contents) that were needed to get the password in the final exercise shall also be included along with a short description of how you went along to get the password (simply asking your partner is a no-no solution).