Chapter 1: Network Overview

1 2 3 4 Page 2
Page 2 of 4

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.

Figure 1-5Datagram encapsulation

A common vehicle for malicious network activity is an altered header field. Attackers capture all (or part) of a message so that it can be used for illegal purposes. The first line of defense is to know which headers are subject to legitimate change and which headers need to be fixed at a specific value, either because of protocol requirements or local security policies. The following list includes high-level categories for expected header behavior. Detailed IP header information is displayed later in this chapter:

  • Inferred. Values that can be inferred from other values. An example is packet length.
  • Static. Values in these fields are expected to be constant throughout the packet stream’s life; they must be communicated at least once. The IP version number is an example.
  • Static-Def. Static fields whose values define a packet stream. IP source and destination addresses are in this classification.
  • Static-Known. Static fields that are expected to have well-known values and do not need to be communicated, such as an IP version 4 (IPv4) header length field.
  • Changing. These fields are expected to vary randomly within a limited value set or range; the TTL field is an example.

Internet Protocol

IP is a primary protocol of the OSI Model and, as its name suggests, an integral part of TCP/IP. Although the word Internet appears in its name, IP is not restricted to use on the global Internet, where it is implemented on all participating hosts. So, what’s in a name? Readers interested in Internet history may enjoy visiting one of several Web sites that the Internet Society sponsors. The society rests at the top of a loosely formed organization of engineers, researchers, operators, and visionaries from the academic community. The IETF is connected to that hierarchy and, through its working groups, keeps the Internet running and is involved in its continued evolution. The URL for the IETF site is http://www.ietf.org/.

Because it is connectionless and uses logical addressing, IP is easily ported to networks that are isolated from the Internet. It is an excellent choice for managers of enterprise networks who need efficient, machine-to-machine communications today, but must prepare for Internet connectivity tomorrow. As a practical matter, when compared with non-IP networks, an existing IP infrastructure is cheaper to migrate to the Internet or to an extranet2 connection with another organization. NetWare environments, where IPX is a competing protocol, face bigger challenges as the need for growth becomes a reality.

A key concept about IP is that it is a routed protocol, not a routing protocol. An IP packet knows where it is going in the network because it holds addressing information that is unique to its destination. Furthermore, it can only be destined for an IP host, which is termed as such because it contains an IP address. To reach that destination, the packet depends on a routing protocol to direct its path by creating routing tables in infrastructure devices (hence the term router). The dependency of routed protocols on routing protocols is only a small sample, albeit an important one, of a larger set of interactions between software entities that keep the electronic world connected.

IP serves two basic purposes: addressing and fragmentation. The protocol is rigidly structured, and the logical part of its addressing capabilities does not imply a logical or virtual circuit. Fragmentation and reassembly is used for traversing networks3 where transmission units are smaller than at the packet’s source.

Engineers who have supported Ethernet segments might have a better grasp of what connectionless means, at least in the context of TCP/IP. They learned quickly enough that, however voluminous the trouble calls were from first-level support personnel, collisions were generally a good thing. As a shared medium, Ethernet reported collisions when multiple hosts transmitted simultaneously, mainly so some would back off and wait in line to retransmit. Too many collisions were symptomatic of error conditions, but more often than not, there was no cause for alarm. Just as “management events” might have been a better term than “collisions,” connectionless is a better term than “unreliable” when discussing IP. One of the reasons that IP is a robust, efficient protocol is that it leaves time-consuming tasks, such as looking up addresses in routing tables, to resident modules in devices along its path. By design, it is not involved in connection establishment and has no flow-control mechanism. When reliable delivery is necessary, the connection-oriented, higher layer protocol, TCP, produces that service.

The closest thing to flow control in IP—and it is not close at all—is the TTL field in its header. The upper bound of the TTL value is set at the sending side, and it is decremented by one at each point along the route. If the value reaches zero before the packet reaches its destination, the packet is destroyed, which prevents an infinite routing loop. IP packets do not have a checksum function for the data contents of their payload; that’s only for header information.

IP provides for a maximum packet size of 65,535 octets, which is much larger than most networks can handle, hence the need for fragmentation. When the first fragment arrives at its destination, the receiving host’s Internet layer starts a reassembly timer; if all fragments are not received by the time a predetermined value is reached, the received fragments are discarded. When fragments are received on time, the receiving host uses the identification field in the IP header to ensure that fragments are inserted back into the correct packet.

This fragmentation method is called Internet fragmentation, and it is documented in the specification for the IP protocol. An intranet fragmentation method is in existence that might be implemented by software developers, but it is outside of RFC specifications. It is a LAN-only method that is transparent to the Internet module in host software.

Attackers can use altered fragments to allow incoming connections on outgoing-only ports. In 2001, this was exemplified by the Tiny Fragment Attack and the Overlapping Fragment Attack, both of which are explained in RFC 3138, “Protection Against a Variant of the Tiny Fragment Attack.” Do not confuse reassembling fragmented packets with situations where packets unexpectedly arrive out of order. Out-of-order packet arrival is symptomatic of one or more situations that are far more serious than a route through a small packet network. Some of the more worrisome causes for out-of-order packet arrival are

  • Packets have been captured, tampered with, and then played back for intrusion or reconnaissance purposes. An example is a man-in-the-middle (MITM) attack (also called a replay attack).
  • Asymmetric routing4 is occurring, which, under certain conditions, causes out-of-order packet arrival. For example, when the return path has changed because of a circuit failure and the new path has higher propagation delays, an increase in the overall round trip time (RTT) is experienced. This particular condition is known to cause out-of-order packet arrivals.
  • Certain router load-sharing configurations, where the outbound packet stream splits across multiple interfaces, can cause out-of-order packet arrival at the destination.

The IPv4 header is specified in RFC 791, “Internet Protocol,” as being six 32-bit words in length when all optional fields are populated and with a minimum value of five words. It has no hardware dependencies and must be compatible with previous versions of IP. The requirement in RFC 791 for compatibility with earlier versions was important at the time because there had been six prior versions in production on ARPANET. This becomes relevant again as IP version 6 (IPv6) becomes a reality on the Internet. Figure 1-6 shows the IPv4 header layout.

Figure 1-6IPv4 header layout

A more detailed explanation of an IP packet structure is expounded in the following list. The field name is followed by its length and description:

Related:
1 2 3 4 Page 2
Page 2 of 4
Download: EMM vendor comparison chart 2019
  
Shop Tech Products at Amazon