Chapter 4

Section: Part II:  Security Concepts

Chapter 4. A Brief Primer on TCP/IP


        what Is TCP/IP?

        How Does TCP/IP Work?

        The Individual Protocols

        IPsec, IPv6, VPNs, and Looking Ahead

In this chapter, you learn about various protocols (or methods of data transport) used on the Internet, including Transmission Control Protocol (TCP) and Internet Protocol (IP). This chapter is not an exhaustive treatment of TCP/IP. Instead, it is intended to ensure that you have enough understanding of TCP/IP to get maximum benefit out of the chapters that follow. Throughout this chapter, links are provided to other documents and resources from which you can find more comprehensive information on TCP/IP.


Section: Chapter 4.  A Brief Primer on TCP/IP

What Is TCP/IP?

TCP/IP refers to two network protocols used on the Internet: Transmission Control Protocol and Internet Protocol. However, TCP and IP are only two protocols belonging to a much larger collection of protocols called the TCP/IP suite.

The TCP/IP suite of networking protocols connects various operating systems and network components. It provides a standard method for moving data between systems, and is used both on the Internet as well as in the world of private networking.

Protocols within the TCP/IP suite provide data transport for all services available to today's network user. Some of those services include

        Transmission of electronic mail

        File transfers

        Instant messaging

        Access to the World Wide Web

The Open Systems Interconnection (OSI) Reference Model

The OSI Reference Model was defined to standardize discussion of various technologies involved in networking. Its seven layers represent the architecture for data communication protocols. Each layer in the OSI model specifies a particular network function. The OSI model can be thought of as a stack with each layer lying on the one below it. The services that a given layer performs are defined by the protocols at that layer. Understanding the OSI model and each layer is very helpful in conceptualizing how the different parts of TCP/IP networks and applications interact. The seven layers of the OSI model stack are

        Layer 7 (Application). The highest layer of the OSI model. This layer defines the way applications interact with the network and between systems.

        Layer 6 (Presentation). Contains protocols that are part of the operating system. This layer defines how information is formatted for display. Data encryption and translation can occur at this layer.

        Layer 5 (Session). Coordinates communication between endpoints. Session state is maintained at this layer for security, logging, and administrative functions.

        Layer 4 (Transport). Controls the flow of data between systems, defines the structure of data in messages, and performs error checking. Web browser encryption commonly occurs at this layer.

        Layer 3 (Network). Defines protocols for routing data between systems. This is the layer where endpoint addressing occurs; it makes sure that data arrives at the correct destination.

        Layer 2 (Data-link or Network interface). Defines the rules for sending and receiving information from one node to another in local network environments (that is, LANs).

        Layer 1 (Physical or Media). Governs hardware connections and byte-stream encoding for transmission. It is the only layer that involves a physical transfer of information between network nodes.

TCP/IP was created prior to the development of the OSI reference model, and, although TCP/IP fits within the OSI architecture, not all OSI layers are relevant when talking about TCP/IP. With respect to TCP/IP, the most important OSI layers are the application, transport, network, and data-link. Each of these layers has specific protocols associated with them, which we'll examine in detail later in this chapter. Common protocols at these layers are

        Application: Hypertext Transfer Protocol (HTTP)

        Transport: Transmission Control Protocol (TCP)

        Network: Internet Protocol (IP)

        Data-link: Address Resolution Protocol (ARP)

These protocols can be divided into two types, network and application (see Figure 4.1):

Figure 4.1. OSI and IP protocol stacks.


Network-Level Protocols

Network-level protocols manage the mechanics of data transfer, and are typically invisible to the end user. For example, the Internet Protocol (IP) provides packet delivery of information sent between the user and remote machines. It does this based on a variety of data, most notably the IP address of the two machines. Based on the IP address and other information, IP provides a "best-effort" service to route the information 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 network.

Application-Level Protocols

Unlike network-level protocols, application-level protocols are visible to the user. For example, Hypertext Transfer Protocol (HTTP) is an interactive protocol; you see the results of your connection and transfer as it's happening. (That information is presented in error messages and status reports on the transfer for example, the number of bytes that have been transferred at any given moment).

The History of TCP/IP

In 1969, the Defense Advanced Research Projects Agency (DARPA) commissioned development of a network for its research centers. The chief concern was this network's capability to withstand a nuclear attack. If the Soviet Union launched a first strike, the network still had 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. The prototype for this system (called ARPANET) was based in large part on research done in 1962 and 1963.

The original ARPANET worked well but was subject to periodic system crashes. Furthermore, long-term expansion of that network proved costly. A search was therefore initiated for a more reliable set of protocols; that search ended in the mid-1970s with the development of TCP/IP.

TCP/IP had two chief advantages over other protocols: It was lightweight and could be implemented at lower cost than the other choices then available. Based on these factors, TCP/IP became exceedingly popular. By 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. It has remained so to this day. (For more on the history of the Internet, see Appendix B, "Internet 101." )

Today, TCP/IP is used for many purposes, not just for Internet communication. For example, intranets are often built using TCP/IP. In such environments, TCP/IP can offer significant advantages over other networking protocols. For example, TCP/IP works on a wide variety of hardware and operating systems. Using TCP/IP, one can quickly and easily create a heterogeneous network that links Macs, IBM compatibles, Mainframes, Sun UNIX servers, MIPS machines, and so on. Each of these can communicate with its peers using a common protocol suite. For this reason, TCP/IP has remained extremely popular since its introduction.

The RFCs

The protocols of TCP/IP suite are usually defined by documents called Requests For Comments (RFCs). The RFC approval process is managed by the Internet Engineering Steering Group (IESG) based on recommendations from the Internet Engineering Task Force (IETF). RFCs can be composed and submitted by anyone. In addition, RFCs are unlike many other networking standards in that they are freely available online and are open to comment by anyone.

For complete information about The Internet Standards Process, see c/files/rfc2026.txt.

The IETF is primarily responsible for forming working groups focused on strategic TCP/IP issues. Standards RFCs are often the product of many months of discussion within these working groups, which are made up of people interested in a particular aspect of the Internet. The working groups often draft proposed RFCs and make them available for discussion. These discussions typically take place on mailing lists, which welcome input from any interested party. Not all RFCs specify TCP/IP standards. Some RFCs contain background information, some provide documentation and tips for managing a TCP/IP network, some document protocol weaknesses, and some are even completely humorous. The core RFCs that define the standards associated with TCP/IP networking are

        RFC 768: User Datagram Protocol

        RFC 791: Internet Protocol

        RFC 792: Internet Control Message Protocol

        RFC 793: Transmission Control Protocol

        RFC 1122: Requirements for Internet Hosts Communication Layers

        RFC 1123: Requirements for Internet Hosts Application and Support.

For more complete information about Internet protocols and associated RFCs, visit an RFC archive such as that provided by the IETF at

Implementations of TCP/IP

The de facto standard for TCP/IP implementations has been the 4.x BSD releases, and its code has been the starting point for many other implementations. There are numerous implementations available including a number of BSD derivatives such as FreeBSD, OpenBSD, and NetBSD. In addition, the UNIX-like operating system GNU/Linux includes source code for a TCP/IP implementation. Source code for non-UNIX implementations is also available. Packages for MS-DOS and Windows include WATTCP/WATT-32 and KA9Q.


Section: Chapter 4.  A Brief Primer on TCP/IP

How Does TCP/IP Work?

As with the OSI model, TCP/IP operates through the use of a protocol stack. This stack is the sum total of all protocols necessary to transfer data between two machines, as shown in Figure 4.2. (It is also the path that data takes to get out of one machine and into another.)

Figure 4.2. The TCP/IP protocol stack.


After data passes through the stack, it travels to its destination on another machine or network. There, the process is executed in reverse. (The data first meets the physical layer and subsequently travels its way up the stack.) Throughout this process, a system of error checking is employed both on the originating machine and the destination machine.

Each stack layer can send data to and receive data from its neighbor. Each layer is also associated with multiple protocols. At each tier of the stack, these protocols provide the user with various services. When two applications are communicating over a network, data passes from one application to the other by moving down the stack from the application on the transmitting system and back up the stack of the receiving system to the application running there. As information moves down the stack, information is added to the packet in the form of a header. This header information is like an envelope in which the previous layer's information is wrapped. As the packet goes up the stack, the header is processed and removed before that packet is passed on to the next layer (much like a person opening an envelope to read the letter inside).


Section: Chapter 4.  A Brief Primer on TCP/IP

The Individual Protocols

Data is transmitted via TCP/IP using the protocol stack. In each layer of the TCP/IP stack, individual protocols provide certain network services. These protocols can be categorized as network-level or application-level, with many individual protocols existing in each level.

Network-Level Protocols

Network-level protocols facilitate the data transport process transparently. They are invisible to the end user unless that user employs utilities to monitor system processes.


Sniffers are devices that can monitor network processes. A sniffer is a device either hardware or software that can read every packet sent across a network. Sniffers are commonly used to isolate network problems that, although invisible to the end user, are degrading net work performance. As such, sniffers can read all activity occurring between network-level protocols. Moreover, sniffers can pose a tremendous security threat. You will examine sniffers in Chapter 15, "Sniffers."


Important TCP/IP network-level protocols include the following:

        Address Resolution Protocol (ARP)

        Internet Control Message Protocol (ICMP)

        Internet Protocol (IP)

        Transmission Control Protocol (TCP)

        User Datagram Protocol (UDP)

We will briefly examine each, ascending up the stack from the data-link layer to the transport layer.

For more comprehensive information about protocols (or the stack in general), see TCP/IP Illustrated, Volume 1 by W. Richard Stevens (Addison Wesley, ISBN # 0-201-63346-9).

The Address Resolution Protocol (ARP)

The Address Resolution Protocol (ARP) serves the critical purpose of mapping Internet addresses into hardware addresses and translating the network layer address (or IP address) to the data-link address. This is vital in routing information between hosts on a local network, and out onto 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, network IP address of both the originating and destination machines. What remains is to determine the hardware, or the data-link address of the destination machine. This is where ARP makes its entrance.

An ARP request message is broadcast on a local network. If the destination IP address is active on the local network, the destination host will reply with its own hardware address. The originating machine receives this reply, and the transfer process can begin.

For those readers seeking in-depth information on ARP, see RFC 826 at

The Internet Control Message Protocol (ICMP)

The Internet Control Message Protocol provides error and control messages that are passed between two (or more) computers or hosts. It enables those hosts to share the information. In this respect, ICMP is critical for diagnosis of network problems. ICMP provides helpful messages, such as the following:

        Echo and reply messages to test for network availability

        Redirect messages to enable more efficient routing

        Time-exceeded messages to inform sources that a packet has exceeded its allocated time within the network

An ICMP packet can be of several types. The two most common are the ICMP_ECHO_REQUEST and ICMP_ECHO_REPLY. These packets are used to test network connectivity to make sure a host or network component is active and reachable.


Perhaps the most widely known ICMP implementation involves a network utility called ping. Ping is often used to determine whether a remote machine is alive. Ping's method of operation is simple: When the user pings a remote machine, a series of ICMP_ECHO_REQUEST packets are forwarded from the user's machine to the remote host. The remote host replies with ICMP_ ECHO_REPLY packets. If no reply packets are received at the user's end, the ping program usually generates an error message, indicating that the remote host is down or unreachable.


In-depth information about ICMP can be found in RFC 792 at

The Internet Protocol (IP)

The Internet Protocol provides packet delivery for all protocols within the TCP/IP suite. Thus, IP is the heart of the process by which data traverses the Internet. The IP datagram, or packet, is the vehicle for transmission of data on TCP/IP networks. The structure of an IP datagram is shown in Figure 4.3.

Figure 4.3. The IP datagram.


An IP datagram is composed of several parts. The first part, the header, is composed of important network information, including source and destination IP addresses. Together, these elements form a complete header. The remaining portion of a datagram contains whatever data is then being sent.

One of the important aspects of IP networking is that it can be used to transmit data using a number of protocols (that is, TCP, UDP, and so on). Each protocol serves a particular function; we'll be looking at some important ones soon. In addition, IP enables the fragmentation and reassembly of data. At the data-link layer, networks can only transmit data in discrete chunks up to a specific size, called the Maximum Transmission Unit (MTU). If the data you want to transmit is larger than the MTU that a network can transmit, the data must be broken into pieces smaller than the MTU, transmitted, and then put back together at the other end. IP provides a mechanism for fragmenting the data, tracking it, and reassembling it. Fragmentation is also important from a security perspective. In some cases, it can be manipulated to work around security measures if security isn't implemented carefully.

An IP datagram also contains a time-to-live (TTL) field. A numeric value, the TTL is decremented as the IP datagram traverses the network. When that value finally reaches zero, the datagram is discarded. This ensures that the network doesn't become clogged with datagrams that can't find their destination in a timely fashion. Many other types of packets have time-to-live limitations, and some network utilities (such as Traceroute) use the time-to-live field as a marker in diagnostic routines.

IP Network Addressing

The IP address is a unique identifier for a system on the network. It is 32 bits long and is usually represented as 4 numbers, each a byte, separated by decimal points, for example, Each byte, or octet, in an IP address can range from 0 to 255. This representation of an IP address is called dotted-decimal notation and is the most common humanly readable format for working with IP addresses.

A contiguous range of IP addresses defines an IP network. This range of IP addresses is denoted by the combination of an IP address and network mask (or netmask). A netmask is a 32-bit value like an IP address, which, when combined with the IP address, defines address boundaries of the IP network. This requires conversion of the IP address and netmask to binary format and their combination using binary arithmetic. Note that the first address in a contiguous range of IP addresses indicates the network address. The last address in the contiguous range denotes the network broadcast address.

The network layer in TCP/IP is usually considered to be unicast. This is in contrast to the data-link layer, where ARP operates in a broadcast mode. Unicast indicates that IP communications occur between two endpoints in a point-to-point fashion. However, an IP datagram can be addressed to the network broadcast address. This causes the IP datagram to be received and responded to by all nodes on the IP network. Several network based denial of service attacks take advantage of this broadcast capability in IP.

In-depth information on the Internet Protocol can be found in RFC 760 at

The Transmission Control Protocol (TCP)

The Transmission Control Protocol (TCP) is one of the main protocols employed on the Internet. Working at the transport level in the stack, it facilitates such mission-critical tasks as file transfers and remote sessions. TCP accomplishes these tasks through a method called reliable communication. In this respect, TCP is more reliable than other protocols within the suite because it includes mechanisms for sequencing and acknowledgment of data transmission.

As with IP, TCP has its own packet structure (see Figure 4.4), composed of source port and destination port numbers that identify services. In addition, important parts of a TCP packet are the sequence number, flags, and checksum. The sequence number tracks a TCP connection and the order in which data is sent. The flags control the connection state, whether it is being established, in use, or being closed. There are six flags that can be used in combination to describe the state of a TCP connection. The most important for this analysis are SYN, ACK, and FIN. The checksum in the TCP packet ensures that the data has not been corrupted during transmission.

Figure 4.4. TCP packet structure.


The TCP system relies on a virtual circuit between the requesting machine (client) and its target (server). This circuit is opened via a three-part process, often referred to as the three-way handshake. The process typically follows the pattern illustrated in Figure 4.5.

Figure 4.5. Establishment of TCP connection.


To establish a TCP connection, the three-way handshake must be completed as follows:

1.       The client sends a TCP SYN packet to the server that it wants to establish a connection with. This is a TCP packet with only the SYN flag active. The packet also contains an initial sequence number (ISN) that will be used to track the connection.

2.       The server responds with a TCP SYN packet with its own ISN. The server also acknowledges the client's TCP SYN by setting the ACK flag on this packet and using the client's ISN plus 1 as the acknowledgement number.

3.       The client acknowledges the server's TCP SYN with a TCP ACK using the server's ISN plus 1.

No data is exchanged during this process, but, when it is completed, a connection is available for data transfer between the client and server. This connection provides a full-duplex transmission path. Full-duplex transmission enables 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 checksum is calculated, and the sequence number is incremented. The two machines identify each transferred block using the sequence number. For each block successfully transferred, the receiving host sends an ACK message to the sender that the transfer was clean. Conversely, if the transfer is unsuccessful, one of two things might 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 was dropped.

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.

TCP Connection Termination

As you might expect, because TCP provides a protocol for establishing a connection, it also provides a protocol for terminating a connection. Establishing a TCP connection takes three steps, whereas terminating one takes four steps. Because a TCP connection is bi-directional or full-duplex, transmission in both directions of the connection must be shut down separately. This is done by using the TCP FIN packet, much as the TCP SYN packet is used to create a connection. When a client is finished using a connection, it will issue a TCP FIN packet to the server. The server responds with a TCP ACK to acknowledge that the connection is closing. Because the connection is bi-directional, the server will also issue a TCP FIN to the client. The client will then acknowledge the server's TCP FIN, thus completing the TCP connection termination process.

In-depth information about TCP can be found in RFC 793 at

User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) is a simple, connectionless transport layer protocol. In fact, it is so simple that the RFC that defines it is only three pages long. Unlike TCP, UDP provides no reliability, and, because it is connectionless, it doesn't have any mechanism for connection establishment or termination. It does provide data integrity checks via a checksum. Although it might seem that UDP is inferior to TCP, it is, in fact, much better for certain applications because it has very low overhead.

In-depth information about UDP can be found in RFC 768 at

Application Level Protocols The Ports

Each time a machine requests services from another, it specifies a particular destination and transport method. The destination is expressed as the Internet (IP) address of the target machine, and the transport method is the transport protocol (that is, TCP or UDP). Further, the requesting machine specifies the application it is trying to reach at the destination by using a system of ports.

Just as machines on the Internet have unique IP addresses, each application (FTP or Telnet, for example) is assigned a unique address called a port. The port defines the type of service that is being requested or provided. The application in question is bound to that particular port, and, when any connection request is made to that port, the corresponding server application responds.

There are thousands of ports on the average Internet server, although often, most will not be active. For purposes of convenience and efficiency, a standard framework has been developed for port assignments. (In other words, although a system administrator can assign services to the ports of his choice, services are generally assigned to recognized ports commonly referred to as well-known ports.) Table 4.1 shows some commonly recognized ports and the applications typically bound to them.

Table 4.1. Common Ports and Their Corresponding Services or Applications

Service or Application


Hypertext Transfer Protocol (HTTP)

TCP port 80

Domain Name System (DNS)

UDP and TCP port 53


TCP port 23

File Transfer Protocol (FTP)

TCP port 20 and 21

Simple Mail Transfer Protocol (SMTP)

TCP port 25

Secure Shell (SSH)

TCP port 22

Each of the ports described in Table 4.1 are assigned to application-level protocols or services that is, they are visible to the user, and the user can interact with them. We will examine each of these applications in the following sections.

For a comprehensive list of all port assignments, visit This document is extremely informative and exhaustive in its treatment of commonly assigned port numbers.

Hypertext Transfer Protocol (HTTP)

Hypertext Transfer Protocol (HTTP) is perhaps the most renowned protocol of all because it enables users to surf the World Wide Web. Stated briefly in RFC 1945, HTTP is

an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, enabling systems to be built independently of the data being transferred.

RFC 1945 has been superseded by RFC 2068, which is available at RFC 2068 is a more recent specification of HTTP.

HTTP has forever changed the nature of the Internet, primarily by bringing the Internet to the masses. Using a common browser such as Netscape Navigator or Microsoft Internet Explorer, you can monitor the process of HTTP as it occurs. Depending upon the version of HTTP the server supports, your browser will contact the server for each data element (text, graphic, sound) on a WWW page. Thus, it will first grab text, then a graphic, then a sound file, and so on. In the lower-left corner of your browser's screen is a status bar. Watch it for a few moments while it is loading a page. You will see this request/response activity occur, often at a very high speed.

HTTP typically runs on port 80 using TCP. HTTP does little to protect the confidentiality of data because documents are transmitted without encryption. Some security can be added by using HTTPS, which is HTTP transmitted over Secure Sockets Layer (SSL). HTTPS typically runs on port 443 using TCP.

Domain Name System (DNS)

The Domain Name System (DNS) provides services that translate host names to IP addresses and back again. Much as Address Resolution Protocol provides a mechanism for translating addresses between the data-link and network layers (hardware address to IP address), DNS translates addresses between the network layer and the application layer (IP address to hostnames). Because IP addresses aren't exactly human friendly, the Domain Name System was developed to allow people to use human-friendly naming for systems. For example, when you enter into your Web browser, the name needs to be translated from that friendly format into an IP address that can be used by the network layer.

DNS has two modes of operation. The first mode is primarily for communications to clients that need names resolved to addresses. Because this is a small, easy task, transport for this mode is provided by UDP. DNS servers also must transfer large blocks of DNS records so that the workload and administration involved with resolving names to and from IP addresses can be distributed. These larger transfers (called DNS zone transfers) occur via TCP.

DNS is a very active area of discussion, and numerous Internet drafts and RFCs have been created to add functionality and security to DNS.

The core RFCs for DNS are 1034 and 1035. You can find them at and

All modern operating systems that run TCP/IP come with a DNS client (called a resolver) as part of the OS. A client program that enables a user to query DNS directly is often included. On UNIX and Microsoft Windows NT or 2000, the program nslookup is provided. This DNS client lets you interactively connect to a DNS server and perform various queries of the DNS data.

The most widely used DNS server is the Berkeley Internet Name Domain (BIND) DNS server. Developed and supported by the Internet Software Consortium, BIND is available for most UNIX systems as well as for Microsoft Windows NT. DNS typically runs on port 53 using UDP and TCP.


Telnet is best described in RFC 854, the Telnet protocol specification:

The purpose of the Telnet protocol is to provide a fairly general, bi-directional, eight-bit byte-oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other.

Telnet not only enables the user to log in to a remote host, it also lets that user execute commands on the host. Thus, an individual in Los Angeles can telnet to a machine in New York and begin running programs on the New York machine just as though she were in New York.

For those of you who are unfamiliar with Telnet, it operates much like the interface of a bulletin board system (BBS). Telnet is an excellent application for providing a terminal-based front-end to databases. For example, many university library catalogs can be accessed via Telnet or tn3270 (a variation that emulates an IBM 3270 terminal). Figure 4.6 shows an example of a Telnet library catalog screen.

Figure 4.6. A sample Telnet session.


Even though GUI applications have taken the world by storm, Telnet which is essentially a text-based application is still incredibly popular. Telnet enables you to perform a variety of functions (retrieving mail, for example) at a minimal cost in network resources.

To use Telnet, the user issues whatever command necessary to start his Telnet client, followed by the name (or numeric IP address) of the target host. In UNIX, this is done as follows:

% telnet

This command launches a Telnet session, contacts, and requests a TCP connection on port 23. That connection request will either be honored or denied, depending on the configuration at the target host. In UNIX, the telnet command has long been a native one. In addition, Telnet has been included with Microsoft Windows distributions for more than a decade.

Telnet is a simple protocol, and offers very little in the way of security. All data transmitted during a Telnet session, including the login ID and password, are sent unencrypted. Anyone with access to a sniffer and the network between the client and server could capture critical data including your password.

Secure Shell (examined later in this chapter) provides services similar to Telnet, but adds security by encrypting the data between client and server.

Telnet typically runs on port 23 via TCP.

File Transfer Protocol (FTP)

File Transfer Protocol (FTP) is a standard method of transferring files from one system to another. Its purpose is set forth in RFC 0765 as follows:

The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among Hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.

For more than two decades, researchers have investigated a wide variety of file-transfer methods. The development of FTP has undergone many changes in that time. Its first definition occurred in April 1971, and the full specification can be read in RFC 114.

RFC 114 contains the first definition of FTP, but a more practical document might be RFC 959, found at

Mechanical Operation of FTP

File transfers using FTP can be accomplished using any suitable FTP client. Table 4.2 defines some common FTP clients, by operating system.

Table 4.2. FTP Clients for Various Operating Systems

Operating System



Native, LLNLXDIR2.0, FTPtool, NCFTP

Microsoft Windows 95/98

Native, WS_FTP, Netload, Cute-FTP, Leap FTP, SDFTP, FTP Explorer

Microsoft Windows NT/2000

See listings for Windows 95/98

Microsoft Windows 3.x



Anarchie, Fetch, Freetp


Gibbon FTP, FTP-IT, Lynn's Workplace FTP

FTP file transfers occur in a client/server environment. The requesting machine starts one of the clients named in Table 4.2. This generates a request that is forwarded to the targeted FTP server (usually a host on another network). Typically, the request is sent by the client to port 21. For a connection to be established, the targeted file server must be running an FTP server.

FTPD: An FTP Server Daemon

FTPD is the standard FTP server daemon for UNIX. Its function is simple: to reply to connect requests received and to satisfy those requests for file transfers. An FTP daemon comes standard on most distributions of UNIX (for other operating systems, see Table 4.3).

Table 4.3. FTP Servers for Various Operating Systems

Operating System



Native (FTPD), WUFTD

Microsoft Windows 95/98

WFTPD, Microsoft FrontPage, WAR FTP Daemon, Vermilion

Microsoft Windows NT/2000

Serv-U, OmniFSPD, Microsoft Internet Information Server

Microsoft Windows 3.x

WinQVT, Serv-U, Beames & Whitside BW Connect, WFTPD FTP Server, WinHTTPD


Netpresenz, FTPd



FTPD waits for a connection request. When such a request is received, FTPD requests the user login. The user must either provide her valid user login and password or log in anonymously (if the server allows anonymous sessions).

When logged in, the user can download files. In certain instances and if security on the server allows, the user can also upload files.

As with Telnet, FTP is an insecure protocol. It does nothing to encrypt the user ID, password, or any of the files being transferred. Secure Shell provides a more secure method of file transfer via either Secure Copy (SCP) or Secure FTP (SFTP).

FTP uses ports 20 and 21 via TCP.

Simple Mail Transfer Protocol (SMTP)

SMTP is the protocol responsible for email transmission between servers, and the sending of email from clients to servers. Its purpose is stated concisely in RFC 821:

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.

SMTP is an extremely lightweight protocol. Running any SMTP-compliant client, the user sends a request to an SMTP server. The client forwards a series of instructions, indicating that it wants to send mail to a recipient somewhere on the Internet. If the SMTP allows this operation, an affirmative acknowledgment is sent back to the client machine. At that point, the session begins. The client might then forward the recipient's identity, his IP address, and the message (in text) to be sent.

Despite the simple character of SMTP, mail service has been the source of countless security holes. The configuration of an SMTP server can be complex, depending upon the options an administrator needs to support. A combination of SMTP server application bugs, and difficulty in configuration have led to numerous security holes. These security issues are covered in detail later in this book.

Most networked operating systems have SMTP servers available for use. STMP server support is included as sendmail for most UNIX distributions, or part of Internet Information Services for Microsoft Windows.

SMTP typically runs on port 25 via TCP.

Further information on SMTP is available in RFC 821

Secure Shell Protocol (SSH)

SSH is relatively new to the TCP/IP suite of protocols. Unlike the application protocols we've examined already, SSH has been widely implemented without completing the RFC process. This is largely because of the vast demand for a more secure method of providing services similar to Telnet and FTP.

There are two versions of the SSH protocol, and a number of implementations. The first widely used version of the protocol was SSH1, which was defined in an Internet draft (a pre-RFC document) in 1995. As of this writing, there is an Internet Engineering Task Force working group developing the second generation of SSH. Based upon that group's Internet drafts, a number of SSH2 implementations have been completed.

Information on the IETF SSH working group, along with the latest Internet drafts, can be found at

SSH allows you to log in to another computer over a network, to execute commands in a remote machine (like Telnet), and to move files from one machine to another (like FTP). It provides for strong authentication and secure, encrypted communications over otherwise insecure networks. It is intended as a replacement for Telnet and other remote access protocols like rlogin, rsh, and rcp. In SSH2, there is a replacement for FTP as well, called sftp.

Secure Shell client implementations exist for a variety of platforms, as shown in Table 4.4.

Table 4.4. SSH Clients for Various Operating Systems

Operating System



SSH Communications, F-Secure, OpenSSH, Lsh, MindTerm

Microsoft Windows 95/98

SSH Communications, F-Secure, PuTTY, TeraTerm, FiSSH, SecureCRT, Cygwin32, MindTerm

Microsoft Windows NT/2000

Same as 95/98


F-Secure, NiftyTelnet 1.1 SSH, MindTerm



Secure Shell server implementations are also available, although not on as many platforms as for clients (see Table 4.5).

Table 4.5. SSH Servers for Various Operating Systems

Operating System



SSH Communications, F-Secure, OpenSSH, Lsh

Microsoft Windows 95/98

SSH Communications, F-Secure, Cygwin32

Microsoft Windows NT/2000

Same as 95/98


Section: Chapter 4.  A Brief Primer on TCP/IP

IPsec, IPv6, VPNs, and Looking Ahead

The Internet Protocol discussed in this chapter is version 4. It was developed many years ago and, although it has delivered amazing potential and growth, it really wasn't designed to provide many of the services that we expect from the Internet today. Some of the limitations of IP version 4 (IPv4) that need to be addressed are

        Limitations on IPv4 addressing. Because of the explosive growth of the Internet, there is a critical shortage of available IP addresses. As the Internet continues to grow and more devices become Internet enabled, there will be an increased demand for new IP addresses.

        Lack of prioritization in IPv4. There is currently no method to prioritize particular kinds of traffic on the Internet. For example, a packet stream that provides real-time audio or video gets the same priority as a packet containing an email message. If packets are a few seconds late delivering real-time audio or video, it is very noticeable. If a few packets arrive later for a non real-time service such as email, no one will notice.

        Lack of security in IPv4. The current version of IP doesn't provide for authentication or the privacy of data transmitted.

Actions have been taken over the past few years to address these issues. The lack of available IPv4 addresses has been temporarily alleviated through the use of address translation techniques, but this will only suffice for a time before addresses are completely used up. In addition, address translation is known to break certain protocols that expect valid, non-changing IP addresses on datagrams.

Prioritization technologies are available for use with IPv4, but are limited to use in local networks. These technologies will not work in the Internet environment, where a central authority is not available to manage the flow of data.

Finally, security needs to be added to the Internet if we expect to be able transmit confidential data (that is, bank accounts, medical records, personal data, and so on), and expect that no one will break into our home and business systems connected to the Internet.

A great deal of effort has been put forth in the area of IPv4 security. IP Security (IPsec) has been developed to offer security services at the IP layer. IPsec provides methods for authentication and encryption of data at the network layer, but they are not universally available. IPsec can be used today to establish Virtual Private Networks (VPNs), which are logical private networks created over the Internet. However, these extensions are not normally available to the average Internet user. In addition, the successes of IPsec extensions do not yet address some of the more unusual aspects of IPv4, such as address translation.

Information on IP security can be found in RFC 2401 at You can also visit the IP security working group's Web site at

Fortunately, planning has been going on for quite some time to develop the next generation of the Internet Protocol. Enter Internet Protocol version 6 (IPv6)! IPv6 has been a very active area of discussion at the Internet Engineering Task Force, and has generated numerous RFCs over the past few years as planning for the next phase of Internet growth and services continues.

IPv6 promises to alleviate the limitation on IP addresses, add proper flow control and data prioritization, and provide security at the network layer. In addition, Ipv6 will provide nice services such as auto-configuration of networked systems, simplification of datagrams, improved performance, and greater capability for expansion. However, IPv6 is not currently widely deployed, and it will most likely be a few more years before the IPv6 standards are solidified. It will be several years beyond that when Internet providers base their services upon IPv6.

Information on IP version 6 (sometimes called IPng for "next generation") can be found in RFC 2460 ( and by visiting the IP version 6 working group's Web site,


Section: Chapter 4.  A Brief Primer on TCP/IP


TCP/IP makes up the Internet itself. It is a complex collection of hundreds of protocols, and many more are being developed each year. Many of the primary protocols in use on the Internet have been found to have one or more security problems.

In this chapter, you learned about these relevant points about the TCP/IP protocol suite:

        The TCP/IP suite contains all protocols necessary to facilitate data transfer over the Internet.

        The TCP/IP suite provides quick, reliable networking without consuming heavy network resources.

        TCP/IP is implemented on almost all computing platforms.

        Security is lacking in TCP/IP version 4.

Now that you know a little bit about TCP/IP, let's move ahead to a more exciting subject: hackers and crackers.


Enterprises - Maximum Security
We Only Played Home Games: Wacky, Raunchy, Humorous Stories of Sports and Other Events in Michigans
ISBN: 0000053155
EAN: 2147483647
Year: 2001
Pages: 38 © 2008-2017.
If you may any questions please contact us: