Republished with permission from WatchGuard Technologies, Inc.

WatchGuard


Foundations: What Is TCP?

by David M. Piscitello, President, Core Competence, Inc.

An inscription on the General Post Office in New York City claims, "Neither snow nor rain nor heat nor gloom of night stays these couriers from the swift completion of their appointed rounds."  The USPS tries its best, but in reality, bad weather, accidents, and random acts of sloth and stupidity prevent it from being 100% effective in mail delivery.

It's hard to find anyone who hasn't lost a letter, or had a parcel arrive damaged, or a postcard arrive unreadable. I live at 3 Myrtle Bank Lane, which is a cul de sac at the end of Myrtle Bank Road. The family at 3 Myrtle Bank Road routinely receives mail addressed to me and returns the mis-delivered mail to the courier.

A previous LiveSecurity article, "Foundations: Internet Protocol for Beginners," draws an analogy between the U.S. Postal System and the way chunks of information called IP packets are sent across the Internet. What postal mail and IP share is their normal delivery service model, which we call best effort. For real-world situations where we need "better than best effort" delivery, we often choose courier services that guarantee correct and timely delivery and insure against loss. Similarly, IP is one of several protocols that work together to make the Internet fast, functional, flexible, and consequently, successful. But when you need "better than best effort" transmission for your data, an equally important protocol, Transmission Control Protocol (TCP), helps make communications across the Internet reliable.

TCP is known as a reliable delivery or reliable transport protocol: its job is to make certain that the information you send -- whether mail to a friend, or an online banking transaction -- is delivered to your friend, or the bank, undamaged and without loss, in a timely manner, and in the order submitted. To illustrate how TCP manages this, let's consider another analogous form of communications: marine radio.

How TCP Works

In many respects, the problems TCP attempts to correct are similar to those that ships face when they use VHF/FM and Single Sideband to communicate over their various radio frequencies (distress, calling, and working/ship-to-ship). Weather and distance can interfere with both near- and offshore radios, so to overcome loss and garbled transmission, mariners have adopted internationally recognized calling and answering procedures. A radio operator should hail a ship by name and identify his own ship as well; e.g., "Titanic Titanic Titanic, this is the Lusitania Lusitania Lusitania, OVER."

Just as a radio operator uses names to identify ships, TCP uses ports to identify source and destination applications. Ports are conveyed in every chunk of data TCP carries. Like IP packets, these chunks, called segments, have header information, followed by application data. Port numbers are included in the header, along with a set of flags that indicate the kind of action the segment is performing. A Synchronize (SYN) flag is turned on to mark the start of a TCP session. In nautical terms, the SYN flag is how TCP in one computer, hhi.corecom.com, "hails" another computer, cs1.vpnday.com.

In our example, the Titanic's radio operator is listening for calls. To respond to Lusitania's call, he replies, "Lusitania Lusitania Lusitania, this is the Titanic, OVER." In like manner, TCP running in cs1.vpnday.com responds to the Synchronize segment from hhi.corecom.com by replying with its own segment. But in this reverse direction, cs1.vpnday.com sets both the Synchronize and Acknowledgement (SYN/ACK) flags, to say "I received your call request and I want to send information to you as well."

Back on the Lusitania, the radioman has received the Titanic's response and now knows  Titanic is alive and within radio reach. The radio operator on the Titanic, however, can't be absolutely certain his reply reached the Lusitania until he receives another message from that mighty ship. Assume the radioman on the Lusitania obliges and sends a "COPY THAT, Titanic" message. TCP uses a similar technique: hhi.corecom.com sends a segment to cs1.vpnday.com with the Acknowledgement (ACK) flag set.

To summarize: when establishing communication via TCP, Computer 1 sends a packet bearing a SYN flag. Computer 2 sends back a packet with the flags SYN/ACK. Computer 1 replies with an ACK, and communication can begin. This sequence, called a three-way handshake, is how every TCP session begins. (If you'd like to see it in technical detail, consult this sample TCP session.)

TCP Reliability Mechanisms

An important aspect of providing reliable transfer is assuring that the data transmitted across the Internet from one application to another is delivered as an exact duplicate of the original. If I attempt to deliver a small file containing the ASCII text "Please do not eat the daisies," but deliver instead, "Please eat the daisies," or "not eat Please the daisies," or "Please do do do eat the daisies," I've failed to protect the transfer against loss, out of order delivery, or duplication, respectively.

Acknowledging successful delivery, and dealing with loss
During a typical radio conversation, a radioman will ask "DO YOU (HEAR) COPY? OVER,"to ascertain whether his message was received. A response such as "MESSAGE RECEIVED" or "THAT IS CORRECT" is the appropriate response for indicating "I heard every word you said, clearly." If no response of this nature is delivered, a radio operator will pause, then repeat the message. TCP protects against loss in a very similar way. Implicit in the transmission of a TCP segment is a request for a positive acknowledgement. Also implicit is that the sender will retransmit upon timeout, which simply means that if TCP doesn't receive a segment containing an acknowledgement for data it has sent, it will resend the unacknowledged data.

Handling mis-sequenced and duplicate delivery
Greatly simplified, TCP randomly chooses a number it will use as the base number for identifying bytes in the application data it is about to send. In each segment containing application data, TCP writes a data offset, which tells the receiver, "Add this value to the initial number I sent you and that's where this chunk of application data begins." Such techniques are required because a stream of Internet packets may not remain in sequence as the packets find their way across who-knows-how-many routers, making their way from Point A to Point B. The data offset tells the receiver how to connect chunks of application data so that the receiver can reconstruct an exact copy of the original data transmitted, and helps TCP distinguish duplicates among the data received.

FINishing up

When a radio operator wishes to indicate he has nothing further to say, he concludes a message with the keyword "OUT" instead of "OVER." If a radioman were to confirm he received your last message and wished to end the conversation, he might say "Lusitania, THAT IS A COPY, thank you, Titanic OUT." TCP implements the same concept, called a graceful close. Graceful close means that TCP waits until it's received an acknowledgement for all the unacknowledged data it's sent -- and has acknowledged all the data it's received -- before it shuts down. Like the Synchronize message sequence, graceful close is a three-way handshake. So if TCP at hhi.corecom.com begins the connection close process by issuing a segment with the Finish (FIN) flag set; TCP at cs1.vpnday.com will return a segment with the Finish and Acknowledgement (FIN/ACK) flags set which also confirms that all the data hhi.corecom.com has sent has been delivered.

Compared to postal or radio communications, TCP transactions occur at blinding speed, and (usually) behind the scenes. That tempts us to take TCP for granted. But a proactive network administrator will get to know TCP, because hackers abuse it in several common ways. One popular attack involves sending mass quantities -- a flood -- of SYN packets to a victim computer, but not acknowledging the resulting SYN/ACK response. This forces the victim computer to waste time and resources waiting for a response that will never come, ultimately resulting in a Denial of Service. Hackers also know how to take over a TCP session after the handshake, intercepting packets originally intended for someone else and responding while posing as that someone. So a basic understanding of TCP will aid you in your quest to secure your network.

I'll explain more about TCP attacks in a future column; for now, you've got the foundation -- and below, you'll find great resources for learning more on your own. So to close gracefully: Reader reader reader, this is Dave Dave Dave, out. ##

Resources:

RFC 879 (functionally, the specification for TCP)

Open Systems Networking: TCP/IP and OSI, Chapter 12, by David M. Piscitello and A. Lyman Chapin

TCP/IP Illustrated, Volume 1: The Protocols, by W. Richard Stevens
A very detailed book, widely regarded as the best work on TCP.

Sample TCP Session, captured with Ethereal

More Foundations articles


Copyright© 2003, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.



Copyright © 1996 - 2003 WatchGuard Technologies, Inc. All rights reserved.