Task 1 - Observing TCP's 3-way handshake
In this exercise you will watch TCP setting up a connection, observing how it uses sequence numbers and three-way handshakes to achieve reliability. In order to create some TCP traffic, you will be using FTP, which uses TCP to deliver data.
2. Start a capture.
3. From a DOS box use the FTP (File Transfer Protocol) program to start an FTP session with an FTP server.
- Within the FTP window type "open (((FTPServer)))".
- If the server address has been given as a DNS name rather than a numeric IP address you will need to find out the IP address - use "ping -a <hostname>" and note down the IP address of the host. ("-a" forces ping to display this information)
- Connect using (((FTPCredentials)))
4. Once you have logged in, halt the capturing process and observe the packets held in the capture buffer. (You may close the FTP application, if you wish, by typing "bye").
5. Look first at the "Layer" column in the packet list. This tells you what the main purpose of each packet is - in earlier labs you might have seen "ARP" in this column. Today, if you have filtered correctly, you should see a mixture of "TCP" and "FTP".
6. Today we will be trying examine the "TCP" packets but to start off with select an "FTP" packet ( capture again if you do not have one )
2. Expand the IP header ( click on the sign ) and inspect the IP addresses. Click on them and notice how they are highlit in the raw data of the packet. In the decode window they have been translated into decimal - for human consumption, whereas in the raw data window you see the actual 4 bytes - represented in hexadecimal. Try the translation yourself - use the Windows Calculator Start/Programs/Accessories/Calculator selecting View/Scientific to give "Mode" buttons for hexadecimal and decimal.
2. Expand the field within the TCP header named "Code"
3. How big ( how many bits ) is the Code field
4. To answer this you may like to look at the raw data and remember that every hexadecimal "digit" ( eg '1', 'A', '9' ) represents 4 bits.
5. Each bit has a special significance in terms of managing the connection between your PC and the host that you are connected to.
- PSH means that that there is some data in the packet. If you are looking at an "FTP" packet then PSH should be set because data is being transferred.
- ACK is an acknowledgment and is used throughout the conversation to acknowledge the previous packet. Often ACK and PSH will both be set meaning that we are sending some new data at the same time as sending an acknowledgment. Find a packet with ACK and PSH set ( recapture if necessary )
- SYN and FIN are to do with setting up and ending connections and this will be the main focus in the rest of the lab. Have you captured any packets with SYN set
6. Notice the two large number fields ( Sequence Number and Acknowledgment Number ). Click on either of these fields and note how many bytes are being used in the raw data section.
A Data Pattern filter can accept ( or reject ) packets that have a certain piece of data at a certain position in the packet. The assumption is that you have some idea of what it is that you want to accept or reject. Take the following steps:
1. Make sure that you still have a buffer with some of the packets from the earlier exercises and that the window is displayed. If not re-capture.
2. From the Filter Settings windows select the Data Pattern tab
3. Click on the Add Pattern button. If you have the data available ( first step above ) you should see a new decode window open up within the Edit Pattern screen. If this is not the case go back to step 1. You can move back and forth between your packets using the Next and Previous buttons.
4. Find a packet that has a TCP header ( shrink the other headers ) and locate the Code section of the TCP header ( it is displayed already expanded - RES, URG, ACK etc )
5. Click on one of these lines and then on the Set Data button. Notice what happens in the top of the screen. The precise position of the Code byte has been calculated ( Offset = 47 ), the length ( Len = 1 byte ) and the value inserted into the mini-spreadsheet. What value do you see
The value you see will be the value of the Code byte in the packet you are currently viewing so it is not yet the value that you want to go looking for.
6. The packets that we want to grab are ACK, FIN packets ( ie they have those two bits set ) Looking at the packet decode you should be able to see that this would be 00010001 in binary. What would that be in hex
7. Enter this hexadecimal value in the first cell of the mini-spreadsheet ( instead of the value that is there). Packets with this value, at that position, are the ones you want to capture!
8. Say "OK" to Edit Pattern and before leaving the Filter Setting window check that you still have the Advance Filter set for FTP ( there may be some non-TCP packets out there that have the same piece of data, in the same position, as the Data Pattern filter is looking in )
9. Start the capture.
10. Capture an FTP session - this time there should be no packets captured until you say "bye"
11. Inspect your packets - there should be two. The significance of ACK, FIN is that each end of the connection is winding up its sequence number series.
Task 3 - Sorting out sequence numbers
In this exercise you will examine the way that TCP calculates the acknowledgement number that it sends in response to a specific sequence number. The intention is that this acknowlegment number has the effect of confirming the reception of each byte that was sent. This is achieved by adding the number of bytes received to the sequence number in the packet and using that number as the acknowledgement number. The sender knew the sequence number and the number of bytes that was sent so this acknowldegment confirms that everything got there OK!
When you captured 5 packets at the beginning of an FTP session the first three were the 3-way handshake, as described, but the last two consisted of the server sending a login message which was acknowledged by your workstation. Confirm this by looking at the source and destination IP addresses for the last two packets and also at the TCP flags that were set in them.
If you do not have what seem like the right five packets repeat the capture as described above.