TCP/IP Illustrated Episode 7

Designing Applications

The network concepts we have touched upon so far provide a fairly simple service model [RFC6250]: moving bytes between programs running on different (or, occasionally, the same) computers. To do anything useful with this capability, we need networked applications that use the network for providing services or performing computations. Networked applications are typically structured according to a small number of design patterns. The most common of these are client/server and peer-to-peer.

Standardization Process

Newcomers to the TCP/IP suite often wonder just who is responsible for specifying and standardizing the various protocols and how they operate. A number of organizations represent the answer to this question. The group with which we will most often be concerned is the Internet Engineering Task Force (IETF) [RFC4677]. This group meets three times each year in various locations around the world to develop, discuss, and agree on standards for the Internet’s “core” protocols. Exactly what constitutes “core” is subject to some debate, but common protocols such as IPv4, IPv6, TCP, UDP, and DNS are clearly in the purview of IETF. Attendance at IETF meetings is open to anyone, but it is not free.

IETF is a forum that elects leadership groups called the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG).The IAB is chartered to provide architectural guidance to activities in IETF and to perform a number of other tasks such as appointing liaisons to other standards-defining organizations (SDOs). The IESG has decision-making authority regarding the creation and approval of new standards, along with modifications to existing standards. The “heavy lifting” or detailed work is generally performed by IETF working groups that are coordinated by working group chairs who volunteer for this task.

Request for Comments (RFC)

Every official standard in the Internet community is published as a Request for Comments, or RFC. RFCs can be created in a number of ways, and the publisher of RFCs (called the RFC editor) recognizes multiple document streams corresponding to the way an RFC has been developed. The current streams (as of 2010) include the IETF, IAB, IRTF, and independent submission streams. Prior to being accepted and published (permanently) as an RFC, documents exist as temporary Internet drafts while they receive comments and progress through the editing and review process.

All RFCs are not standards. Only so-called standards-track category RFCs are considered to be official standards. Other categories include best current practice (BCP), informational, experimental, and historic. It is important to realize that just because a document is an RFC does not mean that the IETF has endorsed it as any form of standard. Indeed, there exist RFCs on which there is significant disagreement.

Implementations and Software Distributions

The historical de facto standard TCP/IP implementations were from the Computer Systems Research Group (CSRG) at the University of California, Berkeley. They were distributed with the 4.x BSD (Berkeley Software Distribution) system and with the BSD Networking Releases until the mid-1990s. This source code has been the starting point for many other implementations. Today, each popular operating system has its own implementation. In this text, we tend to draw examples from the TCP/IP implementations in Linux, Windows, and sometimes FreeBSD and Mac OS (both of which are derived from historical BSD releases). In most cases, the particular implementation matters little.

By the mid-1990s, the Internet and TCP/IP were well established. All subsequent popular operating systems support TCP/IP natively. Research and development of new TCP/IP features, previously found first in BSD releases, are now typically found first in Linux releases. Windows has recently implemented a new TCP/IP stack (starting with Windows Vista) with many new features and native IPv6 capability. Linux, FreeBSD, and Mac OS X also support IPv6 without setting any special configuration options.

Attacks Involving the Internet Architecture

Spoofing can be combined with a variety of other attacks seen periodically on the Internet. Denial-of-service (DoS) attacks usually involve using so much of some important resource that legitimate users are denied service. For example, sending so many IP datagrams to a server that it spends all of its time just processing the incoming packets and performing no other useful work is a type of DoS attack. Other DoS attacks may involve clogging the network with so much traffic that no other packets can be sent. This is often accomplished by using many sending computers, forming a distributed DoS (DDoS) attack.

Unauthorized access attacks involve accessing information or resources in an unauthorized fashion. This can be accomplished with a variety of techniques such as exploiting protocol implementation bugs to take control of a system (called 0wning the system and turning it into a zombie or bot). It can also involve various forms of masquerading such as an attacker’s agent impersonating a legitimate user (e.g., by running with the user’s credentials). Some of the more pernicious attacks involve taking control of many remote systems using malicious software (malware) and using them in a coordinated, distributed fashion (called botnets). Programmers who intentionally develop malware and exploit systems for (illegal) profit or other malicious purposes are generally called black hats. So-called white hats do the same sorts of technical things but notify vulnerable parties instead of exploit them.