Sign In Sign-Up

Welcome!

Close

Would you like to make this site your homepage? It's fast and easy...

Yes, Please make this my home page!

No Thanks

  Don't show this to me again.

Close

A Brief Primer on TCP/IP

Examined here are the Transmission Control Protocol (TCP) and the Internet Protocol (IP). These two protocols (or networked methods of data transport) are generally referred to together as TCP/IP.

TCP/IP: The Basics

What Is TCP/IP?

TCP/IP refers to two network protocols (or methods of data transport) used on the Internet. They are Transmission Control Protocol and Internet Protocol, respectively. These network protocols belong to a larger collection of protocols, or a protocol suite. These are collectively referred to as the TCP/IP suite.

Protocols within the TCP/IP suite work together to provide data transport on the Internet. In other words, these protocols provide nearly all services available to today's Net surfer. Some of those services include

Ø      Transmission of electronic mail

Ø      File transfers

Ø      Usenet news delivery

Ø      Access to the World Wide Web

There are two classes of protocol within the TCP/IP suite.

Ø      The network-level protocol

Ø      The application-level protoco1

Network-Level Protocols

Network-level protocols manage the discrete mechanics of data transfer. These protocols are typically invisible to the user and operate deep beneath the surface of the system. For example, the IP protocol provides packet delivery of the information sent between the user and remote machines. It does this based on a variety of information, most notably the IP address of the two machines. Based on this and other information, IP guarantees that the information will be routed to its intended destination. Throughout this process, IP interacts with other network-level protocols engaged in data transport. Short of using network utilities (perhaps a sniffer or other device that reads IP datagrams), the user will never see IP's work on the system.

Application-Level Protocols

Conversely, application-level protocols are visible to the user in some measure. For example, File Transfer Protocol (FTP) is visible to the user. The user requests a connection to another machine to transfer a file, the connection is established, and the transfer begins. During the transfer, a portion of the exchange between the user's machine and the remote machine is visible (primarily error messages and status reports on the transfer itself, for example, how many bytes of the file have been transferred at any given moment).

For the moment, this explanation will suffice: TCP/IP refers to a collection of protocols that facilitate communication between machines over the Internet (or other networks running TCP/IP).

The History of TCP/IP

In 1969, the Defense Advanced Research Projects Agency (DARPA) commissioned development of a network over which its research centers might communicate. Its chief concern was this network's capability to withstand a nuclear attack. In short, if the Soviet Union launched a nuclear attack, it was imperative that the network remain intact to facilitate communication. The design of this network had several other requisites, the most important of which was this: It had to operate independently of any centralized control. Thus, if 1 machine was destroyed (or 10, or 100), the network would remain unaffected.

The prototype for this system emerged quickly, based in part on research done in 1962 and 1963. That prototype was called ARPANET. ARPANET reportedly worked well, but was subject to periodic system crashes. Furthermore, long-term expansion of that network proved costly. A search was initiated for a more reliable set of protocols; that search ended in the mid-1970s with the development of TCP/IP.

TCP/IP had significant advantages over other protocols. For example, TCP/IP was lightweight (it required meager network resources). Moreover, TCP/IP could be implemented at much lower cost than the other choices then available. Based on these amenities, TCP/IP became exceedingly popular. In 1983, TCP/IP was integrated into release 4.2 of Berkeley Software Distribution (BSD) UNIX. Its integration into commercial forms of UNIX soon followed, and TCP/IP was established as the Internet standard.

Today, TCP/IP is used for many purposes, not just the Internet. For example, Intranets are often built using TCP/IP. In such environments, TCP/IP can offer significant advantages over other networking protocols. One such advantage is that TCP/IP works on a wide variety of hardware and operating systems. Thus, one can quickly and easily create a heterogeneous network using TCP/IP. Such a network might have UNIX, Windows, Macs, IBM compatibles, Sun SPARCstation, MIPS machines, and so on. Each of these can communicate with its peers using a common protocol suite. For this reason, since it was first introduced in the 1970s, TCP/IP has remained extremely popular.

What Platforms Support TCP/IP?

Most platforms support TCP/IP. However, the quality of that support can vary. Today, most mainstream operating systems have native TCP/IP support (that is, TCP/IP support that is built into the standard operating system distribution). However, older operating systems on some platforms lack such native support. The following table describes TCP/IP support for various platforms. If a platform has native TCP/IP support, it is labeled as such. If not, the name of a TCP/IP application is provided.

Platforms and their support for TCP/IP.

Platforms that do not natively support TCP/IP can still implement it through the use of proprietary or third-party TCP/IP programs. In these instances, third-party products can offer varied functionality. Some offer very good support and others offer marginal support.

The Individual Protocols

After examining how data is transmitted via TCP/IP using the protocol stack. Now I want to zoom in to identify the key protocols that operate within that stack. I will begin with network-level protocols.

Network-Level Protocols

Network protocols are those protocols that engage in (or facilitate) the transport process transparently. These are invisible to the user unless that user employs utilities to monitor system processes.

Important network-level protocols include

Ø      The Address Resolution Protocol (ARP)

Ø      The Internet Control Message Protocol (ICMP)

Ø      The Internet Protocol (IP)

Ø      The Transmission Control Protocol (TCP)

The Address Resolution Protocol

The Address Resolution Protocol (ARP) serves the critical purpose of mapping Internet addresses into physical addresses. This is vital in routing information across the Internet. Before a message (or other data) is sent, it is packaged into IP packets, or blocks of information suitably formatted for Internet transport. These contain the numeric Internet (IP) address of both the originating and destination machines. Before this package can leave the originating computer, however, the hardware address of the recipient (destination) must be discovered. (Hardware addresses differ from Internet addresses.) This is where ARP makes its debut.

An ARP request message is broadcast on the subnet. This request is received by a router that replies with the requested hardware address. This reply is caught by the originating machine and the transfer process can begin.

ARP's design includes a cache. To understand the ARP cache concept, consider this: Most modern HTML browsers (such as Netscape Navigator or Microsoft's Internet Explorer) utilize a cache. This cache is a portion of the disk (or memory) in which elements from often-visited Web pages are stored (such as buttons, headers, and common graphics). This is logical because when you return to those pages, these tidbits don't have to be reloaded from the remote machine. They will load much more quickly if they are in your local cache.

Similarly, ARP implementations include a cache. In this manner, hardware addresses of remote machines or networks are remembered, and this memory obviates the need to conduct subsequent ARP queries on them. This saves time and network resources.

Well, what type of security risks might be involved in maintaining such an ARP cache? At this stage, it is not particularly important. However, address caching (not only in ARP but in all instances) does indeed pose a unique security risk. If such address-location entries are stored, it makes it easier for a cracker to forge a connection from a remote machine, claiming to hail from one of the cached addresses.

The Internet Control Message Protocol

The Internet Control Message Protocol handles error and control messages that are passed between two (or more) computers or hosts during the transfer process. It allows those hosts to share that information. In this respect, ICMP is critical for diagnosis of network problems. Examples of diagnostic information gathered through ICMP include

Ø      When a host is down

Ø      When a gateway is congested or inoperable

Ø      Other failures on a network

The Internet Protocol

IP belongs to the network layer. The Internet Protocol provides packet delivery for all protocols within the TCP/IP suite. Thus, IP is the heart of the incredible process by which data traverses the Internet.

The Transmission Control Protocol

The Transmission Control Protocol is the chief protocol employed on the Internet. It facilitates such mission-critical tasks as file transfers and remote sessions. TCP accomplishes these tasks through a method called reliable data transfer. In this respect, TCP differs from other protocols within the suite. In unreliable delivery, you have no guarantee that the data will arrive in a perfect state. In contrast, TCP provides what is sometimes referred to as reliable stream delivery. This reliable stream delivery ensures that the data arrives in the same sequence and state in which it was sent.

The TCP system relies on a virtual circuit that is established between the requesting machine and its target. This circuit is opened via a three-part process, often referred to as the three-part handshake.

After the circuit is open, data can simultaneously travel in both directions. This results in what is sometimes called a full-duplex transmission path. Full-duplex transmission allows data to travel to both machines at the same time. In this way, while a file transfer (or other remote session) is underway, any errors that arise can be forwarded to the requesting machine.

TCP also provides extensive error-checking capabilities. For each block of data sent, a numeric value is generated. The two machines identify each transferred block using this numeric value. For each block successfully transferred, the receiving host sends a message to the sender that the transfer was clean. Conversely, if the transfer is unsuccessful, two things may occur:

Ø      The requesting machine receives error information.

Ø      The requesting machine receives nothing.

When an error is received, the data is retransmitted unless the error is fatal, in which case the transmission is usually halted. A typical example of a fatal error would be if the connection is dropped. Thus, the transfer is halted for no packets.

Similarly, if no confirmation is received within a specified time period, the information is also retransmitted. This process is repeated as many times as necessary to complete the transfer or remote session.

After examining how the data is transported when a connect request is made. It is now time to examine what happens when that request reaches its destination. Each time one machine requests a connection to another, it specifies a particular destination. In the general sense, this destination is expressed as the Internet (IP) address and the hardware address of the target machine. However, even more detailed than this, the requesting machine specifies the application it is trying to reach at the destination. This involves two elements:

Ø      A program called inetd

Ø      A system based on ports

inetd

Before exploring the inetd program, It is necessary to know about daemons. Which wil help to understand the inetd program.

Daemons are programs that continuously listen for other processes (in this case, the process listened for is a connection request). Daemons loosely resemble terminate and stay resident (TSR) programs in the Microsoft platform. These programs remain alive at all times, constantly listening for a particular event. When that event finally occurs, the TSR undertakes some action.

inetd is a very special daemon. It has been called many things. This is because inetd is the main daemon running on a UNIX machine. It is also an ingenious tool.

Common sense tells that running a dozen or more daemon processes could eat up machine resources. So rather than do that, why not create one daemon that could listen for all the others? That is what inetd does. It listens for connection requests from the void. When it receives such a request, it evaluates it. This evaluation seeks to determine one thing only: What service does the requesting machine want? For example, does it want FTP? If so, inetd starts the FTP server process. The FTP server can then process the request from the void. At that point, a file transfer can begin. This all happens within the space of a second or so.

In general, inetd is started at boot time and remains resident (in a listening state) until the machine is turned off or until the root operator expressly terminates that process.

The behavior of inetd is generally controlled from a file called inetd.conf, located in the /etc directory on most UNIX platforms. The inetd.conf file is used to specify what services will be called by inetd. Such services might include FTP, Telnet, SMTP, TFTP, Finger, Systat, Netstat, or any other processes that you specify.

The Ports

Many TCP/IP programs can be initiated over the Internet. Most of these are client/server oriented. As each connection request is received, inetd starts a server program, which then communicates with the requesting client machine.

To facilitate this process, each application (FTP or Telnet, for example) is assigned a unique address. This address is called a port. The application in question is bound to that particular port and, when any connection request is made to that port, the corresponding application is launched (inetd is the program that launches it).

There are thousands of ports on the average Internet server. For purposes of convenience and efficiency, a standard framework has been developed for port assignment. (In other words, although a system administrator can bind services to the ports of his or her choice, services are generally bound to recognize ports.)

Common ports and their corresponding services or applications.