The Transmission Control Protocol (TCP) is the single most widely used transport layer protocol. TCP is used by the majority of the common application layer protocols, including FTP, email (SMTP), Web (HTTP), Telnet, and Secure Shell (SSH). Nearly every application layer protocol that requires a connection oriented service uses TCP. Even though physical, data link, and network layer protocols may vary, TCP is effectively available universally.

Although TCP is a common basis for connection-oriented transport services, the User Datagram Protocol (UDP) provides connection-less support. DNS, real time collaboration (e.g., VoIP and NetMeeting), and file-sharing protocols such as NFS and SMB, commonly use UDP. Together, TCP and UDP account for more than 98 percent of all packets traversing the Internet.

TCP’s functionality provides reliable and ordered end-to-end communication. When viewed independently, each of the functions, from connection to data ex-change and from state flags to sequence numbering, pose no direct security risk. Instead, the risks come from combining the various functions. These combinations can be used for reconnaissance, hijacking, or effective DoS attacks. Due to their high availability, exploits that impact TCP and UDP are likely to threaten virtually every service on the network.

TCP and TCP/IP

TCP was designed for the transport layer in the DoD TCP/IP stack because of this close association, the transport layer for the TCP/IP stack is sometimes called “TCP” instead of “Transport.” Adding confusion, TCP is sometimes mistakenly called “TCP/IP”—using the stack name instead of the protocol’s name. Similarly, UDP is sometimes mistakenly referred to as “UDP/IP.” For clarification, TCP and UDP are protocols, and TCP/IP is the DoD network stack. (And, UDP/IP does not exist.)

Connection-Oriented Protocol

TCP is a connection-oriented protocol and offers two guarantees for higher layer protocols: reliable data delivery and sequential data ordering. As a transport layer protocol, TCP also provides facilities for flow control and multiple connections.

TCP uses a byte-stream data flow model. In this model, the byte ordering is important, but the TCP packets are not. TCP packets may be combined or split as long as the data’s byte ordering is maintained. This is different from other protocols such as IEEE 802.1, PPP, and IP, where the message blocks delimitate data flow. TCP uses a segmented header to enclose transmission data. Besides the basic 20-byte header, TCP also may include optional header information. The smallest TCP packet (containing no data and no options) is 20 bytes, whereas the largest can exceed 64 KB. Usually a TCP packet with data is only a few kilobytes in size, which ensures that one TCP packet can fit within one data link layer frame.

The data being transmitted by the TCP packet is often called application data or user data. Although the data may come from the application layer or user layer (outside the OSI stack), the session or presentation layers can also generate transport data.
Reliable Acknowledgements

TCP guarantees reliable data delivery. Each byte sent by a TCP packet is confirmed with an acknowledgement. If no acknowledgement is received, then it assumes that the data transfer failed. To reduce the number of acknowledgements, TCP uses a windowing system. This system acknowledges the amount of data received.

Checksums

TCP encases the application data within a TCP header. The TCP header includes a simple checksum value to detect transmission corruptions. The checksum function is a 16-bit CRC function, similar to the checksum used by IP, and covers the entire

TCP header and application data. Corrupted packets with invalid checksums (that somehow manage to pass lower layer checks) are discarded and not acknowledged. Although RFC791 and RFC793 state that TCP packets with invalid checksums should be discarded, some TCP implementations do not validate checksums. By skipping the validation, portable devices, gateways, and packet filters can reduce per-packet processing time and improve speed performance.

Retries

To ensure data is properly delivered, TCP resends unacknowledged data. The retry time interval varies based on the network speed, but is usually less than 2 minutes. Data transfers may be retried many times before the connection is assumed to be inactive and closed. This long duration can hang applications that wait for TCP to deliver data. For example, if an application blocks on writing to the network socket, then the application may appear temporarily hung while TCP waits for transfer confirmation. If there are 7 retries, 1 minute apart, then an application may hang for 7 minutes before detecting the failed connection. Under most Linux systems,

TCP defaults to 15 retries (see the Linux command, sysctl net.ipv4.tcp_retries2); delays under Linux can be as long as 30 minutes. Most Windows systems retry 5 times, resulting in shorter delays. Retransmission timeout (RTO) durations are based on the round trip time (RTT) of each TCP packet. This is a measurement based on the time it takes to receive an acknowledgement for a given packet transmission [RFC793]. In general, faster networks have smaller RTT values, leading to a shorter retry duration. In the best case, a fast network will result in rapid detection of unacknowledged packets. In the worse case, TCP may hang for minutes as it times out and retries.

Sequence Numbers

TCP guarantees the order of application data delivery. Although lower layer protocols may transmit and receive packets out of order, TCP will reconstruct the ordering before passing the data up the stack to an application. The reconstruction is based on sequence numbers. Each TCP packet is assigned a sequence number, and subsequent packets increase the sequence number by the amount of data transported.

For example, if the sequence number is 12345 and 100 bytes of application data are transmitted, then the next sequence number will be 12445. TCP provides full-duplex communication; both sides may transmit data at the same time. To minimize the number of packets, each TCP packet may data transfer and acknowledge a previous transmission. The packet header stores the current sequence number for the data being transmitted, as well as an acknowledgement for previous data received.

TCP does not acknowledge data receipt directly. A direct confirmation would acknowledge each transmitted packet. Instead, the TCP acknowledgement packet (ACK) confirms the data but not the packet itself. Each ACK includes the next expected sequence number. If all data has been received, then the next expected sequence number would match the next transmission’s sequence number. Using this approach, a gateway or proxy can collect packets, combine (or split) TCP data, and reformat the data into new packets. The reply identifies the amount of data received and not individual packets.

Flow Control

TCP manages data flow using control flags and windows. These two methods combine to provide transport state, acknowledgements, priority, and optimized buffering.

Control Flags

Each TCP packet header contains 12 bits for use as control flags. One flag denotes an acknowledgement, another identifies a reset request, and a third defines urgent data. In total, there are six primary control flags (Table 15.1). The flags do not need to be used symmetrically. For example, the client may send a reset to the server to tell the server to resend all unacknowledged data; however, this does not reset the data from the client to the server—it only resets the state from the server to the client.

Window Size

In a basic connection-oriented system, each transmission is acknowledged. The acknowledgement confirms data delivery, but creates significant overhead and delays. For example, if the transport layer needs to pass 100 KB of data, it may segment the data into 100 packets containing 1 KB each. Each of the 100 packets would require a confirmation—another 100 packets. To reduce the amount of bidirectional communication, TCP allows each packet header to define the amount of data that can be transferred before requiring an ACK. If the client specifies a window size of 8,192 bytes, then the server can send up to 8,192 bytes of data before requiring an ACK.

For large transfers, larger window sizes can be used; however, the TCP header only supports 16 bits for the window size—a maximum of 65,535 bytes. RFC1323 defines an optional extension to the TCP header for window scaling. The scale indicates the number of bits to right-shift the window size. As an example, a window value of 0x05B4 indicates a 1460-byte window. But when combined with a right shift of 3 (multiply by 23, or shift the bits 3 positions), the value denotes 11,680 bytes. A window size of 1460 bytes is very common. It is based on an Ethernet packet data size of 1,500 bytes (MTU 1500), minus the 20 bytes for the IP header and the 20- byte minimum for the TCP header. A shift of “3” indicates that the recipient can buffer up to eight (23) packets before forcing an acknowledgement.

Even when using large transfer sizes, it can be desirable to force an acknowledgement before the recipient’s buffer fills. The sender’s push flag (PSH) is usually sent with the last packet in a large block. This flag informs the recipient to acknowledge the entire data transfer before the next transfer begins.

Multiple Connections and Ports

The source and destination port numbers are combined with the source and destination network addresses to define each TCP connection. Data from one set of ports and addresses (one connection) is not intermixed with data from another set of ports and addresses. This allows the host system to manage many connections at once.

A TCP server binds to a specific port. For a client to connect to the server, it must first acquire its own local port number. Then it connects to a server and establishes a unique transport session defined by the network client and server addresses as well as the transport client and server ports. This unique combination of source and destination ports and network addresses allows a single Web server to operate on 80/tcp while transferring data to a variety of clients. As long as the clients have different network addresses—or the same network address but different client ports—the connection remains unique.