Home > Experiential Learning > Experiential Learning of Networking Technologies: Understanding TCP States – Part 1

Experiential Learning of Networking Technologies: Understanding TCP States – Part 1

Experiential Exercises

 
All the example exercises [13] discussed in this article make use of Linux built in commands related to network utility nc for data transfer and netstat for monitoring network connection state. No specific programs are required for these exercises. At times depending upon your Linux installation, the utility netstat may not be installed. In that case, install this utility by using the command sudo apt-get install net-tools. The netcat (nc) is available on all Linux and Apple Mac machines, (there are free open source versions available for Windows machines as well). All the steps in these exercises are defined for Ubuntu installation 16.04 LTS but would work on other versions of Ubuntu as well and other variants of Linux as well. All the exercise steps described consider that two machines, namely, Ciient (C_m) and Server (S_m) are connected via a network. An example of this connectivity is shown in Figure 3.

Exercise 1
Topic: Basic TCP states in a general successful communication

 
a. On S_m, run nc command in server mode to listen on a port. To listen on TCP port number 5555, run the command
nc –l 5555
b. On S_m, run netstat command to check the TCP connection state of this server. The
netstat –nat | grep 5555
It should show the state of this TCP socket as LISTEN. Since we have not specified any IP address for the server, by default it will consider all the IP addresses available (displayed as 0.0.0.0) on that machine and will show the Local Address as 0.0.0.0.5555. Since no client has connected to this server, thus it will show client side address (listed under the column name Foreign Address) as *.*.
c. On C_m, use a client program to connect to our server application. For this you should know the IP address of the server S_m (It can be found by using the command ip addr show on the server). Assuming the server IP address is 10.11.255.10, run the command on C_m
nc 10.211.55.10 5555
d. When network is working fine, the client will connect to server. On both server and client, the connection will show the state ESTABLISHED. Use the following command to check status of TCP connection on both client and server. On client, it will show the server’s IP address as foreign address, and on server it will show the client’s IP address as Foreign address.
i. netstat –nat | grep 5555
e. After TCP connection is successfully established, whatever is entered on the terminal of client and server, it will be sent to other side and displayed. The connection will continue to remain in ESTABLISHED state indicating the connection setup is completed and connection is in data transfer stage.
f. On client machine, open the browser, and access any of your preferred website e.g. (http://acc.digital). Check the number of TCP connections which are in established state (netstat –nat | grep ESTABLISHED). It will show all the TCP connections for which setup is completed and data transfer can occur. For website acc.digital, it is likely to show both HTTP (port 80) and HTTPS (port 443) connections i.e.94.130.104.144.80 and 94.130.104.144.443as the Foreign Address of TCP connections in ESTABLISHED state.
g. Terminate the client program (enter Ctrl_C on the terminal window where nc client is running). Since it is client initiated close, TCP connection on client will move to TIME_WAIT state, whereas TCP connection will be fully closed on server and will not be listed under the output of netstat command.
h. Wait for about 2 minutes (equal to 2MSL timeout), and then check the status of TCP Connection. This TCP Connection is closed and will not be shown in output of netstat.
i. Rerun the steps of establishing the TCP connection between client and server (steps a to e), but after data transfer has taken place on this connection, terminate the server program rather than the client program. Now since this is server initiated close, the state of TCP connection on server will show in TIME_WAIT state and TCP connection on client is fully closed (will not show in the output of netstat command).

Exercise 2
Topic : TCP Connection state for client and server in incomplete state.

 
a. Create a firewall on client side to drop TCP connection setup packet (i.e. SYN packet) to the server. The rule should use the action Drop rather than Reject (since the latter will inform the sender that packet has been dropped and this might cause state change of TCP connection). Assuming (as before) that server program is listening on port 5555 for new connection, use the following command to invoke a firewall rule.

sudo iptables -I OUTPUT -p tcp --dport 5555 --tcp-flags
SYN,ACK,FIN,RST SYN -j DROP

This command inserts a rule in its firewall chain (-I OUTPUT), which defines that a TCP packets (-p tcp) with destination port number of 5555 (--dport 5555) initiating TCP connection setup (TCP Flag as SYN) should be silently dropped without informing the server (-j DROP).
b. As described in previous exercise (i.e. Exercise 1), run the server program (nc –l 5555) on server machine and run the client program on client machine connecting to server (nc 10.211.55.10 5555)
c. Analyze the TCP connection state on client. The state should show as SYN_SENT. This happens because TCP SYN packet is dropped by firewall which client’s TCP connection is unaware of and is waiting for SYN|ACK from server.
d. Analyze the TCP connection state on server. Since it has not received any SYN packet, it will show the TCP socket state as LISTEN only.
e. Analyze the number of packets dropped by firewall rule. Since TCP will retry sending of SYN packets, multiple TCP SYN packets will be sent by client, though it doubles the timeout wait value each time it receives no response. Thus, depending upon the time duration, nc program was running, count of number of packets dropped will vary. Use the following command to observe the number of packets dropped by firewall
sudo iptables -L OUTPUT –vn

f. Close the client application and remove the firewall rule on client side. To remove (delete) the re-invoke the firewall rule as in step a) above, but with option –D, for example
sudo iptables -D OUTPUT -p tcp --dport 5555 --tcp-flags
SYN,ACK,FIN,RST SYN -j DROP

g. Create a firewall on server side to drop SYN|ACK packets i.e. the server should receive TCP SYN packets, but when server application sends SYN|ACK as response packet, this packet should be dropped. Since the rule is created on server side, the port number 5555 will become source port, and TCP flags to be checked should specify both SYN and ACK. An example command is

sudo iptables -I OUTPUT -p tcp --sport 5555 --tcp-flags
SYN,ACK,FIN,RST SYN,ACK -j DROP

h. Repeat the above step b) to start the server program and client program.
i. Analyze the connection state at both client and server. Since client has not received TCP SYN|ACK response, it will show the connection state as SYN_SENT. Similarly, server program has sent the SYN|ACK response (which is dropped by firewall) and thus has not received ACK (not completed the 3-way handshake), and thus TCP Connection state would be in SYN_RECV. Since TCP server programs are subject to TCP SYN flooding attack [10]., it is possible that this connection is closed in a short time and may not be seen in the output of netstat command. Thus, if you encounter this situation, repeat the experiment few times to witness this state.

References

 
[1] RFC 2616, “Hyper Text Transfer Protocol – HTTP/1.1”, Network Working Group; Fielding, Gettys et al. June 1999, https://tools.ietf.org/html/rfc2616, last accessed Nov 2018
[2] RFC 793, “Transmission Control Protocol “, Information Sciences Institute, USC, CA, Sep 1981, https://tools.ietf.org/html/rfc793. Last accessed Aug 2018.
[3] Ram Rustagi, Viraj Kumar, “Understanding Transport Layer Basics”, ACCS journal of Computing and Communications, Vol 2, Issue 3, Sep 2018. https://acc.digital/experiential-learning-of-networking-technologies-understanding-transport-layer-basics/, last accessed Nov 2018.
[4] Communicating Finite State Machines, Wikipedia; https://en.wikipedia.org/wiki/Communicating_finite-state_machine, accessed Nov 2018.
[5] netstat: man page, http://manpages.ubuntu.com/manpages/bionic/man8/netstat.8.html, Accessed Nov 2018.
[6] netstat usage examples: https://www.tecmint.com/20-netstat-commands-for-linux-network-management/
[7] Netcat (nc) command utility,
http://manpages.ubuntu.com/manpages/xenial/man1/nc.traditional.1.html, last accessed Aug 14, 2018.
[8] nc cheat-sheet, https://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf, last accessed Nov 2018.
[9] Iptables tutorial. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html, last accessed Nov 2018.
[10] https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-34/syn-flooding-attacks.html. Last accessed Nov 2018.
[11] RFC 791, “Internet Protocol”, Information Sciences Institute, USC, CA, Sep 1981, https://tools.ietf.org/html/rfc791, last accessed Nov 2018
[12] Ram Rustagi, Viraj Kumar, “Understanding Network Delays”, ACCS journal of Computing and Communications, Vol 1, Issue 3, Dec 2017; https://acc.digital/experiential-learning-of-networking-technologies-understanding-network-delays/, last accessed Nov 2018.
[13] Example details for TCP Connection state during connection setup, https://github.com/rprustagi/EL-TCP-States.git. Last accessed Nov 2018.

Pages ( 6 of 6 ): « Previous1 ... 45 6

Leave a Comment:

Your email address will not be published. Required fields are marked *