This chapter and Chapter 2 discuss the communication protocols that became a set of rules or standards designed to enable these stations to connect with one another and to exchange information. The protocol generally accepted for standardizing overall computer communications is a seven-layer set of hardware and software guidelines known as the Open Systems Interconnection (OSI) model. Before one can accurately define, implement, and test (hack into) security policies, it is imperative to have a solid understanding of these protocols. These chapters will cover the foundation of rules as they pertain to TCP/IP, ARP, UDP, ICMP, IPX, SPX, NetBIOS, and NetBEUI.
A Brief History of the Internet
During the 1960s, the U.S. Department of Defense's Advanced Research Projects Agency (ARPA, later called DARPA) began an experimental wide area network (WAN) that spanned the United States. Called ARPANET, its original goal was to enable government affiliations, educational institutions, and research laboratories to share computing resources and to collaborate via file sharing and electronic mail. It didn't take long, however, for DARPA to realize the advantages of ARPANET and the possibilities of providing these network links across the world.
By the 1970s, DARPA continued aggressively funding and conducting research on ARPANET, to motivate the development of the framework for a community of networking technologies. The result of this framework was the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. (A protocol is basically defined as a set of rules for communication over a computer network.) To increase acceptance of the use of protocols, DARPA disclosed a less expensive implementation of this project to the computing community. The University of California at Berkeley's Berkeley Software Design (BSD) UNIX system was a primary target for this experiment. DARPA funded a company called Bolt Beranek and Newman, Inc. (BBN) to help develop the TCP/IP suite on BSD
UNIX.
This new technology came about during a time when many establishments were in the process of developing local area network technologies to connect two or more computers on a common site. By January 1983, all of the computers connected on ARPANET were running the new TCP/IP suite for communications. In 1989, Conseil Europeen pour la Recherche Nucleaire (CERN), Europe's high-energy physics laboratory, invented the World Wide Web (WWW). CERN's primary objective for this development was to give physicists around the globe the means to communicate more efficiently using hypertext. At that time, hypertext only included document text with command tags, which were enclosed in
At the time, there were approximately 50 Web servers providing archives for viewable HTML. Nine months later, the number had grown to more than 500. Approximately one year later, there were more than 10,000 Web servers in 84 countries comprising the World Wide Web, all running on ARPANET's backbone called the Internet.
Today, the Internet provides a means of collaboration for millions of hosts across the world. The current backbone infrastructure of the Internet can carry a volume well over 45 megabits per second (Mb), about one thousand times the bandwidth of the original ARPANET. (Bandwidth is a measure of the amount of traffic a media can handle at one time. In digital communication, this describes the amount of data that can be transmitted over a communication line at bits per second, commonly abbreviated as bps.)
Internet Protocol
The Internet Protocol (IP) part of the TCP/IP suite is a four-layer model (see Figure 1.1). IP s designed to interconnect networks to form an Internet to pass data back and forth. IP contains addressing and control information that enables packets to be routed through this Internet. (A packet is defined as a logical grouping of information, which includes a header containing control information and, usually, user data.) The equipment—that is, routers—that encounter these packets, strip off and examine the headers that contain the sensitive routing information. These headers are modified and reformulated as a packet to be passed along.
Hackers Packet headers contain control information (route specifications) and user data. This Not*1** information can be copied, modified, and/or spoofed (masqueraded) by hackers.
One of the IP's primary functions is to provide a permanently established connection (termed connectionless), unreliable, best-effort delivery of datagrams through an Internetwork. Datagrams can be described as a logical grouping of information sent as a network layer unit over a communication medium. IP datagrams are the primary information units in the Internet. Another of IP's principal responsibilities is the fragmentation and reassembly of datagrams to support links with different transmission sizes.
During an analysis session, or sniffer capture, it is necessary to differentiate between different types of packet captures. The following describes the IP packet and the 14 fields therein, as illustrated in Figure 1.2.
Version. The IP version currently used.
IP Header Length (Length). The datagram header length in 32-bit words.
Type-of-Service (ToS). How the upper-layer protocol (the layer immediately above, such as transport protocols like TCP and UDP) intends to handle the current datagram and assign a level of importance.
Total Length. The length, in bytes, of the entire IP packet.
Identification. An integer used to help piece together datagram fragments.
Flag. A 3-bit field, where the first bit specifies whether the packet can be fragmented. The second bit indicates whether the packet is the last fragment in a series. The final bit is not used at this time.
Fragment Offset. The location of the fragment's data, relative to the opening data in the original datagram. This allows for proper reconstruction of the original datagram.
Time-to-Live (TTL). A counter that decrements to zero to keep packets from endlessly looping. At the zero mark, the packet is dropped.
Protocol. Indicates the upper-layer protocol receiving the incoming packets.
Header Checksum. Ensures the integrity of the IP header.
Source Address/Destination Address. The sending and receiving nodes (station, server, and/or router).
Options. Typically, contains security options.
• Data. Upper- layer information.
Key fields to note include the Source Address, Destination Address, Options, and
Data.
Now let's look at actual sniffer snapshots of IP Headers in Figures 1.3a and 1.3b to compare with the fields in the previous figure.
IP Header —
IP
IP
Version ■ 4, header length ■ 20 bytes
IP
Type of service
=
00
rr
000
u
routine
IP
. . .0
=
normal delay
IP
0. . .
=
noraal throughput
IP
0.
=
nomal rel iabi 1 i ty
IP
Total length
=
60 bytes
IP
Identif ication
=
S9136
IP
Flags
=
OX
IP
.0
□
may fragment
IP
.0
=
last fragment
TP
Fragment offset
=
0 bytes
IP
Time to live
=
3 2 seconds/hops
IP
Prot ocol
1 (ICMF)
IP
Header checksum
0 3 7Ј (correct)
IP
Source address
= [172.29.44.14]
ip
IP
Ho options
Figure 1.3a Extracted during the transmission of an Internet Control Message Protocol (ICMP) ping test (ICMP is explained later in this chapter).
IP Header
IP
IF
Version = 4, header length = 2 0 bytes
IP
Type ot service =
00
IF
000 =
routine
IP
. . .0 ■
normal delay
IP
.... 0 ... -
normal throughput
IF
0., ■
normal reliability
IF
Total length
112 bytes
IF
Identification ■
1964
IP
Flags
4S
IF
.1 -
don't fragment
IP
. . 0 -
last fragment
IF
Fragment offset =
0 bytes
IP
Time to live =
32 seconds:/hops
IF
Protocol =
6 (TCP)
IF
Header eheeksun =
FA8F (correct)
IP
Source address
= [10.55.28.117]
IF
Destination address ■ [10.55,23.22]
IP
Ho options
Figure 1.3b Extracted during the transmission of a NetBIOS User Datagram Protocol (UDP) session request (these protocols are described later in this chapter and in Chapter 2).
IP Datagrams, Encapsulation, Size, and Fragmentation
IP datagrams are the very basic, or fundamental, transfer unit of the Internet. An IP datagram is the unit of data commuted between IP modules. IP datagrams have headers with fields that provide routing information used by infrastructure equipment such as routers (see Figure 1.4).
Be aware that the data in a packet is not really a concern for the IP. Instead, IP is concerned with the control information as it pertains to the upper-layer protocol. This information is stored in the IP header, which tries to deliver the datagram to its destination on the local network or over the Internet. To understand this relationship, think of IP as the method and the datagram as the means.
The IP header is the primary field for gathering information, as well as for gaining control.
It is important to understand the methods a datagram uses to travel across networks. To sufficiently travel across the Internet, over physical media, we want some guarantee that each datagram travels in a physical frame. The process of a datagram traveling across media in a frame is called encapsulation.
Now, let's take a look at an actual traveling datagram scenario to further explain these traveling datagram methods (see Figure 1.5). This example includes corporate connectivity between three branch offices, over the Internet, linking Ethernet, Token Ring, and FDDI (Fiber Distributed Data Interface) or fiber redundant Token Ring networks.
An ideal situation is one where an entire IP datagram fits into a frame; and the network it is traveling across supports that particular transfer size. But as we all know ideal situations are rare. One problem with our traveling datagram is that networks enforce a maximum transfer unit (MTU) size, or limit, on the size of transfer. To further confuse the issue, different types of networks enforce their own MTU; for example, Ethernet has an MTU of 1500, FDDI uses 4470 MTU, and so on. When datagrams traveling in frames cross network types with different specified size limits, routers must sometimes divide the datagram to accommodate a smaller MTU. This process is called fragmentation.
Hacker's Routers provide the fragmentation process of datagrams, and as such, become Note1*' vulnerable to passive and intrusive attacks.
IP Addresses, Classes, Subnet Masks
Communicating on the Internet would be almost impossible if a system of unique addressing were not used. To prevent the use of duplicate addresses, routing between nodes is based on addresses assigned from a pool of classes, or range of available addresses, from the InterNetwork Information Center (InterNIC). InterNIC assigns and controls all network addresses used over the Internet by assigning addresses in three classes (A, B, and C), which consist of 32-bit numbers. By default, the usable bits for Classes A, B, and C are 8, 16, and 24 respectively. Addresses from this pool have been assigned and utilized since the 1970s, and they include the ranges shown in Figure 1.6; an example of an IP address is shown in Figure 1.7.
First Ociftt
I
NIC Assigned CHass C: 2060-1250
holworh Host
Figure 1.7 IP address example with four octets.
The first octet (206) indicates a Class C (Internet-assigned) IP address range with the format Network.Network.Network.Host with a standard mask binary indicating 255.255.255.0. This means that we have 8 bits in the last octet for hosts. The 8 bits that make up the last, or fourth, octet are understood by infrastructure equipment such as routers and software in the following manner:
Bit: 1 2 3 4 5 6 7 8
Value: 128 64 32 16 8 4 2 1 = 255 (254 usable hosts)
In this example of a full Class C, we only have 254 usable IP addresses for hosts; 0 and 255 cannot be used as host addresses because the network number is 0 and the broadcast address is 255.
With the abundant utilization of Class B address space and the flooding of requested Class C addresses, a Classless Interdomain Routing (CIR) system was introduced in the early 1990s. Basically, a route is no longer an IP address; a route is now an IP address and mask, allowing us to break a network into subnets and supernets. This also drastically reduces the size of Internet routing tables.
It is important to understand IP address masking and subnetting for performing a Note1*' security analysis, penetration hacking, and spoofing. There's more information on these topics later in this chapter.
Subnetting, VLSM, and Unraveling IP the Easy Way
Subnetting is the process of dividing an assigned or derived address class into smaller, individual, but related, physical networks. Variable-length subnet masking (VLSM) is the broadcasting of subnet information through routing protocols (covered in the next chapter). A subnet mask is a 32-bit number that determines the network split of IP addresses on the bit level.
Let's take a look at a real-world scenario of allocating IP addresses for a routed network (Figure 1.8).
Given: 206.0.125.0 (NIC assigned Class C). In this scenario, we need to divide our Class C address block to accommodate three usable subnets (for offices A, B, and C) and two subnets for future growth. Each subnet or network must have at least 25 available node addresses. This process can be divided into five steps.
Step 1
Four host addresses will be required for each of the office's router interfaces: Router 1 Ethernet 0, Router 2 Ethernet 0/Ethernet 1, and Router 3 Token Ring 0 (see Figure 1.9).
Step 2
Subnetting Calculator found on the CD for quick calculations. It is important to understand this process when searching for all possible hosts on a network during a discovery analysis.
Bfts In Subnet Mjsk
Subnet Mjsk
= ol Subnets
M ol Hosts Pei Subnet
2
25G.255 2SS.192
2
S2
3
255.2 55.255.2 24
6
30
4
255.255.255.2JO
14
]i
5
255 255 255 243
30
E
6
255.255.255.252
62
2
Figure 1.10 Class C subnet chart by number of subnets versus number of hosts per subnet.
• Bits in Subnet Mask: Keeping in mind the information given earlier, let's further explore the subnet mask bit breakdown. When a bit is used, we indicate this with a 1:
3 Bits: 1 1 1
Value: 128 64 32 16 8 4 2 1 When a bit is not used, we indicate this with a 0:
Подпись: 0 0 0 0 4 23 Bits:
Value: 128 64 32 16 8
1
SUBNET MASK
3 Bits: 1 1
0 0 0 0
Value: 128 64 32 16 8
0 1
0 1
Value: 128+ 64+ 32 = 224 (mask = 255.255.255.224)
Number of Subnets: Remember, in this scenario we need to divide our Class C address block to accommodate three usable subnets (for offices A, B, and C) and two subnets for future growth with at least 25 available node addresses per each of the five networks.
To make this process as simple as possible, let's start with the smaller number—that is, 5 for the required subnets or networks, as opposed to 25 for the available nodes needed per network. To solve for the required subnets in Figure 1.9), we'll start with the following equation, where we'll solve for n in 2n - 2, being sure to cover the required five subnets or networks.
• Let's start with the power of 2 and work our way up: 22 - 2 = 2 23 - 2 = 6 24 - 2 = 14
The (3rd power) in the equation indicates the number of bits in the subnet mask. Here we see that 23 - 2 = 6 subnets if we use these 3 bits. This will cover the required five subnets with an additional subnet (or network) left over.
Number of Hosts per Subnet: Now let's determine the number of bits left over for available host addresses. In this scenario, we will be using 3 bits in the mask for subnetting. How many are left over?
Out of the given 32 bits that make up IP addresses, the default availability (for networks versus hosts), as previously explained, for Classes A, B, and C blocks are as follows:
Class A: 8 bits
Class B: 16 bits Class C: 24 bits
Our scenario involves a Class C block assigned by InterNIC. If we subtract our default bit availability for Class C of 24 bits (as shown) from the standard 32 bits that make up IP addresses, we have 8 bits remaining for networks versus hosts for Class C blocks.
Next, we subtract our 3 bits used for subnetting from the total 8 bits remaining for network versus hosts, which gives us 5 bits left for actual host addressing:
3 Bits: 1 1 1 0 0 0 0 0 Value: 128 64 32 (16 8 4 2 1)
5 bits left
Let's solve an equation to see if 5 bits are enough to cover the required available node addresses of at least 25 per subnet or network:
25 - 2 = 30
Placing the remaining 5 bits back into our equation gives us the available node addresses per subnet or network, 25 - 2 = 30 host addresses per six subnets or networks (remember, we have an additional subnet left over).
From these steps, we can divide our Class C block using 3 bits to give us six subnets with 30 host addresses each.
Step 3
Now that we have determined the subnet mask, in this case 255.255.255.224 (3 bits), we need to calculate the actual network numbers or range of IP addresses in each network.
An easy way to accomplish this is by setting the host bits to 0. Remember, we have 5 bits left for hosts:
3 Bits: 1 1 1 0 0 0 0
Value: 128 64 32 (16 8 4 2
With the 5 host bits set to 0, we set the first 3 bits to 1 in every variation, then calculate the value (for a shortcut, take the first subnet value=32 and add it in succession to reveal all six subnets):
Step 4
Now that we have solved the network numbers, let's resolve each network's broadcast address by setting host bits to all 1s. The broadcast address is defined as the system that copies and delivers a single packet to all addresses on the network. All hosts attached to a network can be notified by sending a packet to a common address known as the broadcast address:
3 Bits:
0
0
1
1
1
1
1
Value:
128
64
32
(16
8
4
2
1)
32+
16+
8+
4+
2+
1
= 63
3 Bits:
0
1
0
1
1
1
1
Value:
128
64
32
(16
8
4
2
1)
64
+16
+8
+4
+2
+1
= 95
3 Bits:
0
1
1
1
1
1
1
Value:
128
64
32
(16
8
4
2
1)
64+
32+
16+
8+
4+
2+
1
= 127
3 Bits:
1
0
0
1
1
1
1
Value:
128
64
32
(16
8
4
2
1)
128+
16+
8+
4+
2+
1
= 159
3 Bits:
1
0
1
1
1
1
1
Value:
128
64
32
(16
8
4
2
1)
128+
32+
16+
8+
4+
2+
1
= 191
3 Bits:
1
1
0
1
1
1
1
Value:
128
64
32
(16
8
4
2
1)
128+
64+
16+
8+
4+
2+
1
= 223
Let's take a look at the network broadcast addresses of our subnetted Class C block with mask
255.255.255.224:
206.0.125.63 206.0.125.95 206.0.125.127
206.0.125.159 206.0.125.191 206.0.125.223 Step 5
So what are the available IP addresses for each of our six networks anyway? They are the addresses between the network and broadcast addresses for each subnet or network (see Figure 1.11).
n elwoi k AH dr ess
Bioadcast Address
Valid ip Addiess Range
206,0.125.32
206.0.12S.63
::t 3 125 33 2OG0 12562
206.0.125.64
206.0.125-95
206.0.125.65 - 206.0.125.9J
206.0.125 96
206.0.125.127
206 0.125.97-206.0.125.126
206.0.125.128
206.0.125.159
206.0.125.123-206.0.125.153
2DS.0.125.160
2OG.0.125.191
206 0.12fi.161 - 206 0.125 190
206.0.125.192
206.0 125 223
206 0 125.193- 206 0.125 222
Figure 1.11 Available IP addresses for our networks. Unraveling IP with Shortcuts
Example 2
Now let's calculate the IP subnets, network, and broadcast addresses for another example:
Given: 07.247.60.0 (InterNIC-assigned Class C) 255.255.255.0. In this scenario, we need to divide our Class C address block to accommodate 10 usable subnets. Each subnet or network must have at least 10 available node addresses. This example requires four steps to complete.
Step 1
Number of Subnets: Remember, in this scenario we need to divide our Class C address block to accommodate 10 usable with at least 10 available node addresses per each of the 10 networks.
Let's start with the number 10 for the required subnets and the following equation, where we'll solve for n in 2n - 2, being sure to cover the required 10 subnets or networks.
We'll begin with the power of 2 and work our way up:
22 - 2 = 2 23 - 2 = 6 24 - 2 = 14
In this equation, the (4 th power) indicates the number of bits in the subnet mask. Note that 24 - 2 = 14 subnets if we use these 4 bits. This will cover the required 10 subnets, and leave four additional subnets (or networks).
SUBNET MASK
4 Bits: 1 1 1 1 0 0 0 0 Value: 128 64 32 16 8 4 2 1 Value: 128+ 64+ 32+ 16 =240 (mask = 255.255.255.240)
Number of Hosts per Subnet: Now we'll determine the number of bits left over for available host addresses. In this scenario, we will be using 4 bits in the mask for subnetting. How many are left over?
Remember, out of the given 32 bits that make up IP addresses, the default availability (for networks versus hosts), as previously explained, for Classes A, B, and C blocks is as follows:
Class A: 8 bits
Class B: 16 bits Class C: 24 bits
Our scenario involves a Class C block assigned by InterNIC. If we subtract our default bit availability for Class C of 24 bits (as shown) from the standard 32 bits that make up IP addresses, we have 8 bits remaining for networks versus hosts for Class C blocks.
Next, we subtract the 4 bits used for subnetting from the total 8 bits remaining for network versus hosts, which gives us 4 bits left for actual host addressing:
4 Bits: 1 1 1 1 0 0 0 0
Value: 128 64 32 16 (8 4 2 1)
4 bits left
Let's solve an equation to determine whether 4 bits are enough to cover the required available node addresses of at least 10 per subnet or network: 24 - 2 = 14
Placing the remaining 4 bits back into our equation gives us the available node addresses per subnet or network: 24 - 2 = 14 host addresses per 14 subnets or networks (remember, we have four additional subnets left over).
From these steps, we can divide our Class C block using 4 bits to give us 14 subnets with 14 host addresses each.
Step 2
Now that we have determined the subnet mask, in this case 255.255.255.240 (4 bits), we need to calculate the actual network numbers or range of IP addresses in each network. An easy way to accomplish this is by setting the host bits to 0. Remember, we have 4 bits left for hosts:
4 Bits:
1
1
1
1
0
0
0 0
Value:
128
64
32
16
(8
4
2 1)
4 host bits left
ith the 4
host bits set to 0,
we set
the first 4 bits to 1
in every variation, then calculate the value:
4 Bits:
0
0
0
1
0
0
0
0
Value:
128
64
32
16
(8
4
2
1)
16
= 16
4 Bits:
0
0
1
0
0
0
0
0
Value:
128
64
32
16
(8
4
2
1)
32
= 32
and so on to reveal our 14 subnets or networks. Recall the shortcut in the first example; we can take our first value (=16) and add it in succession to equate to 14 networks:
Step 3
Now that we have solved the network numbers, let's resolve each network's broadcast address. This step is easy. Remember, the broadcast address is the last address in a network before the next network address; therefore:
FIRST NETWORK SECOND NETWORK
207.247.60.16 (.31) 207.247.60.32 (.47) 207.247.60.48 (.63)
207.247.60.64 (.79)
SECOND BROADCAST
Step 4
So what are the available IP addresses for each network? The answer is right in the middle of step 3. Keep in mind, the available IP addresses for each network fall between the network and broadcast addresses:
FIRST NETWORK SECOND NETWORK
207.247.60.16 (.31) 207.247.60.32 (.47) 207.247.60.48
FIRST BROADCAST SECOND BROADCAST
(Network 1 addresses: .17 - .30) (Network 2 addresses: .33 - .46)
ARP/RARP Engineering: Introduction to Physical Hardware Address Mapping
Now that we have unearthed IP addresses and their 32-bit addresses, packet/datagram flow and subnetting, we need to discover how a host station or infrastructure equipment, such as a router, match an IP address to a physical hardware address. This section explains the mapping process that makes communication possible. Every interface, or network interface card (NIC), in a station, server, or infrastructure equipment has a unique physical address that is programmed by and bound internally by the manufacturer.
One goal of infrastructure software is to communicate using an assigned IP or Internet address, while hiding the unique physical address of the hardware. Underneath all of this is the address mapping of the assigned address to the actual physical hardware address. To map these addresses, programmers use the Address Resolution Protocol (ARP).
Basically, ARP is a packet that is broadcasted to all hosts attached to a physical network. This packet contains the IP address of the node or station with which the sender wants to communicate. Other hosts on the network ignore this packet after storing a copy of the sender's IP/hardware address mapping. The target host, however, will reply with its hardware address, which will be returned to the sender, to be stored in its ARP response cache. In this way, communication between these two nodes can ensue (see Figure 1.12).
Hacker's The hardware address is usually hidden by software, and therefore can be defined as Nater*J the ultimate signature or calling card for an interface.
Figure 1.12 ARP resolution.
ARP Encapsulation and Header Formatting
It is important to know that ARP is not an Internet protocol; moreover, ARP does not leave the local logical network, and therefore does not need to be routed. Rather, ARP must be broadcasted, whereby it communicates with every host interface on the network, traveling from machine to machine encapsulated in Ethernet packets (in the data portion).
ARP is broadcasted to reach every interface on the network. These hosts can store Note1** this information to be used later for potential masquerading. See Chapter 8 for more information on spoofing.
Figure 1.13 An ARP/RARP packet.
Type of Hardware.
Type of Protocol.
Hardware Length. Protocol Length. Operation Field.
Specifies the target host's hardware interface type (1 for Ethernet).
The protocol type the sender has supplied (0800 for an IP address).
The length of the hardware address.
The length of the protocol address.
Specifies whether either an ARP request/response or RARP request/response.
ARP Sender's Hardware Address. Sender's hardware address.
ARP Sender's IP Address. Sender's IP address.
RARP Targets Hardware Target's hardware address.
Address.
RARP Targets IP Address. Target's IP address.
Keep in mind that ARP packets do not have a defined header format. The length fields shown in Figure 1.13 enable ARP to be implemented with other technologies.
RARP Transactions, Encapsulation
The Reverse Address Resolution Protocol (RARP), to some degree, is the opposite of ARP. Basically, RARP allows a station to broadcast its hardware address, expecting a server daemon to respond with an available IP address for the station to use. Diskless machines use RARP to obtain IP addresses from RARP servers.
It is important to know that RARP messages, like ARP, are encapsulated in Ethernet frames (see Figure 1.14, Excerpt from Figure 1.13). Likewise, RARP is broadcast from machine to machine, communicating with every host interface on the network.
The RARP Daemon (RARPd) is a service that responds to RARP requests. Diskless systems typically use RARP at boot time to discover their 32-bit IP address, given their 48-bit hardware Ethernet address. The booting machine sends its Ethernet address, encapsulated in a frame as a RARP request message. The server running RARPd must have the machine's name-to-IP-address entry, or it must be available from the Domain Name Server (DNS) with its name-to-Ethernet-address. With these sources available, the RARPd server maps this Ethernet address with the corresponding IP address.
Hacker's RARP, with ARP spoofing, gives a hacker the ability to passively request an IP Mate'* address and to passively partake in network communications, typically unnoticed by other nodes.
Transmission Control Protocol
IP has many weaknesses, one of which is unreliable packet delivery—packets may be dropped due to transmission errors, bad routes, and/or throughput degradation. The Transmission Control Protocol (TCP) helps reconcile these issues by providing reliable, stream-oriented connections. In fact,
TCP/IP is predominantly based on TCP functionality, which is based on IP, to make up the TCP/IP suite. These features describe a connection-oriented process of communication establishment.
There are many components that result in TCP's reliable service delivery. Following are some of the main points:
Streams. Data is systematized and transferred as a stream of bits, organized into 8-bit octets or bytes. As these bits are received, they are passed on in the same manner.
Buffer Flow Control. As data is passed in streams, protocol software may divide the stream to fill specific buffer sizes. TCP manages this process, and assures avoidance of a buffer overflow. During this process, fast-sending stations may be stopped periodically to keep up with slow-receiving stations.
Virtual Circuits. When one station requests communication with another, both stations inform their application programs, and agree to communicate. If the link or communications between these stations fail, both stations are made aware of the breakdown and inform their respective software applications. In this case, a coordinated retry is attempted.
Full Duplex Connectivity. Stream transfer occurs in both directions, simultaneously, to reduce overall network traffic.
Sending Station
Receiving Station
Send firsl 4 bytes.
Receive lirst A bytes
/ SandACK=5
Receive ACK=5 *
Send next 4 bytes
>> Receive nexl 4 bytes
Send ACK=9
Figure 1.15 TCP windowing example. Sequencing and Windowing
TCP organizes and counts bytes in the data stream using a 32-bit sequence number. Every TCP packet contains a starting sequence number (first byte) and an acknowledgment number (last byte). A concept known as a sliding window is implemented to make stream transmissions more efficient. The sliding window uses bandwidth more effectively, because it will allow the transmission of multiple packets before an acknowledgment is required.
Figure 1.15 is a real-world example of the TCP sliding window. In this example, a sender has bytes to send in sequence (1 to 8) to a receiving station with a window size of 4. The sending station places the first 4 bytes in a window and sends them, then waits for an acknowledgment (ACK=5). This acknowledgment specifies that the first 4 bytes were received. Then, assuming its window size is still 4 and that it is also waiting for the next byte (byte 5), the sending station moves the sliding window 4 bytes to the right, and sends bytes 5 to 8. Upon receiving these bytes, the receiving station sends an acknowledgment (ACK=9), indicating it is waiting for byte 9. And the process continues.
At any point, the receiver may indicate a window size of 0, in which case the sender will not send any more bytes until the window size is greater. A typical cause for this occurring is a buffer overflow.
TCP Packet Format and Header Snapshots
Keeping in mind that it is important to differentiate between captured packets—whether they are TCP, UDP, ARP, and so on—take a look at the TCP packet format in Figure 1.16, whose components are defined in the following list:
Source Port.
Destination Port.
Sequence Number.
Acknowledgment Number.
Data Offset.
Reserved. Flags.
Specifies the port at which the source processes send/receive TCP services.
Specifies the port at which the destination processes send/receive TCP services.
Specifies the first byte of data or a reserved sequence number for a future process.
The sequence number of the very next byte of data the sender should receive.
The number of 32-bit words in the header. Held for future use.
Control information, such as SYN, ACK, and FIN bits, for connection establishment and termination.
Window Size.
The sender's receive window or available buffer space.
Checksum. Specifies any damage to the header that occurred
during transmission.
Urgent Pointer. The optional first urgent byte in a packet, which indicates the end of urgent data.
Options. TCP options, such as the maximum TCP segment
size.
Data. Upper- layer information.
Now take a look at the snapshot of a TCP header, shown in Figure 1.17a, and compare it with the fields shown in Figure 1.17b.
Ports, Endpoints, Connection Establishment
TCP enables simultaneous communication between different application programs on a single machine. TCP uses port numbers to distinguish each of the receiving station's destinations. A pair of endpoints identifies the connection between the two stations, as mentioned earlier. Colloquially, these endpoints are defined as the connection between the two stations' applications as they communicate; they are defined by TCP as a pair of integers in this format: (host, port). The host is the station's IP address, and port is the TCP port number on that station. An example of a station's endpoint is:
206.0.125.81:1026
(host)(port)
An example of two stations' endpoints during communication is:
STATION 1
206.0.125.81:1022 (host)(port)
STATION 2
207.63.129.2:26 (host)(port)
This technology is very important in TCP, as it allows simultaneous communications by assigning separate ports for each station connection.
When a connection is established between two nodes during a TCP session, a three-way handshake is used. This process starts with a one-node TCP request by a SYN/ACK bit, and the second node TCP response with a SYN/ACK bit. At this point, as described previously, communication between the two nodes will proceed. When there is no more data to send, a TCP node may send a FIN bit, indicating a close control signal. At this intersection, both nodes will close simultaneously. Some common and well-known TCP ports and their related connection services are shown in Table B.1 in Appendix B on page 793.
TCP header
TCP:
TCP:
Source part
80 (WW-HTTP)
TCP:
Destination port
■
1033
TCP:
Sequence number
135173
TCP:
Acknowledgment number
34406^5
TCP:
Data offset
20 bytes
TCP ■
Flags
10
TCP:
. . 0
-
(Ho urgent pointer)
TCP:
.1 ....
Acknowledgnen t
TCP:
. . , . 0...
(Ho push)
TCP:
0 . .
(Be reset)
TCP;
0
-
(Ho SYTf)
TCP:
0
(He FIH)
TCP:
Window
6389
TCP :
Checksum
-
9A4 8 (correct)
TCP:
Ho TCP options
TCP
E14&0 Bytes oi date]
Figure 1.17a Extracted from an HTTP Internet Web server transmission.
TCP header
TCP:
TCP:
Source port
1027
TCP
Destination port
::
4107
TCP:
Sequence number
2126033619
TCP:
Acknowledgment number
-
2666B94
TCP:
Data offset
=
20 bytes
TCP:
Flags
18
TCP
. .0
(Ho urgent pointer)
TCP:
. . .1
Acknowledgment
TCP:
1. . .
■
Push
TCP:
0
(Ho reset)
TCP
0 .
■
(Ho SYN)
TCP:
0
(Ho FIH)
TCP:
Window
16060
TCP:
Checksum
EF41 (correc t)
TCP:
Ho TCP options
TCP:
[224 Bytes of data]
Figure 1.17b Extracted from a sliding window sequence transmission.
User Datagram Protocol
The User Datagram Protocol (UDP) operates in a connectionless fashion; that is, it provides the same unreliable, datagram delivery service as IP. Unlike TCP, UDP does not send SYN/ACK bits to assure delivery and reliability of transmissions. Moreover, UDP does not
include flow control or error recovery functionality. Consequently, UDP messages can be lost, duplicated, or arrive in the wrong order. And because UDP contains smaller headers, it expends less network throughput than TCP and so can arrive faster than the receiving station can process them.
UDP is typically utilized where higher-layer protocols provide necessary error recovery and flow control. Popular server daemons that employ UDP include Network File System (NFS), Simple Network Management Protocol (SNMP), Trivial File Transfer Protocol (TFTP), and Domain Name System (DNS), to name a few.
UDP does not include flow control or error recovery, and can be easily duplicated.
UDP Formatting, Encapsulation, and Header Snapshots
UDP messages are called user datagrams. These datagrams are encapsulated in IP, including the UDP header and data, as it travels across the Internet. Basically, UDP adds a header to the data that a user sends, and passes it along to IP. The IP layer then adds a header to what it receives from UDP. Finally, the network interface layer inserts the datagram in a frame before sending it from one machine to another.
As just mentioned, UDP messages contain smaller headers and consume fewer overheads than TCP. The UDP datagram format is shown in Figure 1.18, and its components are defined in the following
list.
Source/Destination Port. A 16-bit UDP port number used for datagram processing.
Message Length. Specifies the number of octets in the UDP datagram.
Checksum. An optional field to verify datagram delivery.
Data. The data handed down to the TCP protocol, including upper-
layer headers.
UDP provides multiplexing (the method for multiple signals to be transmitted concurrently into an input stream, across a single physical channel) and demultiplexing (the actual separation of the streams that have been multiplexed into a common stream back into multiple output streams) between protocol and application software.
Multiplexing and demultiplexing, as they pertain to UDP, transpire through ports. Each station application must negotiate a port number before sending a UDP datagram. When UDP is on the receiving side of a datagram, it checks the header (destination port field) to determine whether it matches one of station's ports currently in use. If the port is in use by a listening application, the transmission proceeds; if the port is not in use, an ICMP error message is generated, and the datagram is discarded. A number of common UDP ports and their related connection services are listed in Table B.2 in Appendix B on page 795.
Internet Control Message Protocol
The Internet Control Message Protocol (ICMP) delivers message packets, reporting errors and other pertinent information to the sending station or source. Hosts and infrastructure equipment use this mechanism to communicate control and error information, as they pertain to IP packet processing.
ICMP Format, Encapsulation, and Delivery
ICMP message encapsulation is a two-fold process. The messages are encapsulated in IP datagrams, which are encapsulated in frames, as they travel across the Internet. Basically, ICMP uses the same unreliable means of communications as a datagram. This means that ICMP error messages may be lost or duplicated.
The ICMP format includes a message type field, indicating the type of message; a code field that includes detailed information about the type; and a checksum field, which provides the same functionality as IP's checksum (see Figure 1.20). When an ICMP message reports an error, it includes the header and data of the datagram that caused the specified problem. This helps the receiving station to understand which application and protocol sent the datagram. (The next section has more information on ICMP message types.)
Like UDP, ICMP does not include flow control or error recovery, and so can be easily duplicated.
Message Type
Description
0
Echo Reply
3
Destinalion Unreachable
A
Source Quench
5
Route Redirecl
a
Echo Request
H
Datagram Time Exceeded
12
Data gram Parameter Pratlern
13
Timestamp Requesl
14
Time stamp Reply
15
Information Re^uesl
16
Information RefVy
17
Address Mask Requesl
18
Address Mask Reply
Figure 1.21 ICMP message chart.
ICMP Messages, Subnet Mask Retrieval
There are many types of useful ICMP messages; Figure 1.21 contains a list of several, which are described in the following list.
• Echo Reply (Type 0)/Echo Request (Type 8). The basic mechanism for testing possible communication between two nodes. The receiving station, if available, is asked to reply to the ping. An example of a ping is as follows:
STEP 1: BEGIN ECHO REQUEST
Ping 206.0.125.81 (at the command prompt) STEP 2: BEGIN ECHO REPLY
Reply from 206.0.125.81: bytes-32 time<10ms TTL=128 (from receiving station 206.0.125.81)
Reply from 206.0.125.81: bytes-32 time<10ms TTL=128
Reply from 206.0.125.81: bytes-32 time<10ms TTL=128
Reply from 206.0.125.81: bytes-32 time<10ms TTL=128
Destination Unreachable (Type 3). There are several issuances for this message type, including when a router or gateway does not know how to reach the destination, when a protocol or application is not active, when a datagram specifies an unstable route, or when a router must fragment the size of a datagram and cannot because the Don't Fragment Flag is set. An example of a Type 3 message is as follows:
STEP 1: BEGIN ECHO REQUEST
Ping 206.0.125.81 (at the command prompt)
STEP 2: BEGIN ECHO REPLY
Pinging 206.0.125.81 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable. Destination host unreachable. Destination host unreachable.
Source Quench (Type 4). A basic form of flow control for datagram delivery. When datagrams arrive too quickly at a receiving station to process, the datagrams are discarded. During this process, for every datagram that has been dropped, an ICMP Type 4 message is passed along to the sending station. The Source Quench messages actually become requests, to slow down the rate at which datagrams are sent. On the flip side, Source Quench messages do not have a reverse effect, whereas the sending station will increase the rate of transmission.
Route Redirect (Type 5). Routing information is exchanged periodically to accommodate network changes and to keep routing tables up to date. When a router identifies a host that is using a nonoptional route, the router sends an ICMP Type 5 message while forwarding the datagram to the destination network. As a result, routers can send Type 5 messages only to hosts directly connected to their networks.
Datagram Time Exceeded (Type 11). A gateway or router will emit a Type 11 message if it is forced to drop a datagram because the TTL (Time-to-Live) field is set to 0. Basically, if the router detects the TTL=0 when intercepting a datagram, it is forced to discard that datagram and send an ICMP message Type 11.
Datagram Parameter Problem (Type 12). Specifies a problem with the datagram header that is impeding further processing. The datagram will be discarded, and a Type 12 message will be transmitted.
Timestamp Request (Type 13)/Timestamp Reply (Type 14). These provide a means for delay tabulation of the network. The sending station injects a send timestamp (the time the message was sent) and the receiving station will append a receive timestamp to compute an estimated delay time and assist in their internal clock synchronization.
Information Request (Type 15)/Information Reply (Type 16). As an alternative to RARP (described previously), stations use Type 15 and Type 16 to obtain an Internet address for a network to which they are attached. The sending station will emit the message, with the network portion of the Internet address, and wait for a response, with the host portion (its IP address) filled in.
• Address Mask Request (Type 17)/Address Mask Reply (Type 18). Similar to an Information Request/Reply, stations can send Type 17 and Type 18 messages to obtain the subnet mask of the network to which they are attached. Stations may submit this request to a known node, such as a gateway or router, or broadcast the request to the network.
If a machine sends ICMP redirect messages to another machine in the network, it could cause an invalid routing table on the other machine. If a machine acts as a router and gathers IP datagrams, it could gain control and send these datagrams wherever programmed to do so. These ICMP-related security issues will be discussed
in more detail in a subsequent chapter. ICMP Header Snapshots
Figure 1.22 on page 35 contains snapshots of an ICMP Header. The first was extracted after the IP portion of an ICMP ping test transmission; the second was extracted during an unreachable ping test.
Moving Forward
In this chapter, we reviewed the principal functions of the TCP/IP suite. We also covered various integrated protocols, and how they work with IP to provide connection-oriented and connectionless network services. At this time, we should be prepared to move forward and discuss interconnectivity with similar all-purpose communication protocols, including NetWare and NetBIOS technologies.
No comments:
Post a Comment