Knowledge of the structure of Internet Protocol (IP) packets is a fundamental part of understanding the Internet and how information moves from one point to another. The benefits of such knowledge extend to virtually all networking disciplines, not the least of which is intrusion detection. Rules-based intrusion-detection mechanisms, for example, can flag packets as suspicious if their structure mimics that of a known malicious string. While this is happening, another rule might cause an action in response to a packet that has no conceivable reason to exist, as when both the SYN and RST flags are set. There are many ways to probe and attack from within a packet, and the problem only gets worse as a network gets larger. The shotgun approach of enabling all possible Intrusion Detection Systems (IDS) rules is sure to fail in most environments, particularly when busy, high-speed circuits threaten to overtax IDS deployments that must decode every packet on the wire. In IP networks, bit-level expertise cannot be overvalued when you are designing solutions or choosing the most appropriate defense technologies.
The topic of this chapter—the structure and functions of TCP/IP—is uniquely appropriate in any discussion of intrusion-detection techniques. This chapter begins with a clarification of key terms and concepts, and then it discusses the genesis of current reference models that were introduced in the early 1980s. Following that is a detailed examination of TCP/IP, and the final section describes modern networking.
Key Terms and Concepts
It is important to clarify certain key terms that this chapter uses. Readers who know the standards that are under review by more than one name will see them here as TCP/IP and the OSI Model, which represent Transmission Control Protocol over Internet Protocol and Open Systems Interconnection, respectively. Because all the popular terms are essentially correct, it is best to declare this common ground before the details are discussed.
When reading technical information or preparing for a network-analysis effort, it helps to have certain issues and concepts in mind. These items serve that purpose regarding TCP/IP and the OSI Model:
- All implementations are not created equal. Conforming to standards made by developers and manufacturers is practically voluntary.
- In nearly all real-world cases, the OSI Model nomenclature is used in documents and discussions, regardless of the technology.
- Although it can be made to work, communication between TCP/IP and the OSI Model systems can have undesirable effects, at least in the form of more difficult implementation.
Brief History of the Internet
The goal that was realized by the creation of this protocol mix, which is often called a “protocol stack,” is a means for open communication between disparate computers. The driving forces behind the Internet was the United States Department of Defense (DoD), specifically the Defense Advanced Research Projects Agency (DARPA), and two international organizations: the International Organization for Standardization (ISO) and the International Telecommunications Union (ITU).
DARPA began work on its network, ARPANET, in 1968, which went into full production in 1970. At the time, the protocol in use was the ARPANET Network Control Program (NCP) host-to-host protocol, and the first five nodes added belonged to Bolt, Beranek, and Newman (BBN); Stanford University; UCLA; UC Santa Barbara; and the University of Utah.
The number of nodes on ARPANET grew considerably over the next few years, which lead to various problems that were largely viewed as symptoms of technical limitations. In July 1980, the Office of the Secretary of Defense directed that a set of DoD standard protocols be used on all defense networks. The protocols have the following official designations:
- RFC 791, Internet Protocol
- RFC 793, Transmission Control Protocol
These are the most current RFC numbers and descriptions; the authoritative organization of the day was the Internet Configuration Control Board (ICCB), who designated the original releases as RFC 760, DoD Standard Internet Protocol and RFC 761, DoD Standard Transmission Control Protocol.
In the mid to late 1970s, the ITU and ISO were working independently to develop an open set of standards for network architectures. This presented significant challenges that DARPA did not encounter, which, by comparison, operated in a controlled environment. The ISO and ITU architects faced the daunting task of convincing equipment manufacturers to agree with each and every standard.
ISO and ITU established a positive vendor relationship with Honeywell Information Systems, which worked with the international teams. In 1984, the ITU and ISO teams merged their respective standards work into a single document, and much of the final product came from Honeywell engineers. The standards document was released under the umbrella name Open Systems Interconnection, which is now referred to as the OSI Reference Model (or simply the OSI Model). The cooperating international organizations designate the specification as follows:
- ITU-T, X-Series Recommendation X.200
- ISO 7498, Open Systems Interconnection, Basic Reference Model
The ARPANET transition to TCP/IP happened between October 1981 and October 1983. During this time, the protocols were intensely researched and scrutinized by their developers. The official release came on January 1, 1983, and the Internet was born. The headstart that was gained by the development period and 1983 release date is said to be the reason that TCP/IP is now the global standard for Internet communications. Now that you have an abridged knowledge of the history of the Internet it’s time to explore the OSI Model and TCP/IP.
Layered Protocols
Internet hosts communicate by using a special software mechanism called layers (or layered protocols). The OSI Model has seven layers, and TCP/IP has four.
Note - The depiction of layers might depend on which reference document is chosen as the authoritative model. Although most Internet Engineering Task Force (IETF) documents reference TCP/IP as having the four layers shown in Figure 1-1, RFC 1983, “Internet User’s Glossary,” lists the number of layers at five. Commercial documents also reflect this difference, but Cisco Systems, the current and long-standing leader in network technologies, teaches in CCENT/CCNA ICND1 Official Exam Certification Guide (Odom 2007) that TCP/IP has four layers.
Figure 1-1 makes it easy to understand why the world is comfortable with TCP/IP as the Internet standard protocol suite, but it still uses the OSI Model terms in documents and discussions. The end result is the same with both versions, but TCP/IP has an edge over the OSI Model in terms of simplicity. The Internet Society can divide TCP/IP into two areas of responsibility in support of developers and users: The lower three layers (link, Internet, and transport) are the communication layers, which focus on networking requirements, and the application layer covers host software. On the other hand, the OSI Model gives the technical community a clear set of terms for communication between humans. A minor point is the fact that many readers interpret Figure 1-1 to be based on “incorrect” names. For example, the link layer is also known as the access layer and media access layer.
Figure 1-1TCP/IP and OSI Model comparison
As previously mentioned, OSI Model nomenclature is used in nearly all discussions and documents, even though TCP/IP is the Internet standard. Figure 1-1 shows that TCP/IP is at Layer 2 if the counting starts at the bottom and moves up; however, because it is functionally the same as the OSI Model network layer, referring to it as a Layer 3 protocol causes no problems.
Industry technical parlance involves specific names for data units in the context of the TCP/IP and OSI Model layers. For the data link layer, the term is frames, the network layer term is packets, and the transport layer term is segments. In the broader context of the Internet, a unit of data is called a datagram (or an IP datagram). This is a case of TCP/IP terminology being applied to the OSI Model layers, but it is technically accurate. Architects of the OSI Model devised a more elegant way to describe data chunks. OSI Model documents use the term Protocol Data Unit (PDU) for all units of data and, as a differentiator between layers, it simply uses the layer number as a prefix to PDU. As such, a TCP/IP Ethernet frame is an OSI Model Layer 2 PDU. Note that the word datagram is sometimes used interchangeably with PDU or packet in RFCs and commercial documents. Table 1-1 lists the TCP/IP and OSI Model layers and functions.
Table 1-1 OSI Model Layers
Consider an analogy of what is required for a personal computer in Redmond, Washington, to converse with a mainframe computer in Armonk, New York:
Disregarding that this analogy is fiction, the conversation became easier because traffic cops along the route did not spend time meeting all the same requirements. All they needed was physical connectivity, a common language for communication, and a list of recipient addresses that they could share.
The casual analogy of two computers that need to talk as people do describes a seven-layer communication model. Reality departs from such an analogy, mostly because of these details:
- Same-layer interaction. The layered networking model has a peer-to-peer interaction between equal layers on different computers.
- Adjacent-layer interaction. Layered networking involves an interaction between adjacent layers on the same computer.
The same-layer interaction is how each layer communicates its intended action to its peer on the receiving end of a connection. Adjacent-layer interaction involves attaching a PDU to a protocol header as it moves through the layers, which is a process called encapsulation. As its name implies, a header is at the front of the transmitted data and is the first thing that the receiving host interprets. It contains source and destination addresses, and it can include error checking or other fields. Figure 1-2 and Figure 1-3 show same-layer and adjacent-layer communications.
Figure 1-2OSI Model same-layer and adjacent-layer interactions
Figure 1-3TCP/IP same-layer and adjacent-layer interactions
An example using TCP/IP hosts shows how layered protocols enable communication. Assume that a host application program needs to send data to another host that is several hops away. Figure 1-4 illustrates the following steps:
~~
TCP/IP Protocol Suite
Specifications in RFC 1122, “Requirements for Internet Hosts—Communication Layers,” state that Internet hosts must implement at least one protocol from each layer of the TCP/IP protocol suite. In light of the fact that the link, Internet, and transport layer protocols must be operational for an implementation to work, it might appear as though the IETF is “requiring the obvious.” Additional details clarify the requirement by distinguishing two categories of application layer protocols: user protocols that provide services to users, and support protocols that enable common system functions. RFC authors explain that the most common examples of each are as follows:
- Application layer user protocols. Telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).
- Application layer support protocols. Simple Network Management Protocol (SNMP), BOOTP, Reverse Address Resolution Protocol (RARP), and Domain Name System (DNS).
Tables 1-2 through 1-5 offer brief definitions of these protocols and others that are widely used today. To be consistent with typical industry language, OSI Model terms describe the layers at which each protocol operates.
Table 1-2 Application Layer Protocols
Table 1-3 Session Layer Protocols
Table 1-4 Transport Layer Protocols
Table 1-5 Internet Layer Protocols
Although developers have latitude for implementing the TCP/IP protocol suite, there are some stringent requirements to consider. A good example is the robustness principle, which stresses that software is written in such a way that it deals with every conceivable error condition. The principle also involves performance in a network-friendly manner and drives the point home with specific verbiage, such as “be liberal in what you accept and conservative in what you send.”
To clarify, for applications that do not require reliable transport services, UDP is available. This is called a UDP/IP application, and it is distinct from TCP/IP.
The nuts and bolts of protocol operations exist as fields within the bit-level structure of each data unit, whether it is a frame, segment, or packet. According to the layered protocol discussion so far, those particular units, or chunks, of data will at some point exist within the same logical structure. The concept was described at a high level in the layered communications example earlier in this chapter (specifically at Step 4). At that point, application data and an application layer header—if required, an attribute that is unique to the application—were encapsulated inside an Ethernet header and trailer along with transport and Internet layer headers. The role of a TCP/IP protocol header is to convey information to the other layers and to its peer of the same protocol at the other end of the path. (This is the adjacent-layer and same-layer interactions, respectively.) Figure 1-5 shows application data encapsulated as an Ethernet frame, an IP packet, and a TCP segment.
