TCP & UDP

TCP and UDP

TCP (Transition control Protocol) and UDP (User datagram Protocol) is fundamental to understand how data networks work, if you don’t understand how TCP you will not understand how firewalls and data networks work

So there are 2 transport layer protocols the transport layer is responsible for bring up a session so 2 devices can communicate.

TCP is:

Connection orientated
Flow Control
Reliable delivery

Connection orientated – Using the telephone analogy, we pick up the telephone and listen for the dial tone, we dial the number we want to reach; the user at the other will pick up the phone and acknowledge by saying hello. We are done with the establishing connection.

Flow Control:

Using the telephone analogy, when one person is talking, the sound might be distorted and the other person might not understand what it is being said, or perhaps one person is talking to fast, the person who is receiving the conversation, might say “hey can you repeat I didn’t quite catch that your talking to fast, can you repeat”, flow control works the same.

UDP

Connectionless
Lightweight

UDP is lightweight and doesn’t have any overhead, it’s not building any sessions at all at the transport layer, and it’s a mechanism for identifying a session between devices, it identifies the session by the port numbers, so UDP is just a carrier for port numbers. Imagine this analogy, a presenter is reporting the news, you didn’t quite catch what the presenter as he told the football results for your favorite team, we have no mechanism to tell the presenter that I didn’t catch what he said, the presenter has no idea that I did not catch what he said and doesn’t care as he can’t hear me asking if I asked. UDP works in the same way neither device can tell each other what’s going on the receiving device has no mechanism to tell the sender that the  data has been received,  and the sender does not know if the receiver has received the data.

So why is UDP used? Because it’s not going through the process of building a connection UDP is lightweight. So it can send small bits of data very fast.

TCP how it works

The way TCP works to build a session, it uses a 3 way handshake and this 3 way handshake is used for several reset

Its used to build a connection

It’s used to negotiate parameters for the rest of the communication it can manage the connection as efficiently as possible

So using a basic example, a user at his workstation wishes to request a website. He enters in his browser www.google.com the workstation sends a request to the webserver in the form of a TCP SYN

SYN Stands for synchronization

Inside the Segment header port 80 (HTTP) will be assigned as the destination port the sender port will be port 49182.

Port 49182 is an Ephemeral port number

Port 49182 is assigned to the user’s browser to request the website; in the segment there is other information that will determine how to negotiate the rest of the connection.

The webserver is then going to reply with a SYN ACK, inside the segment being sent from the webserver is once again is the ephemeral port 491892.

Once the SYN ACK is sent back to the user’s workstation, the users work station sends a ACK that the data was received.

Once the process has been completed only then can the data can be exchanged.

So now the connection is established the Data can begin to be transferred, the data for the data being processed is called a TCP 4-Way disconnects.

After communication is established with the web server and data is ready to be sent, we tear down the TCP session it can be done in one of several ways but the most graceful way and appropriate method  is the 4 way disconnect.

One of the workstations (server or workstation) will realize the conversation is over and it will send a FIN ACK, and then a ACK will be sent from the PC or server and directly afterward and from the same server or PC a FIN ACK will be sent, then final ACK from the other device. See following screenshot.

Sometimes the 4 way disconnect does not always work and the session will just time out. On the webserver and the workstation will keep track of the sessions that are open and after a certain period of time station and the webserver will just  down the TCP session especially if there is no data being exchanged.

TCP how it works

With UDP often the port numbers change especially if we are sending a lot of segments. In this example we will use a workstation that connects to a TFTP server (Trivial File Transfer Server).  Remember the TFP uses UDP 69. Like we said before UDP is lightweight and has far less overhead the process is smaller as you can see in the following screenshot. In the following screen shot the workstation for example is going to request a  file from the TFTP Server the process is simple:

The workstation initiates the request opening using 49182 on port 69

The TFTP then initiates sending the data using 49182 and send the data to destination port 50157

So basically the workstation requests the data and the TFTP Server responds by sending the data.

The good news is that we rarely use UDP, its really only used with DNS, some SNMP traffic and TFTP.

Sliding windows

Let’s look at how TCP will send a 10 byte file from workstation 1 to workstation 2. In this example we will be sending a 10 byte file via FTP

FTP protocol works at the application layer, so at the transport layer we use TCP for FTP. We can only send a certain amount of data at a time from workstation 1 to workstation 2; this is where we talked about flow control and reliable data delivery this is exactly what sliding windows are. So during the 3 way hand shake we are going to negotiate something called a window size. The window size is the number of bytes of data we can send to the receiving host before the receiving host replies with an acknowledgement that it received the data. Once it has received the data the sending workstation will send more data when it knows the receiving workstation has received it.

So the 10 byte file gets moved to the TCP buffer, the TCP buffer keeps track of what data has been sent and what data has been acknowledged. In the next screenshot the 3 way handshake has completed devices negotiated a window size of 5. Normally window sizes are negotiated to 8192 bytes, but for simplicity we are using 5 in this example to show how it works

So workstation one sends 5 bytes of data, see following screenshot

Once workstation 2 receives those 5 bytes it puts them in its buffer and respond’s to workstation 1 with ACK 6 as you can see in the following screenshot.

Once workstation 1 has received ACK 6 from workstation 2 it proceeds to remove the first 5 bytes from its buffer and then begins to deliver the next 5 bytes

When the next 5 bytes are being sent it could be that the network communication is interrupted, in the next screen shot byte 7 gets lost 

Workstation 1 still has the 5 bytes in the buffer. In this scenario we have 2 options to request the missing data to request the data with a standard acknowledgement or with selective acknowledgement. We cannot use selective acknowledgement unless both devices agree on selective acknowledgement. So if it can’t use selective acknowledgement it is going to use standard, standard acknowledgement is way less efficient than selective acknowledgement.

Standard acknowledgement back to the missing byte 7, workstation 2 needs to acknowledge that byte 6 was received so it sends an ACK 7. See following screen shot

When workstation 1 receives the ACK 7 its going to remove byte 6 and the workstation 1 will send bytes 6 to 10 ( the remaining 4 bytes again to workstation 2 ) see following screenshot.

Workstation 2 then will put the bytes in its buffer and then send an ACK 11 to Workstation 1 which is in turn is now given the signal it can remove bytes 7 8 9 and 10

FTP protocol works at the application layer, so at the transport layer we use TCP for FTP. We can only send a certain amount of data at a time from workstation 1 to workstation 2; this is where we talked about flow control and reliable data delivery this is exactly what sliding windows are. So during the 3 way hand shake we are going to negotiate something called a window size. The window size is the number of bytes of data we can send to the receiving host before the receiving host replies with an acknowledgement that it received the data. Once it has received the data the sending workstation will send more data when it knows the receiving workstation has received it.

So the 10 byte file gets moved to the TCP buffer, the TCP buffer keeps track of what data has been sent and what data has been acknowledged. In the next screenshot the 3 way handshake has completed devices negotiated a window size of 5. Normally window sizes are negotiated to 8192 bytes, but for simplicity we are using 5 in this example to show how it works

How ACK 11 SACK 6-8 is interpreted – SACK 6-8 is saying is saying to workstation 1 “6” is the left edge and “7” is the right edge but we don’t have what’s in the middle, which means it did not receive byte 7. So Workstation 1 will pull out all the bytes but only send byte 7, workstation 2 then can send ACK 11 this will be a duplicate ACK but that’s ok because the selective acknowledgement is switched off now.

Now workstation 2 has the file and can do the FIN-ACK ACK FIN-ACK ACK process and now the entire file transfer process from workstation 1 to workstation 2 is complete This complete process is what is happening after the 3 way hand shake. We negotiate our window size  our window size is used during the window transfer in order to make this happen. Acknowledgements are always sent with the number bytes received.

There is another field called the sequence number which is the number of bytes that have been sent

 

Demonstrating TCP and UDP with netstat

First start a command prompt in windows and run the command netstat ?

You will then see a list of all netstat commands like in the following screenshot ( it’s in German as I work in Germany at the time of writing this Document and I’m using a German operating system) 

We will look at first the –a switch first, netstat –a will show us active connections and listening ports

Next we look at the –n switch this will show us addresses and ports in numerical 

The next switch we will be using is –p proto which will show us connections

So if we do a netstat –n it will show us active connections in numerical format

Once the netstat  -an command has been initiated you will be presented with a long list of active connections in numerical format. In the  next screen shot we can see both IPv4 and IPv6

In the next screen shot let’s look at local address first, in the next screen shot I have highlighted the IP 0.0.0.0; this is the local workstation listening on various ports ie. 135, 445, 49152 through to 49157.

What we can now do is analyze the ports and see what the port is listening for. So open you favorite search engine and type in the search box “port 135” there will be a list presented from google,   you will probably see on the first page from googles search:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Here you can you can view most of the major ports in use. Not all are listed but there is a possibility of 65535. The range 49152–65535 contains dynamic or private ports that cannot be registered with IANA. The ports that cannot be registered with IANA are Dynamic, private or ephemeral ports

Port 135, what it is used for:

So as you can see from the 135 is being used by Microsoft EPMapper, the EPMapper is what is used to locate other PCs Devices on the network. So when you see other PCs on the network this is how they are located. You can see everything from tablets to PCs to Storage devices.

Ephemeral port – basically a temporary port

An ephemeral port is a short-lived transport protocol port for Internet Protocol (IP) communications allocated automatically from a predefined range by the IP software. It is used by the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or the Stream Control Transmission Protocol (SCTP) as the port assignment for the client end of a client–server communication to a well known port on a server.

Private Ports

For example if you wish to setup a FTP server the FTP server listens typically on port 21. In the people would typically set a FTP server on 21 and make it available to the internet. This of course would be a risk, hackers could sniff traffic with tools such a Wireshark and get users account details as the passwords would be sent in plain text. So changing the port so it would be in the 49152–65535 range would make it a little bit trickier for a hacker to guess the port. Of course a good hacker would have a port scanner to see what ports are open? This is why SFTP is much more secure as it involves a encrypted key using SSH protocol, makes it virtually impossible for the hacker to get users logon details.

If we use open for example a Youtube video and let it stream and let it stream and run the netstat  -an command we will see something different.

 

I have searched a CISCO video and let it stream:

Now when we run the netstat –an we can see that several ports are open and established

The established connections show where a SYN – SYNACK – ACK have been sent and completed, in the above screen shot where I have highlighted is the local address and ports.

The next highlighted field is the foreign address 

The next highlighted screen shot is showing the TCP state

So a summary

Established tells us SYN – SYNACK – ACK has been sent

Listening state  tells us that the local PC is waiting for a SYN

If its in the time wait state I am not transferring data anymore but I have to received FINACK – ACK FINACK – ACK which means its just siting waiting, when the wait is too long during the session it will eventually timeout

So we can see running netstat –an while a streaming video is open there are many connections. If we want we can filter out specifics. For example if we want to filter established connections we could run the following command.

netstat –an | find “ESTABLISHED”

this will show us all the established connections

We can then use a nslookup command on the first IP address:

nslookup 74.125.134.125

We can now see the result gg-in-f125.1e100.net

Now in google we can search 1e100.net to find out what that is, see following screenshot

We can now see that 1e100 is a scientific notation for google

Now we can continue down the established connections list and do a nslookup on the 23.64.66.127

Now we are presented with a result from Akamai technologies. An Akamai technology is an IT company in the US that provides load balancing. Basically videos are uploaded entry point server and the video is distributed to edge servers which are located all over the world, which in turn provides a high reliable service. Facebook actually uses the same system, SKY BSB, Geissendorfer und Leschinsky based in Germany who provides services for ZDF WDR SWR EinsLive Radio use the Akamai platform also.

So using google you can find many things out about netstat, ports, servers etc etc

Lastly UDP connections you can run the following command

netstat –anp “UDP” this will show all active connections, listening ports with protocols for UDP

If you notice UDP does not have a state, as we said previously it’s does not setup a session it has no 3 way handshake, infact we don’t see UDP conversations, all we see is what ports our workstation are listening for.

And now open a command prompt and run netstat –anp “udp” we will see the following 

We can now see locally the TFPT server running on port 69