- 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-
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
[View full size image]
- 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
• 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
• 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.
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
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.