Intro to the TCP/IP Stack: Transport Layer

Introduction to the Transport Layer

As we take a step deeper into the TCP/IP Stack, we learn about the Transport layer. After all, you know that your web browser is certainly communicating via the Internet, but how does it interact with the web server to get the content that you want to display in the web browser on your computer? Well, that is where the Transport Layer comes in; the Transport Layer connects a process on one host to a process on another host. Remember that a process is just a program in execution. From our Gmail scenario, your laptop's web browser process (as the web client) will use the Transport Layer to communicate with the web server process on mail.google.com.

Datagram or Segment? A message at the Transport Layer is called a datagram or a segment depending on what protocol is in use. Beyond connecting processes, Transport Layer protocols start the process of breaking arbitrary length Application Layer messages into smaller pieces for sending across networks. For example, you're on your phone and you want to download and install the latest social messaging app GipGak. The action of initiating the download is your request from the Application Layer, but the GipGak app is over 50MB in size, while most packets are 1500 Bytes in size. At the Application Layer, the app store sends the single 50MB file, but the Transport starts to break that single large message into smaller datagrams that can traverse the Internet. The Transport Layer is also the start of the encapsulation process on the sending end in the TCP/IP Stack, and conversely the end of the deencapsulation process on the receiving end.

Transport Layer Overview

Ports. When a host receives network traffic, the port number indicates which of the many processes executing on the host we want to receive that traffic. If we were to make an analogy to telephone traffic, it's like calling a big office: the phone number gets you to the office, but you need something extra — an extension — to identify which specific phone in the office you're trying to place a call to. At the Transport Layer, a port takes the role of the office phone number extension for networked communications. A port number identifies the process on which the host is communicating. The source port identifies the process communicating on the source host, and the destination port identifies the process communicating on the destination host. A port number is 16-bits in length with a range of 0–2¹⁶-1 (65535).

The following table summarizes all of this service/protocol/port/tool information. You need to be able to match up the service to protocol name to standard tool for each table entry. Why, because these are all so fundamental. You need to memorize only the highlighted rows.

The Internet Assigned Numbers Authority (IANA) maintains the Service Name and Transport Protocol Port Number Registry for ports, with RFC6335 organizing three ranges for allocation: (1) System Ports from 0-1023, (2) user ports from 1024-49151, and (3) dynamic or private ports from 49512-65535. In other words, network connections used by services will have dedicated ports under 1024 and all others are fair game. Look at the netstat connections in the console output below and review the source port numbers listed after the IP address. They are all in the high ranges at 49152 and above. These dynamic RHP communications are also referred to as ephemeral ports and are specified in OS-specific documentation for Microsoft Windows (49152-65535), Linux (32000-60999).

Knowledge Check: Managing network connections and assigning port numbers for services and user connections are managed by which area of a computer architecture?
Check Answer

Sockets. Applications leverage network connections to allow communications between two hosts. Within TCP (Transport layer) and IP (Network layer), sockets are derived from the connection required to allow processes on the hosts to communicate and include three properties - (1) Layer 4 protocol, (2) local address and port, and (3) remote address and port. Each socket can have only one connection. For example: A connection from your laptop's web browser to the Gmail web server might look like this (each port number comes after a colon):

  TCP    10.60.145.241:64855    172.217.12.229:443

.

Transport Layer Protocols

The most common Transport Layer protocols are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). In both cases, the Layer 4 protocol can split large data into smaller pieces, according to lower layer requirements, so that each piece (as a UDP datagram or TCP segment) can take the best path at that moment.

UDP

UDP is connectionless, in that the delivery of data is not critical and any lost packets are ignored. This is typically the case for real-time applications like Voice-over-IP (VoIP), video conferencing, or other streaming services. DNS operates on UDP:53, Trivial File Transfer Protocol (TFTP) on UDP:69, Network Time (NTP) on UDP:123, and Network Basic Input/Output System (NetBIOS) is on UDP:137 and UDP:138.

According to RFC 1594, a datagram is "a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network." It is a bare bones protocol, so if you need any degree of reliability when using UDP, you will need to depend on achieving that reliability in another layer of the TCP/IP Stack. As evidence that UDP is unreliable, datagrams may get dropped along the way or may arrive out of order. An application layer protocol using UDP needs to function despite these inconsistencies.

UDP is said to be a connectionless protocol. Beyond the unreliable communication concern, connectionless means that UDP each datagram stands on its own, much like the thank you letter you sent to grandma for the cookies. Multiple UDP datagrams between two communicating hosts are all treated as separate communications. Another way to put this is that UDP datagrams are like fire-and-forget munitions.

UDP avoids overhead on the sending and receiving end hosts by not providing services that other TCP/IP Stack layers may provide. Providing services increases overhead and consumption of resources such as CPU, RAM, and network traffic load. By not adding on lots of services, UDP significantly reduces the resources required by the hosts compared to TCP.

TCP

TCP is connection oriented, where the importance of data is critical enough to require that all transmissions are acknowledged. Connections always start with a three-way TCP-handshake process of SYN, SYN-ACK, ACK. Sequences are tracked to ensure the reassembly of data in the correct order and without any missing or corrupted data, which the receiver would request the transmitter to retransmit. TCP segments break apart data into sequences, allowing it to use the best path based on the networking layer and reassembled in order on the receiving end. TCP is considered reliable between connections because data is guaranteed as long as the two communicating hosts are reachable (recall ping and tracert). In fact, reliable communications is the big difference between TCP, UDP, and the other networking protocols mentioned.

TCP is considered a connection-oriented protocol. TCP communications are like communicating over a phone call: you establish a connection, which requires knowing the phone number (remote IP Address and port), and then communicate through the connection by having a back-and-forth conversation in which each party recognizes that the other heard what he or she said. As long as you don't hang up, you don't have to redial the number. You can also ask the other person to repeat something you did not quite hear well the first time.

A TCP connection comes with services that other protocols don't provide, namely TCP provides reliable communications. TCP detects segments that are lost, and the sender will resend segments that the receiver reports not receiving. TCP also puts segments in the correct order. If a receiver receives TCP segments out of order, then the receiving host will use information in the TCP header to correctly order those segments. TCP detects these errors because of the metadata in the TCP header.

So, what's the catch, why don't we use TCP for everything? Well, TCP is great, and many Application protocols make use of the reliable connections that TCP provides, but at the cost of overhead. TCP can provide those services only at the cost of overhead for the sender, receiver, and the network infrastructure in between. First, TCP must establish the connection before sending any Application Layer messages. TCP establishes connection by a process is called a "three-way handshake". In the simplest form of the handshake, a three way back and forth process must be completed in order to establish the connection. For example, if Alice wants to talk to Bob via TCP, Alice sends a TCP synchronize (SYN) request to Bob with some data to synchronize Bob to Alice (Part 1 of Handshake). Bob then replies with a combined TCP acknowledgment (ACK), acknowledging the synchronizing data from Alice, and TCP synchronize (SYN), with data for Bob's side of the connection (Part 2 of Handshake), called a SYN-ACK. Upon receiving Bob's TCP acknowledgment and synchronize, Alice sends a TCP acknowledgment (ACK) back to Bob acknowledging his synchronizing data (Part 3 of Handshake). Once the handshake is complete, the connection is ready for Application Layer data.

There is also overhead in detecting, and recovering from dropped segments. Throughout Alice and Bob's communication there is a series of TCP acknowledgments being sent to indicate what segments have been received. If a certain amount of time goes by and Alice has not received an acknowledgment from Bob, then Alice assumes that the segment was dropped, and then resends the segment. There are two details to highlight with that. First, Alice has to keep a copy of all of the segments that she sent until Bob acknowledges them, and Bob is doing the same thing on his end; that is, each host stores sent segments until the other host acknowledges the data. Again, that is overhead. Second, it took some amount of time for Alice to realize that Bob did not receive a segment. In practice, that time is low, on the order of 100s of milliseconds to seconds, but when compared to nanoseconds (10^-9), that is a long time.

TCP also adds some other services that lower layer protocols do not. TCP provides flow control and congestion control. Flow control is a mechanism for the sending host to not overwhelm the resources of the receiving host. For example, flow control will limit the rate that data are sent to the receiver so as to not fill the receiver's resources. Remember that maintaining the connection requires CPU and RAM. Congestion control is a mechanism for the sending host to not overwhelm the network infrastructure. If Alice detects a number of segments not being received by Bob, then Alice will infer that some portion of the network infrastructure between Alice and Bob is overwhelmed, so Alice will reduce the rate in which she sends segments to Bob. Again, congestion control burdens the host's CPU. Both hosts are maintaining the connection state, managing flow control, and managing congestion control. So, the price of reliable communications is overhead; depending on the application, that overhead may be worth it, or not.

Source and Destination Port Numbers

Understanding how operating systems assign ports to the Layer 4 protocol header is necessary for analyzing network traffic flows.

• The client assigns a destination port number to match the port number identified in the table above for the service offered on the server. For example, when you use your laptop's web browser to connect to Gmail, it assigns port 443 (HTTPS) as the destination port number because the Gmail web server has a daemon listening for incoming connections on port 443.
• The client assigns an ephemeral port number as the source port. It does not assign the port number associated with the service (443 in this example); if it did, your laptop would become extremely limited on connections that it could make because each socket can have only one connection. Using ephemeral ports enables multiple connections from your laptop to the same web server (for multiple browser tabs open on the same site, for example) by making the local port number different for each connection.
• When the server replies to the client, it uses the port numbers but with the source and destination swapped. For example, if it received traffic from port 54321 to its port 443, then it will send from its port 443 to the client's port 54321. This enables the client to recognize the reply as belonging to the same connection that sent the request.

Building on the Gmail scenario, your laptop uses DNS (UDP port 53) to resolve the name mail.google.com to its IP address. Once resolved, your browser can establish an HTTPS (TCP port 443) connection with mail.google.com, which requires a TCP connection (which starts with a three-way handshake) and encryption through TLS (an application-layer protocol).

1. Your laptop's application layer generates a DNS query (#1) and passes it down to your laptop's transport layer.
2. Your laptop's transport layer encapsulates the DNS query (#1) in a UDP datagram (#2) and passes the datagram to your laptop's network layer. The source port number is an arbitrary ephemeral port number, and the destination port number is the default for DNS (53).
   **See the next lesson for what happens below the transport layer.**
   The DNS server's transport layer receives the deencapsulated UDP datagram (#2), deencapsulates the DNS query (#1), and passes the DNS query (#1) up to the DNS server's application layer.
3. The DNS server's application layer processes the DNS query (#1), generates a DNS response (#3), and passes the DNS response (#3) down to the DNS server's transport layer.
4. The DNS server's transport layer encapsulates the DNS response (#3) in a UDP datagram (#4) and passes the UDP datagram (#4) to the DNS server's network layer. For the port numbers, the DNS server uses the same port numbers for the response as were used for the query. As such, the source port number for this response matches the port through which it received the query (port 53), and the destination port number for this response matches the port through which the DNS client transmitted the query (port 54321).
   **See the next lesson for what happens below the transport layer.**
   Your laptop's transport layer receives the deencapsulated UDP datagram (#4), deencapsulates the DNS response (#3), and passes the DNS response (#3) up to the application layer.
5. Now that your laptop has the IP address for mail.google.com, your laptop's application layer generates an HTTPS request (#5) for the Gmail web server and passes it down to your laptop's transport layer.
6. Your laptop's transport layer recognizes the need for a TCP connection to support HTTPS, so it initiates the TCP three-way handshake by generating a TCP SYN (#6) and passing it down to your laptop's network layer. The source port number (54322) is merely incremented from the last assigned ephemeral port number, and the destination port number is the default for HTTPS (443). Because TCP is connection-oriented, your laptop and the Gmail web server will use these same established sockets for all remaining TCP communications in this session.
   **See the next lesson for what happens below the transport layer.**
   The Gmail web server's transport layer receives the deencapsulated TCP SYN (#6).
7. The Gmail web server's transport layer generates a TCP SYN-ACK (#7) and passes it down to the Gmail web server's network layer.
   **See the next lesson for what happens below the transport layer.**
   Your laptop's transport layer receives the deencapsulated TCP SYN-ACK (#7).
8. Your laptop's transport layer generates a TCP ACK (#8) and passes it down to your laptop's network layer.
   **See the next lesson for what happens below the transport layer.**
   The Gmail web server's transport layer receives the deencapsulated TCP ACK (#8), thus completing the TCP three-way handshake.
9. Your laptop's transport layer recognizes the need for encryption so it negotiates the TLS configuration with the Gmail web server. In this back-and-forth (#9), each host continues to communicate through the network stack.
10. Finally, your laptop's transport layer encrypts and then encapsulates the HTTPS request (#5) in a TCP segment (#10) and passes the segment to your laptop's network layer.
    **See the next lesson for what happens below the transport layer.**
    The Gmail web server's transport layer receives the deencapsulated TCP segment (#10), deencapsulates and then decrypts the HTTPS request (#5), and passes the HTTPS request (#5) up to the Gmail web server's application layer.

How DHCP works at Layer 4

The DHCP protocol runs over UDP, using ports 67 and 68. So, why UDP for DHCP? Well, let's think about that a little. TCP certainly has a great feature in that it provides reliable communications between the two hosts. Recall that we said TCP is connection oriented, and that the two hosts need to synchronize in order to start exchanging messages, exchanging data. Well, that synchronization cannot occur if one of the hosts does not have an IP address. The whole reason why a client uses DHCP is so that it can get an IP address. Therefore, DHCP cannot use TCP, DHCP must use UDP. UDP allows a host to send a message without a connection; a host does not need to establish a connection in order to create a UDP datagram and an associated IP packet.

Layer 4 Network Utilities

netstat

The netstat command provides network status and protocol information by listing all the host's sockets. Options provide additional information, such as process IDs (-o) associated with network connections and ability to display port numbers (-n) instead of protocols. Based on the scenario in the illustration above, a TCP connection on the local system was established on port 64855 (an ephemeral port) to the destination port of 443 (the default for HTTPS) and can be observed in the connections listed in the command output below: The ESTABLISHED state is the way that netstat indicates that the TCP session is active, that a connection is established between the two processes on the two hosts.

PS C:\Users\m9999> netstat -ano | findstr ":443"
  TCP    10.60.145.241:55813    142.251.45.98:443      ESTABLISHED     10472
  TCP    10.60.145.241:55878    104.16.19.94:443       ESTABLISHED     10472
  TCP    10.60.145.241:55969    142.250.73.196:443     ESTABLISHED     10472
  TCP    10.60.145.241:55973    172.217.1.202:443      ESTABLISHED     10472
  TCP    10.60.145.241:56343    142.251.33.206:443     ESTABLISHED     10472
  TCP    10.60.145.241:57179    172.217.13.238:443     ESTABLISHED     10472
  TCP    10.60.145.241:57308    142.251.45.98:443      ESTABLISHED     10472
  TCP    10.60.145.241:58207    142.251.45.98:443      ESTABLISHED     10472
  TCP    10.60.145.241:58729    172.217.1.195:443      ESTABLISHED     10472
  TCP    10.60.145.241:59080    157.240.229.35:443     ESTABLISHED     10472
  TCP    10.60.145.241:59750    172.217.9.197:443      ESTABLISHED     10472
  TCP    10.60.145.241:60573    142.250.65.78:443      ESTABLISHED     10472
  TCP    10.60.145.241:61205    142.250.188.33:443     ESTABLISHED     10472
  TCP    10.60.145.241:61349    142.250.188.206:443    ESTABLISHED     10472
  TCP    10.60.145.241:61778    142.250.188.202:443    ESTABLISHED     10472
  TCP    10.60.145.241:63006    199.127.207.183:443    ESTABLISHED     10472
  TCP    10.60.145.241:63785    172.253.63.188:443     ESTABLISHED     10472
  TCP    10.60.145.241:63864    208.118.62.69:443      ESTABLISHED     10472
  TCP    10.60.145.241:64634    162.247.243.146:443    ESTABLISHED     10472
  TCP    10.60.145.241:64855    172.217.12.229:443     ESTABLISHED     10472
  TCP    10.60.145.241:64957    172.217.15.74:443      ESTABLISHED     10472
  TCP    10.60.145.241:65196    142.251.45.98:443      ESTABLISHED     10472

It is common for computing systems to synchronize clocks to maintain logging and auditing for applications. This is where NTP is configured as a global listener, depicted by 0.0.0.0:123.

PS C:\Users\m9999> netstat -ano | findstr ":123"
  UDP    0.0.0.0:123            *:*                                    2108
  UDP    [::]:123               *:*                                    2108

The 0.0.0.0 IP address indicates that the local host is listening on any of its IP addresses. (Hosts can have multiple IP addresses.) Notice that each of the processes listening (State LISTENING) are listening on a specific port; that is, even though the host is listening on all IP addresses, a process listens on a specific port. Since the processes are listening for incoming communications, they are considered server processes, called daemons; in networked communications, the process that is listening for incoming communications is the server process, waiting for incoming communication from a client process on a remote host. Once a client process on a remote host sends a message to the server host, the connections would switch to ESTABLISHED as in the first code listing.

NetKitten

netkitten (nk) is a very simple but powerful USNA tool based on netcat (nc). nk can be used in either server mode or client mode; i.e. nk can listen for and accept an incoming phone call, or initiate a phone call. In the client mode of netkitten, you give it an IP Address (or symbolic name that it will resolve for you via DNS) and a port number, and whatever you type into after pressing enter gets sent to the given address and port using TCP over IPv4. In the server mode of netkitten. you give the -l option (listen) and nk then acts like a server, "listening" for a connection request. Accepting the first one it receives, then echoing whatever gets sent to it to the screen, and taking whatever gets typed on the screen and sending it to the client whose connection request it accepted. The diagram below illustrates what commands users on two hosts would have to give to make a TCP connection with netkitten.

The server command on Host 10.53.88.12 must be given first! Otherwise, when the client calls there's nobody home! netkitten with the -u option (UDP) uses UDP instead of TCP. Since this is connectionless, the server version accepts datagrams from any and all who send them, rather than making a connection with one client. As another consequence, the UDP server doesn't exit just because one of the clients exits. With netkitten, we as users can act like Application Layer programs. Like most Application Layer programs, we require that the Transport Layer provide us with services, which means at a bare minimum that we decide whether we want UDP or TCP. There are lots of interesting demos and activities we can do that demonstrate how TCP and UDP work and how they differ from one another; especially if we are using protocols that are text oriented, easy for humans to create and read.

---

Activity: Evaluating Established Network Connections

Establish a connection to the SSH server and review the connection details.

1. Open PowerShell.
2. Document the IP address assigned to the computer by running ipconfig /all and looking at the IPv4 Address for the network adapter being used.
3. Connect to the SSH server: ssh m9999@
     Note: commands will be executed on the remote server from here.
4. While connected to the remote Linux server, take a look at network connections and see if you can find the IP of the computer the connection was established from: netstat -ant | grep ":22"
   
   

   The remote system is a server, thus it is expected for many other users to also have established connections to that system. Once you find the IP of your system, copy that line to Notepad++. The output should look similar to the example below: tcp6 0 0 10.1.83.73:22 10.60.145.241:51815 ESTABLISHED

5. Leave that connection open and initiate another PowerShell window to observe the connection from the host by entering netstat. It will take a moment to process all of the connections running on the system that will be populated line by line.
6. Filter the netstat output by piping it to the findstr command and search for the port number associated to SSH: netstat -an | findstr ":22"

   PS C:\Users\m9999> netstat -an | findstr ":22" TCP 10.60.145.241:51815 10.1.83.73:22 ESTABLISHED

Knowledge Check: What are the socket connections for the client and server hosts?
Check Answer

From each of the server's and client's perspectives, the SSH connection's sockets identify the Layer 4 protocol, the source IP address and port and the destination IP address and port. The SSH service on the server uses a default port number 22 and the client chooses an arbitrary ephemeral port number, 51815 in this example.

Now, we can figure out which network services are running on a computer. This is a big deal when it comes to assessing a computer's risk for intrusion. Think of it this way, if you wanted to protect your home from intruders, then you would want to know where all of the possible entrances are so that you could secure or seal them. The same notion applies to processes providing network services on computers, fewer running services (and hence, fewer open ports) is better (typically considered to be more secure) than more running services. Unnecessary services should be stopped and removed from computers to make them more secure from network based attacks.

Take a moment to review other established network connections on your computer by running the netstat command. Don't forget to use the /? help command to see the options available and also pipe the output using findstr filter a specific service. We'll explore netstat further in the next lesson.

Supplemental Media:

TCP vs UDP Comparison

Review Questions:

1. What is the purpose of the Transport Layer?
2. What do we use for addresses at this layer?
3. Why do we need to break messages from the Application layer into segments at the Transport layer?
4. What are the key differences between UDP and TCP?
5. What are the port numbers associated with the following: HTTP, HTTPS, DNS, and SSH?
6. Why is it important to reduce the number of services that are running on your computer?
7. What network utility is used to evaluate Transport Layer connections?

References

1. Transmission Control Protocol (TCP) - Request For Comment (RFC) 793
2. User Datagram Protocol (UDP) - RFC 768