Transmission Control Protocol (TCP)

TCP is a connection-oriented transport mechanism that resides at Layer 4 of the OSI model. TCP implements the concept of sessions between hosts to serve as virtual circuits upon which higher-layer data and communications are delivered. In doing so, TCP addresses the inherent unreliability of lower-layer protocols such as IP, providing a means of ensuring that data is accurately and reliably transmitted between hosts.

The foundation of TCP is the creation of a session between hosts. This is performed through the use of a process known as the TCP three-way handshake. When a host decides it needs to transmit data to another host using TCP, it contacts that host with information regarding the initial sequence number that it will use for the session. This data is transmitted to the destination host in a segment known as a synchronize (SYN) segment. This is the first part of the handshake. The destination receives the SYN segment and responds with an acknowledge (ACK) segment to acknowledge the receipt of the SYN segment. In addition, it notifies the original source of its initial sequence number using it is own SYN segment. Although these are two distinct processes (the ACK and the SYN), they are typically combined into a single segment for efficiency of communication. Therefore, this segment is commonly referred to as a SYN/ACK segment and is the second part of the handshake. The originator then responds to the destination with its own ACK segment acknowledging the receipt of the SYN/ACK. This is the final step of the three-way handshake, and at this point the two hosts have established a virtual circuit between each other upon which all data will be transmitted. Figure 3-8 depicts the three-way handshake between hosts.

Figure 3-8. Example of TCP Three-Way Handshake

Reliability will be handled by each host periodically checking in with the other to confirm the successful receipt of data using a process known as sliding windows. If any data is lost, the hosts can retransmit the data upon discovery of the data loss, thereby ensuring the reliable and successful delivery and receipt of all transmitted data.

Because of the reliability of TCP, any application or protocol that requires data transmission to be verified typically implements TCP as a transport mechanism. This includes protocols such HTTP, FTP, SMTP, and most network file-sharing applications such as Microsoft Windows Server and Workstation services. As discussed when we examine the TCP segment header, TCP uses port numbers to identify the higher-layer application or protocol that the data came from and is destined to. These port numbers are assigned and maintained by Internet Assigned Numbers Authority (IANA), which provides a full list of registered port numbers at http://www.iana.org/assignments/port-numbers.

Note

The following RFCs define TCP:

• RFC 0793

• RFC 3168

TCP Segment Structure

The TCP segment is structured similarly to an IP packet in that it contains two general components: a TCP header that contains processing information about the segment, and a data section that contains the data that was presented from/to higher-layer protocols and applications. The TCP header, much like the IP header, is typically 20 bytes in length. The data can be of variable length. Unlike IP, determining the maximum TCP segment length takes a bit of math. As a general rule, the maximum TCP segment length is calculated as being 40 bytes less than the maximum transmission unit (MTU) of the transmitting interface. This 40-byte subtraction represents both the TCP and IP header, so the remaining data would be the actual data contents of the segment. So, for example, using Ethernet with an MTU of 1500, the TCP maximum segment size would be 1460 (or 1460 bytes of data) with a 20-byte TCP header (1480 bytes total) and a 20-byte IP header (1500 bytes total).

TCP Segment Header

Like IP, the TCP segment header typically consists of five 32-bit words, with the potential for optional words containing additional options and the relevant padding to make 32 bits of data. Figure 3-9 depicts the TCP segment header.

Figure 3-9. TCP Segment Header Structure

The fields of the TCP segment header and their meanings are as follows:

• Source Port (16 bits) This field represents the source protocol or application. This allows the source to know which application the data belongs to so that responses can be delivered to the appropriate source application. In most cases, the source port is a random high-level port number (>1024) generated by the application.

• Destination Port (16 bits) This field represents the destination protocol or application on the target host. This allows the destination to properly route the data to the appropriate higher-layer application or protocol. In most cases, the destination port is a defined (and in some cases well known) port number that is associated with the protocol or application in question.

• Sequence Number (32 bits) This field contains the information necessary for the hosts to know what data has been transmitted. If the SYN control bit is enabled, this value is the initial sequence number (ISN) and the first data octet is the ISN+1.

• Acknowledgement Number (32 bits) This field contains the value of the next sequence number the sender is expecting to receive. This field relies on the ACK control bit to be set and is always sent after a session has been established

• Data Offset (4 bits) This field indicates where the actual data begins by specifying how many 32-bit words exist in the TCP header. It is also referred to as the Header Length (HLEN) field.

• Reserved (4 bits) This field is reserved for future use and must have a value of 0.

• Explicit Congestion Notification (ECN, 2 bits) This field is used, like in IP, for ECN information. The first bit is used to set the Congestion Window Reduced (CWR) flag; the second bit sets the ECN-echo (ECE) flag.

• Control bits (6 bits from left to right) The control bits tell the hosts what they should be doing with the session. There are 6 bits that can be either on (1) or off (0) and from left to right they are as follows:

  - URG This indicates that the Urgent Pointer field is significant.
  
  

  - ACK This indicates that the Acknowledgment field is significant.
  
  

  - PSH This indicates that the push function is requested.
  
  

  - RST This indicates that the connection should be reset.
  
  

  - SYN This indicates that the sequence numbers should be synchronized.
  
  

  - FIN This indicates that there is no more data from the sender and the session can be terminated.
  
  

• Window (16 bits) This field represents the number of data octets that will be transmitted before an ACK is expected.

• Checksum (16 bits) This field verifies that the data received is the proper size as what was transmitted.

• Urgent Pointer (16 bits) This field is only processed in segments where the URG control bit is set and communicates the value of the urgent pointer as a positive offset from the sequence number of the current segment.

• Options (variable) The Options field contains any number of variable option values that must be understood by all TCP hosts, but in practice are rarely used.

• Padding (variable) This field provides the necessary padding to the Options field to ensure that the data length is 32 bits.

Bad TCP

Because of how TCP functions, it is susceptible to a number of "bad" implementations and functions, starting with the manner in which sessions are established. When TCP hosts begin to initial a session, the destination host receives a SYN, responds with a SYN/ACK, and then waits for an ACK response. Malicious TCP traffic can take advantage of this process using what is known as a SYN flood. In a SYN flood, the host is inundated with session requests but no final ACK. Therefore, the host slowly fills its receive buffers with incomplete session requests waiting for the final ACK. When the buffers are full, the host can no longer accept new session requests and begins dropping the new session requests, effectively causing a denial of service.

Another example of bad TCP involves the use of non-random-sequence numbers. This allows a malicious host to determine what the expected sequence number is and insert itself into the conversations. Because the destination host uses the sequence number to put the data back together, it can be tricked into believing that the malicious data is the correct data.

If random-source and destination ports are implemented irresponsibly, they can also cause problems with TCP traffic, especially with firewalls. Most firewalls use TCP source and destination ports as part of the decision-making process for their rulesets. In particular, if an application uses random-destination ports, it can make it near impossible to protect the host behind a firewall because you cannot guess what port may be in use and therefore must potentially open multiple/all TCP ports to allow communications. With a stateful firewall, random-source ports are not as big a deal; in some circumstances, however (especially when implementing egress filters), they can make it all but impossible to allow hosts to securely respond to requests, such as when the communication is initiated on one port and then uses a different and/or random port. A good example of this is the X Display Management Control Protocol (XDMCP), which establishes the initial communications session on one port and then dynamically switches to a different port for the transmission of data.