TCP/IP from a Security Viewpoint

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
By Matthew Strebe, Charles Perkins

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 3 from Firewalls, 24 seven, published by Sybex, Inc.

If you are reading this book, you presumably have a good understanding of how computers work and you have a working knowledge of how to use Internet tools such as Web browsers, Telnet, and e-mail. You might not, however, know just how your computer connects to other computers and downloads Web pages, exchanges e-mail, or establishes a Telnet session. This chapter will give you a better idea of what is going on behind the scenes.

On This Page

You Need to Be a TCP/IP Guru
TCP/IP Rules
The Bit Bucket Brigade
Case Study: Where Is the Data Coming From?

You Need to Be a TCP/IP Guru

But why do you care how TCP/IP works if you aren't a computer programmer or network engineer? You should care because the hackers attempting to get past your network security are often computer programmers or network engineers (self-taught or otherwise), and in order to stop them you need to understand and correct the weaknesses in TCP/IP or higher-level protocols that they will attempt to exploit. In other words, know what your enemy knows.

You don't have to be intimidated by the network technology because you just need to know enough to keep the hackers out; not so much that you can recreate a network from scratch. If you were planning the defence of a castle, you wouldn't need to know how to build the stone walls or forge swords, but you would need to know where the openings are, how the invading barbarians typically attack a castle, and what defenses you have at your disposal.

Similarly, you don't need to drop everything and learn how to write device drivers in C, nor do you need to pore over the Internet RFCs that describe the protocols you use. You should know what protocols your network supports, however, and you should have a basic understanding of how the protocols interact with your firewall, the client computers on your network, and with other computers outside your firewall on the Internet. You should understand the risks (and benefits) of opening ports on your firewall for the various services your network clients would like to use. You should be aware of the limitations a firewall places on network traffic, and you should understand which protocols are easily subverted by hackers and which ones are not.

TCP/IP Rules

What is the big deal about TCP/IP anyway? Why, with its acknowledged weaknesses (we'll get to them in a moment), is the world using TCP/IP to "get wired" instead of another protocol, such as IPX/SPX or SNA? TCP/IP has won out over other protocols that might have competed for world domination for the following reasons:

TCP/IP is packet based. Many communicating computers can send data over the same network connections. The alternative is to use switched networks, which require a dedicated circuit for every two communicating devices. Packet-based networks are less costly and easier to implement. They typically don't guarantee how much bandwidth the communicating devices will get or what the latency will be. The market has shown, through the Internet, that low cost is more important than guaranteed performance.

TCP/IP provides for decentralized control. Every network that communicates via TCP/IP gets a range of numbers to use for the computers on that network. Those numbers, once assigned to the organization that requested them, are under the control of that organization for assignment, reassignment, and even sub-allocation to other organizations. Internet Service Providers, for example, get a block of numbers and then dynamically allocate them to callers as they attach to the ISP. Similarly, the Internet domain names, once assigned to an individual or organization by a top-level Internet authority, can be further sub-allocated locally without top-level intervention or authorization. If you own, for example, you can assign www to one computer, to another, and to a third. Similarly, is subdivided by the University of Utah into,,, and (which is further subdivided into and and a host of other specific Internet names for computers on the Law School network).

Communicating devices are peers. Unlike other contemporary networks that divide computers into clients and servers (such as NetWare) or mainframes and terminals (such as SNA), TCP/IP treats every computer on the network as a peer—able to initiate or accept network connections independently of other computers (presuming, of course, that there is a network path between the two computers). Client and server software can be implemented on top of TCP/IP using sockets, but that is all irrelevant to the TCP and IP protocols. This means that TCP/IP is flexible and less likely to be vulnerable to failures of other computers not in the network path between the communicating computers.

TCP/IP is routable. A routed network protocol makes it easy to pass data between two or more LANs or network links because routers simply retransmit the data in the payload portion of the network packet from one LAN onto another. Network protocols that can't be routed must rely on protocol gateways, which reinterpret the data on one network to allow it to conform to the addressing and data requirements of the other.

TCP/IP is independent of any particular transmitting medium. TCP/IP will work over Ethernet, Token Ring, ARCnet, FDDI, USB, serial links, parallel port cables, shortwave radio (AX.25,) or any other mechanism that allows two or more computers to exchange signals. TCP/IP has even been defined to work using carrier pigeons as a packet delivery service!

TCP/IP is an open standard. All of the documents describing the TCP/IP standard are available on the Internet for anyone to download and implement for free. There are no trade secrets or hidden implementation details limiting who may implement it.

TCP/IP is free. TCP/IP was developed by universities with defense department funding, and anyone may implement it without paying royalties or licensing fees to any controlling body. Nobody "owns" TCP/IP. Or rather, everybody does.

TCP/IP is robust. TCP/IP was designed when telecommunications lines between computers were not completely reliable, so the TCP/IP protocols will detect and correct transmission errors and gracefully recover from temporarily interrupted communications. TCP/IP will even route around damaged portions of the Internet.

TCP/IP is flexible. TCP/IP is a protocol suite, with IP and a few other simple protocols at the bottom, and other protocols providing increasingly more sophisticated services layered on top. A simple network device, such as a router or print server, need only include those components required for it to do its job. Other more complex devices, such as personal computers or domain name servers, implement a wider range of protocols to support their expanded functionality.

TCP/IP is pragmatic. TCP/IP grew from a simple set of protocols. Additional protocols were added as the implementers found more uses for TCP/IP. This contrasts protocol suites designed ex-nihlo (such as the OSI stack) which, since nobody can think of everything, often leads to over-architected and brittle standards that don't quickly adapt to changing network requirements.

TCP is not perfect, however. Two significant limitations are addressing and security. When it was first designed to link university and military computers, the implementers had no idea it would eventually grow to span the whole world. At the time, 32 bits of address space (allowing for approximately four billion computers) seemed plenty. Now, not only computers and routers, but also printers, terminal servers, scanners, cameras, fax machines, and even coffee pots connect to the Internet. Those 32 bits are being used up quickly, especially since address numbers are allocated in blocks and not all of the numbers in a block are actually used. Also (despite the military application of TCP/IP), the designers did not spend a great deal of effort securing TCP/IP against data snooping, connection hijacking, authentication attacks, or other network security threats. The era of electronic commerce lay too far in the future to worry about when they were designing a small communications system for a few elite researchers engaged in the open exchange of information.

So TCP/IP is cool, but how does it work? The next section will show you the nitty-gritty details of how your computer talks to those other computers on the Internet.

The Bit Bucket Brigade

Computer networks are complicated, and there is a lot you need to understand about TCP/IP in order to keep your network safe. Fortunately, you don't have to understand the whole structure of TCP/IP at once; you can start at the bottom of the stack (the TCP/IP suite is often called a protocol stack) where things are relatively simple and work your way up. You can do this because TCP/IP is built in layers, each of which relies on the services provided by the layer below and provides more powerful services to the layer above. Figure 3.1 shows a graphical view of the layers in the TCP/IP protocol suite.

The International Organization for Standardization (which in English goes by the acronym ISO) has developed a useful model for comparing network protocols called OSI (Open Systems Interconnect). The OSI stack is comprised of seven layers; the first five describe well the first five layers of the TCP/IP protocol suite. The bottom three layers describe how data transfers from one computer to another, and are discussed in this section, starting at the bottom.


Figure 3.1: The TCP/IP protocol suite is composed of layers of services roughly corresponding to the layers of services defined in the OSI network model.

Layer 1: Physical

Computer networking requires that each computer has a physical device (such as an Ethernet card or modem) to use to connect to the network. This device, and the signaling characteristics of it, comprise the Physical Layer in the TCP/IP suite and the OSI stack. TCP/IP doesn't care what kind of device it is (TCP/IP is not dependent on any specific transmission medium, remember?), only that there is one, and that data can be exchanged using it. TCP/IP relies on the operating system to configure and control the physical device.

Although TCP/IP doesn't care how the data physically gets from one place to another, you should. People trying to break into your network may chip away at any level of the network stack, including the Physical Layer. You need to understand the security implications of each physical-network link choice in order to keep your network secure.

For convenience's sake, physical-layer links can be divided into three categories based on connection behavior:

Dial-up Temporary point-to-point connections over a shared infrastructure such as the telephone system

WAN and MAN (Wide Area Network and Metropolitan Area Network) Constantly connected point-to-point connections

LAN Two or more network devices communicating over a shared broadcast media

For each of the physical link options in each category we'll examine the security vulnerabilities and remedies for that option.


Dial-up connections are temporary; they are established when they are needed and reset at the end of the communications session. The biggest problem with dial-up communications (and digital leased lines as well) is that you cannot provide physical security at all points along the communications stream. The cables are run through the public infrastructure (under streets and over power lines) and other private establishments (the basement of your office complex, for example, where only janitors and telecom people dare to go).

Modem This communications medium uses regular, twisted-pair copper telephone lines for sending and receiving data and attaches to the phone lines just like a regular telephone. The modem modulates the outgoing serial digital signal into analog electrical signals in the same range as a telephone produces for human speech. It demodulates the incoming "tones" (actually just electrical signals corresponding to tones) back into serial digital bits for the computer to receive. Modem bit rates are typically low (up to 56 Kbps).

Vulnerabilities A physical tap on a phone line (either in the same building or at the phone company) can be fed into another pair of modems (one to receive each channel of the bi-directional communications) which can then demodulate the network traffic and feed it to an eavesdropping computer.

Remedies Encrypt the data being sent over the modems.

ISDN This communications medium uses regular, twisted-pair copper telephone lines for sending and receiving data, but rather than connecting like a telephone, the data is sent digitally. Because ISDN does not connect to the phone wires like a regular telephone, the phone wires must be connected to a special, digital service. ISDN bit rates range from fast modem speed (56 Kbps) to almost T1 speed (1.5 Mbps).

Vulnerabilities As with a regular modem, a physical tap on a phone line (either in the same building or at the phone company) can be connected to a specially programmed ISDN modem which can snoop on the network traffic and feed the intercepted communications to an eavesdropping computer.

Remedies Encrypt the data being sent over ISDN.


WAN and MAN communications channels are typically links that are permanently maintained between locations made either using the telephone infrastructure or wireless technologies such as radio, microwave, or lasers.

Dedicated Digital Leased Lines The most frequently used, permanent Internet connection for businesses today is a dedicated telephone line leased from the local phone company that is connected by a digital device called a CSU/DSU. These connections are like ISDN connections in that they are digital; however, they are not established and then shut down for each communications session as ISDN connections are. Also, the bit rate of a leased line ranges from modem speed (56Kbps for a fractional T1) to many times faster than typical LANs (an OC12 allows 1.5 Gbps!). Leased lines may also be shared by more than one communicating device (as in the case of Frame Relay), but are typically transparent to the customer. This is true except when the leased line is also being used by another customer; in such cases there will be less available bandwidth. See Figure 3.2 for a comparison of leased line data rates.


Figure 3.2: Leased line data rates range from 56Kbps all the way up to 2.5 Gbps.

Vulnerabilities As with a regular modem, a physical tap on a phone line (either in the same building or at the phone company) can be connected to a specially programmed DSU which can snoop on the network traffic and feed it to an eavesdropping computer.

Remedies Encrypt the data being sent over leased lines.

Radio, Microwave, and Laser Sometimes it is not feasible to run a physical cable between two locations. Islands, buildings separated by ravines, ships, and isolated communities, for example, need a way to exchange data without wires. NASA uses TCP/IP to communicate with some of its satellites, and for that application copper cables are certainly not an option!

TCP/IP will operate just as effectively over a wireless medium as a wired one. The computer (or other network device) must, of course, have a transceiver for the medium—and there are transceivers for radio, microwave, and even laser communications. Most radio and microwave transmissions have stringent licensing requirements (there is only so much room in the RF spectrum, and government or military applications generally take priority), so there is a lot of paperwork as well as expensive equipment involved in setting up a radio or microwave link.

Vulnerabilities Broadcast media, such as radio and microwave, are even easier to eavesdrop on than cabled media. A single radio anywhere in the broadcast range of both the sender and the receiver of a radio link can eavesdrop on radio communications, while two receivers, each stationed behind and in the line-of-sight of the target transponders, can record the data being sent between them. Alternatively, two receivers directly between the transponders can eavesdrop on the communications, and since the power requirement is squared at twice that distance, the eavesdropping dishes can be much smaller. (Laser communications cannot be easily eavesdropped on in this manner, but lasers are much more sensitive to environmental effects such as rain and snow.)

Remedies Encrypt the data being sent over radio or microwave links. Consider using lasers for point-to-point communications in areas that are not adversely affected by weather and have adequate line-of-sight between communicating endpoints.

DSL This communications medium uses twisted-pair copper telephone lines for sending and receiving data, but they must be of sufficient quality and length to handle the greater voltages of the downstream xDSL (Digital Subscriber Line) signal. Also, like ISDN, the data is sent digitally. Because xDSL does not connect to the phone wires like a regular telephone, the phone wires must be connected to a special, digital service. DSL bit rates are much higher than regular modems (up to several Mbps depending on cable quality and filters).

Vulnerabilities As with a regular modem, a physical tap on a phone line (either in the same building or at the phone company) can be connected to a specially programmed xDSL modem which can snoop on the network traffic and feed it to an eavesdropping computer.

Remedies Encrypt the data being sent over xDSL.

Cable Modems This communications medium uses the cable TV infrastructure for sending and receiving data. A portion of the cable broadband capacity is reserved for digital communications, and all of the customers in a neighborhood share that bandwidth like an Ethernet (the computer even connects to the cable modem using an Ethernet adapter). Cable modem bitrates are the highest of any low-cost Internet connection service (768Kbps upstream, up to 10 Mbps downstream).

Vulnerabilities As with Ethernet, an adapter strategically placed (at the cable company head-end) can snoop on the network traffic and feed it to an eavesdropping computer.

Remedies Encrypt the data being sent over cable modems.


While dial-up and WAN communications provide network links over large distances and generally connect just two computers together, LAN links are typically tied to a single physical location such as an office building and provide many computers with a shared communications medium.

Adequate site security can alleviate the problem of physical tapping of LAN communications, but when you develop the site security plan, keep LAN security requirements in mind.

Ethernet, Token Ring, FDDI, ARCnet, etc. Ethernet has become the glue that binds an organization together. Most organizations can still get some work done if the coffee pot breaks, the printer runs out of toner, or the Internet connection drops, but you can forget it if the network stops working! Ethernet's speed, versatility, and ease of configuration has made it the LAN substrate of choice. From a hacker's point of view, however, they all work similarly—cables are run to various locations, and computers are plugged into them. Any one computer on the LAN can transmit using electrical or optical signals to any other computer on the LAN. If a hacker can get control of one of the computers on the LAN, they can listen to all of the communicating computers.

Vulnerabilities Any computer attached to a LAN can eavesdrop on all of the communication traversing it.

Remedies Maintain strong physical security. If a portion of the LAN goes through a publicly accessible area (such as between buildings in a campus environment), consider using fiber optic cable for that section. Fiber optics are not easily tapped and any break in the cable will terminate the link.

Serial Connections Sometimes you just need to link two devices, but you don't need a very fast connection—RS232 serial cables will do that just fine, and most computers come with serial ports built in. Serial cables make a good poor man's LAN, and serial cables have the same vulnerabilities that other LANs do.

Vulnerabilities A serial cable can be spliced and the data sent over it fed to a third observing computer.

Remedies Maintain strong physical security.

Layer 2: Data Link

At the very bottom of networking technology, signals are sent from one computer to another using an adapter (as the above section shows, there are many kinds of signals and many kinds of adapters). But how does the computer talk to the device, and how are those signals organized into bits that the computer can make sense of? That's what the Data Link Layer (Layer 2 in the OSI stack) is all about, and that's where the software meets the hardware.

Each networking adapter requires a piece of software, called a device driver, so that the operating system can control the hardware. The device driver must be tailored to the specific hardware device (such as an Ethernet card or FDDI adapter) that it drives. The operating system also requires a consistent way of simultaneously communicating with all of the network devices available to it. For this reason, the Data Link Layer has been split (in the IEEE elaboration on the OSI network model) in to two sublayers:

The Logical Link Control (LLC) Sublayer Provides the operating system link to the device driver.

The Media Access Control (MAC) Sublayer Translates generic network requests (send and receive frames, device status, etc.) into device-specific terms.

Media Access Control

The MAC sublayer rests at the very bottom of the software stack, and does its work just before the hardware turns your data into electrical or optical signals to be sent out on the cable. This is the device driver, and it is responsible for controlling the hardware device, as follows:

  • Reporting and setting the device status

  • Packaging outgoing data received from the LLC sublayer in the format that the network adapter requires (in the case of Ethernet and PPP, a correctly constructed frame)

  • Sending outgoing data at the appropriate time

  • Receiving incoming data when it arrives

  • Unpacking incoming data from the transmission format (i.e. the Ethernet or PPP frame), verifying the integrity of the data, and relaying the data up to the LLC sublayer

A network adapter actually receives all of the network frames transmitted over the link (if it is a shared media link, such as Ethernet) regardless of the intended destination because the network adapter has to read the recipient portion of the frame in order to determine if it is the intended recipient or not. The MAC sublayer discards all frames intended for some other recipient and only forwards data in frames intended for the MAC sublayer to the LLC sublayer above it.

The format of frames varies among link types, depending on the features supported by that networking technology. Ethernet, for example, has 48 bits of address space for identifying network devices, while ARCnet has only eight, and for PPP the addressing is irrelevant (the only device you can be talking to is the one at the other end of the line). Similarly, each supports a different data portion size, the ordering of status and control bytes differ, and some network types support features that others do not (such as compression, encryption, quality of service, authentication, and so on). Figure 3.3 compares Ethernet and PPP frames.


Figure 3.3: The structure of Ethernet and PPP frames are tailored to their uses (Ethernet for fast shared LANs, PPP for slow dial-up links).

Ethernet There are actually two frame types for Ethernet. The original Ethernet frame (defined in RFC 894) specified that the last two bytes indicate the type of the frame. The IEEE's reinterpretation of Ethernet (changed in order to fit it into their network taxonomy and defined in the IEEE 802.2 and 802.3 standards as well as RFC 1042) uses the bytes at that offset as a length indicator. Fortunately, none of the RFC 894 types have the same two-byte value as valid IEEE 802 lengths, so network software can tell the two frame formats apart.

The fields the two frame types have in common are the six-byte address and data fields (giving 48 bits of hardware addressing) and the four bytes of cyclic redundancy check (CRC) at the end. For standard Ethernet frames (as opposed to IEEE 802.3 frames), a type of 0800 indicates that the data portion of the frame is an IP packet. 0806 is an ARP packet, and 8035 is a RARP request/reply packet. The IP packet can be from 46 to 1500 bytes in length, while the ARP and RARP packets are 28 bytes in length plus 18 bytes of padding because the minimum data length for a standard Ethernet frame is 46 bytes.

For both kinds of Ethernet, those six-byte addresses identify the sender and the recipient in an Ethernet LAN. An Ethernet LAN is a network where the computers' communications are mediated only by hubs, switches, media converters, and bridges, not routers or firewalls. Ethernet cards are purchased with addresses pre-assigned to the cards (or to the device if the device, such as a network printer, which comes with Ethernet built in). Because each hardware manufacturer is assigned a different range of Ethernet addresses to build into their devices, every Ethernet card or device should have a unique address. However many Ethernet adapters now allow their addresses to be over-ridden in software, so uniqueness is not guaranteed.

Warning: Don't rely solely on unique Ethernet addresses to identify network frames from authorized computers. A network intruder could perform a denial-of-service attack on the authorized computer and bring up in its place on the network another compromised computer with the same Ethernet address configured in software.

Although the addresses in Ethernet frames are (or should be) globally unique, they can only be used to identify computers on the same Ethernet LAN. This is because the Ethernet frame contains no provisions for forwarding or routing between networks. Ethernet is a shared media network, in that every computer on it should be able to communicate directly with another device on the LAN without the Ethernet frame being reinterpreted and converted by an intervening router or firewall. While the frame may be selectively forwarded to other Ethernet segments and/or converted to new media by bridges and media converters, the actual contents of the frame must remain the same. Other LAN protocols, such as Token Ring, ARCnet, and FDDI have local addresses in their frames, not internetwork addresses that can be used to route data between LANs.

TCP/IP uses IP, ARP, and RARP to move data across the whole Internet, not just the local LAN. For now you can just think of them as the data that has to be exchanged; from the Ethernet point of view, it doesn't matter what is contained in the data portion of the frame. Ethernet will convey other network protocols, such as IPX (used by NetWare,) EtherTalk (AppleTalk on Ethernet,) and NetBEUI (Microsoft's networking protocol) just as easily as it will convey TCP/IP.

Note: We'll discuss IP, ARP, and RARP in more detail later on in this chapter.

For IEEE 802 frames, after the length field, there are three bytes containing 802.2 LLC information, and five bytes of SNAP information, the last two of which specify the type of data contained in the payload section. As with Standard Ethernet, a type value of 0800 specifies an IP datagram, 0806 specifies ARP, and 8035 specifies RARP. Because of the 8-byte LLC and SNAP overhead of IEEE 802 frames, the data portion of the frame may be from 38 to 1492 bytes in length, giving a maximum Ethernet packet a length of 1492 and ARP and RARP packets an absolute length of 28 bytes of data and 10 bytes of padding.

PPP The Point-to-Point Protocol was designed to support multiple network types over the same serial link, just as Ethernet supports multiple network types over the same LAN. It replaces an earlier protocol called SLIP (Serial Line Internet Protocol, which is still in wide use) that only supports IP over a serial link.

PPP frames have a five-byte header. The first three bytes are constant (7E FF 03 for the flag, address, and control bytes respectively), and the last two specify the protocol being transmitted in the data portion of that frame. The frame can hold up to 1500 bytes of data, and is trailed by a two-byte CRC and a one-byte flag (value 7E).

The three protocol types used by IP over PPP are the IP datagram with a protocol value of 0021, the link control data packet (C021), and network control data (8021).

Link Establishment Subversion There are several tricks that old-school telephone hackers (or phreakers, as they call themselves) can use to subvert or abuse dial-in networks. Call forwarding, for example, can re-route connection attempts to a hacker computer that can then eavesdrop on all your communications at the modem level rather than the IP level. If the computer making the connection supports several network protocols (newer versions of Windows can use IPX and NetBEUI as well as IP over PPP), the hacker can attempt to break in to the dial-in computer with one of these other protocols. Also, dial-up connections made over cellular phones (especially analog cellular phones; digital ones are a little more secure) can be eavesdropped on and even interrupted or captured by hackers with modified radios and cellular telephones.

Media Access Subversion Since it is up to the MAC to discard frames destined for other computers, hackers exploit this behavior by placing the device driver in promiscuous mode (replacing the device driver with one that supports promiscuous mode, if the installed device driver lacks it). Promiscuous mode simply relays all packets, regardless of their intended destination, to another program that monitors the data on your LAN.

Tip As a part of your greater security policy (beyond setting up and running a firewall), you'll want to monitor the computers on your network for changes to the device drivers, as well as to other important system files (such as the password lists and network service program files).

Logical Link Control

The LLC portion of the network stack is where the operating system sets up and controls the device driver as a general network device. If you have multiple Ethernet adapters, for example, you may have only one device driver but you will need several instances of it running, one for each Ethernet card. You may also have a Token Ring adapter and several serial port links in your computer, and the operating system will want to treat them all the same—as generic network devices that it can initialize, query the state of, deliver data to, and receive data from. Every operating system has a different specification for this layer, but all the device drivers for the operating system must meet the specification in order to operate as network devices. Windows NT has the Network Driver Interface Specification, (or NDIS) for example, and Unix has its character mode device specification (which, of course, varies among Unix implementations).

Layer 3: Network

TCP/IP doesn't specify how the Physical and Data Link Layers work, it just expects them to provide enough functionality to link two or more computers together into a Local Area Network. That is, because TCP/IP is an Internetwork Protocol suite, it specifies how data can make its way from a computer on one LAN to another computer on a totally different LAN that could be as far away as half-way around the world or out of this world entirely.

TCP/IP does not replace other network technologies such as Ethernet or Token Ring. Instead, it incorporates their functionality and layers its own on top (this is in contrast to the supposed network of the future—ATM—which attempts to provide one specification that works at all layers of the OSI stack). The next layer up in TCP/IP is the Internet Protocol, or IP.

Each layer in the stack exists to perform a specific function. The Data Link Layer moves data across a LAN. The purpose of the Network Layer is to move data across as many LANs and network links as is necessary to get the data to its destination. IP performs this function well, and it performs only this function—other functions, such as ensuring that the data arrives in order and without duplication, or even that it arrives at all, are performed by other higher-level layers.

How Layering Works

Each layer in the OSI model (and in the TCP/IP suite) operates by using the data portion of the layer below it. IP over Ethernet, for example, places its data structures (called packets) in the data portion of the Ethernet frame. TCP (a layer above IP) places the communications streams it manages in the data portions of IP packets. Application level services such as FTP, which use TCP to establish and maintain the communications channels for exchanging files, write data to TCP sockets, which are placed in IP packets, which are placed in Ethernet (or PPP or Token Ring) frames to be sent out over the network link.

Another way of looking at the protocol stack is to start from the highest level and work your way down. As the data goes down through the TCP/IP networking layers, information specific to that layer is added to the data until it reaches the bottom, at which point it is sent out over the communications link (see Figure 3.4.). When it is received on the other side, the process is reversed, with each layer removing the data specific to that layer, until it is presented to the ultimate recipient of the data.

Frames and Packets The basic unit of Logical Link Layer data transmission is the frame. The Internet Protocol has a similar basic unit of data transmission—the packet. An IP Packet is quite similar in structure to an Ethernet frame, with source and destination addresses, packet description and option fields, checksums, and a data portion. Because of the way IP is layered on top of the Logical Link Layer, all of the packet structure is nested inside the data portion of the logical link frame (Ethernet, for example).

There are many different types of packets exchanged in a TCP/IP network, starting with the ARP and RARP packets (described in the "Machine vs. IP Addresses" section), and including IP packets (described in the next section of this chapter). For now, just understand that the Internet is based on packets nested in frames. The generic structure of an IP packet is illustrated in Figure 3.5.


Figure 3.4: Each layer of the OSI stack adds layer specific data to what it receives and passes the expanded information to the layer below it. When the layer receives information from the layer below it, the layer removes layer-specific data and passes the information on to the layer above it.

The IP Header As shown in Figure 3.5, the IP header is typically 20 bytes long, but can be up to 60 bytes long if the packet includes IP options. The (non-optional) fields are as follows:

Version These four bits identify which version of IP generated the packet. The current IP version is 4. (IPV6 would, of course, place a 6 here.)

Header length This four-bit value is the number of 32-bit words (not bytes!) in the header, and by default is 20.

Precedence (TOS) These eight bits are an early attempt at implementing quality of service for IP. They are comprised of three bits for packet precedence (ignored by modern implementations of IP), four Type of Service bits, and a bit to be left at zero. Only one of the four Type of Service bits can be turned on. The four bits are: minimize delay, maximize throughput, maximize reliability, and minimize cost. All zeros means the network should use normal priority in processing the packet. RFCs 1340 and 1349 specify TOS use. Most implementations of IP don't allow the application to set the TOS value for the communicated data, which limits the usefulness of this field.

Datagram Length This is the total length of the IP datagram in bytes. Since this is a 16-bit field, the maximum IP packet size is 165535 bytes in length, even if the Data Link Layer frame could accommodate a larger packet.


Figure 3.5 An IP packet has a header that includes the source and destination IP addresses, version, type, and service information, options, and a data section.

Identification To guarantee that packets are unique and to assist in the reassembly of data streams that have been broken down into packets, the sending computer numbers the packets, incrementing the value when each packet is sent. This value doesn't have to start at zero, and isn't necessarily incremented by one on all implementations of IP.

Flags Flags define whether or not this packet is a fragment of a larger packet.

Fragment Offset This defines where in the chain of fragments this fragment belongs when reassembling a fragmented packet.

Time To Live This declares the number of routers through which the packet may pass before it is dropped. This prevents packets from getting caught in routing loops. This field is typically set to 32 or 64. When a packet is dropped due to TTL expiring, an ICMP message is sent to the sender.

Protocol This field shows which IP protocol (TCP, UDP, ICMP, etc.) generated the packet and should be the recipient of it at the destination.

Header Checksum All of the 16-bit values in the packet header are summed together using one's complement addition and placed in this field.

Source This is the computer or device sending the IP packet.

Destination This is the intended ultimate recipient of the IP packet.

Network Byte Order (Big Endian)

Internet Protocol packets are sent in Network Byte Order, where the most significant bit of a word is sent first. For example, the 32-bit word 0xFFE0A102 would have the byte 0xFF sent first, and the byte 0x02 sent last. For this reason, Network byte order is also called Big-Endian. The other way of doing things is called Little-Endian, where the least significant bits are sent first.

Network Byte Order can be a little confusing to think about. If you number the bits in a word being sent, starting with zero, the most significant bit is the 0th bit and the least significant bit is the 31st bit. This is the opposite of how computer professionals are used to numbering bits.

Of course, regular people (and computer professionals, too) like to count forwards rather than backwards when sending and receiving things, and there are other good reasons to send data in Big Endian order. Plus, the Internet requires a standard byte order. Therefore, Most Significant Bit first, starting the count at zero, is the way to go.

Networks of Networks

The Internet is more than just a really big LAN—it is a network of networks, in much the same way a LAN is a network of individual computers. And just as every computer on an Ethernet has an Ethernet address, every network in the Internet has a network address. In addition, every computer on the Internet also has a station address identifying it on that network. Together, the network address and the station address form the IP address, uniquely identifying that computer on the Internet.

Networks vary in size, from small home or office networks to multinational corporations and large ISPs that may have thousands of computers connected to their network. There are many more smaller networks than there are large ones. The designers of the Internet Protocol took advantage of this fact by making the sizes of the network and station addresses variable, with the network portion getting larger as the station portion gets smaller. That way, the address size as a whole can remain constant. With the eternal optimism of computer programmers everywhere, they decided that 32 bits would be plenty—after all, what is the likelihood that anyone would want to connect more than four billion devices to their little academic network?

Class and Classless Addressing

It used to be that you could tell the size of a network by the first byte of the network address. If the first bit was zero (i.e. if the byte was from 0 to 127), the address was a class A network. If the first bit was one and the second was zero (if the byte was from 128 to 191), it was a class B network. If the first two bits were one and the third was zero (if it was from 192 to 223), it was a class C network. So, a simple look at the IP address told you how big your LAN was and whether or not another computer was on the same network (it was on the same network if it had identical network address bits as specified by the class, and a different set of station bits in the IP address).

But things have changed. With the advent of classless adressing, you can no longer expect your IP address to reflect the size of the network the computer is on. Instead, you have to examine the subnet mask, which explicitly defines the size of the network address portion and the station address portion of the IP address. Classless addressing started as an easy way for organizations with large networks to efficiently break up their large IP ranges into subnets (that's why it's called a subnet mask), and as the IP address range has filled up, classless addressing has proved itself a useful tool for scavenging smaller class C network numbers out of the large class B and class A spaces.

If you were paying attention you'd have noticed that classes A, B, and C did not fill up the all 32 bits of IP address space. There were two additional classes specified, as follows:

  • Class D (with the first three bits set to one and the fourth set to zero), which was reserved for IP multicast (sending packets to multiple networks)

  • Class E (with the first four bits set to one and the fifth set to zero), which was reserved for future use

Until address space started to run out, an organization could request a range of addresses in one of three classes that conveniently mapped to byte boundaries, as follows:

Class A There were only 125 (0,10, and 127 reserved) of these because only seven bits were used for the network address (the first bit was zero and (several network addresses are reserved), but a class A network could have more than sixteen million stations.

Class B There were about 16,000 of these, each of which could have more than 65,000 stations, because the network portion of the address was 14 bits and station portions of the address were 16 bits in size.

Class C Almost the opposite of a class A network, there were about two million possible class C networks, each of which could have up to 254 station addresses.

The number of networks and stations are always a little less than the number of bits allocated to the network size because several network and station addresses are reserved for special functions. The lowest and highest address (0 and 255 for class C, 0 and 65536 for class B, etc.) are used for broadcasting to all of the computers in the local network, for example.

So, when an organization wanted to connect to the Internet they got a range of IP addresses sufficient for the number of computers they wanted to hook up. Internally, the computers all shared the same network number, but each had different station addresses.

Machine vs. IP Addresses

If Ethernet addresses are globally unique, why not use them as the Internet address? Ethernet addresses could not be used as a global addressing scheme because a) not every computer has an Ethernet adapter, and b) the sending computer needs to know not only the recipient's address, but also how to send the data to that address (there's no telling where in the world any particular Ethernet adapter might end up).

For this reason, IP uses its own addressing scheme in addition to whatever addressing scheme is used by the network adapter in the machine. IP addresses are four bytes long, and (unlike Ethernet addresses) they are hierarchical in nature. While Ethernet cards from different vendors (and therefore with completely different Ethernet addresses) can be mixed with impunity in a LAN, all of the TCP/IP-capable computers that communicate directly with each other (i.e. that are in the same subdomain) have anywhere from 3 to 30 bits of the address in common, depending on the size of the subdomain the computers participate in.

The Ethernet, Token Ring, ARCnet, FDDI, or AX.25 address (depending on the Data Link Layer media connecting the computer to the Internet) is still used to get the IP data across the LAN. To avoid confusion, the Data Link Layer address is called the Machine Address, while internetwork addressing is done using an IP address, which is more than just a number.

Network Addresses, Subnet Masks, and Station Addresses As described in the previous section, every IP address has two parts: those bits it has in common with the other computers in its subdomain (called the network address) and those bits that are unique for computers in the subdomain (the station address). The bits for the network address always come before the bits for the station address. A third IP configuration value, the subnet mask, tells the computer which part of the IP address is the network address and which part is the station address, as shown in Figure 3.6.


Figure 3.6: The subnet mask identifies which part of the IP address is the network address and which part is the station address.

All of the computers that have the same network address are expected to be able to directly communicate with each other using the Data Link Layer. All of the computers on one Ethernet LAN could be put in one subnet, for example, and all of the computers in a Token Ring LAN could be put in another. Mixed Token Ring and Ethernet computers can't all be put in the same IP subdomain (i.e. they could not be given the same network address) because an Ethernet enabled computer could not send an Ethernet frame directly to a Token Ring enabled computer.

Every subnet that will be connected to a larger network, such as a campus network or the Internet, must have at least one machine that has multiple network adapters so that it can move data between the LAN and the exterior network. This machine is called the gateway in Internet terminology (see Figure 3.7), and can be a special purpose adapter (such as a fast hardware router) or a general purpose computer that routes network data as well as performing other functions (such as firewalling and hosting FTP and Web services). This machine will have two (or more) IP addresses, one for the network adapter residing on the local network and one (or more) for the network adapter(s) residing on the external one(s).


Figure 3.7: A gateway machine has two network adapters and allows network traffic to move between LANs.

A multi-homed host may reside on networks of different sizes. Therefore, each network adapter (Ethernet, CSU/DSU, modem, etc.) has a different subnet mask associated with its IP address, identifying for that IP address only which part of it is the network address and which part is the station address for that network adapter.

Communicating with a Local Host Sending IP data is a little more complicated than sending Ethernet data, partially because IP uses data link protocols such as Ethernet to do part of its job. With Ethernet, a computer that has data to send just broadcasts it. Every computer on the LAN then receives it and (unless a hacker has put an adapter in promiscuous mode) only the recipient keeps it. IP, on the other hand, needs first to determine whether or not the destination computer is on the local network, and if so, what its corresponding machine address is before it can send the packet embedded in a Data Link frame.

IP operates simply to determine if the destination computer can be communicated with directly. For each of the network devices attached to the computer, the computer compares the network portion of the adapter IP address (as identified by the subnet mask for that adapter) with the same bits (but only those bits, as identified by that same subnet mask) of the destination IP address. If the bits match, the destination computer resides on the subnet that adapter is connected to, and the computer can send the data directly to that computer using that adapter.

But the Data Link Layer, which IP uses to actually send the data, doesn't know anything about IP addresses, so IP needs to get the Machine Address of the destination computer on that LAN before it can put the IP data into a Data Link Layer frame and send it out. The Internet Protocol uses another protocol, called the Address Resolution Protocol (ARP), which every computer on an IP subnet hears and can respond to, to translate IP addresses into Machine Addresses.

ARP works by filling a Data Link Layer frame with a special packet that every computer on the LAN will receive. As you saw in the Data Link Layer section, the frame type for Ethernet for an ARP packet is 0806. Figure 3.8 shows the structure of an ARP packet (which is contained in the data portion of the Data Link Layer frame).


Figure 3.8: An ARP/RARP packet is a broadcast request for data.

The fields for an ARP/RARP packet are defined as follows (this example is based on Ethernet; other Data Link Layer packets may have different sized values):

  • Hardware Type (two bytes)—The type of hardware address (1 for Ethernet)

  • Protocol Type (two bytes)—The protocol type (0x0800 for Internet Protocol)

  • Hardware Size (one byte)—The size of the hardware addresses in bytes

  • Protocol Size (one byte)—The size of the protocol addresses in bytes

  • OP (two bytes)—The type of operation: either ARP Request, ARP Reply, RARP Request, or RARP Reply

  • Sender Hardware Address (six bytes for Ethernet)—The Ethernet address of the ARP packet sender

  • Sender Protocol Address (four bytes for IP)—The IP address of the ARP packet sender

  • Target Hardware Address (six bytes for Ethernet)—The Ethernet address of the ARP packet sender

  • Target Protocol Address (four bytes for IP)—The IP address of the ARP packet sender

To get the hardware address of a computer in a local subnet, a computer sends out (in a broadcast Data Link Layer frame) an ARP packet with an OP value of 1 and everything but the Target Hardware Address filled in (because only the sender needs to know that). Since the frame is broadcast to all stations on the LAN, all of the computers will receive it, but only the one with the matching Target Protocol Address responds by changing the OP value of the packet to 2, filling in the Target Hardware Address, and broadcasting the packet back.

The computer does not perform an ARP for every IP packet it sends out. The computer maintains a table of IP addresses and corresponding hardware addresses, and only when the computer does not have an entry for an IP address in its subnet does it send out an ARP packet and wait for a reply. The rest of the time it just uses the value it has in its ARP table.

When the computer has the hardware address corresponding to an IP address for a packet, the computer sends the IP packet to the destination in a Data Link Layer frame addressed to just that computer. That computer receives the frame, notes that the destination IP address is its own, and processes the packet according to the protocol information in the header.

Note: Why does IP bother with ARP and machine addressing when Ethernet is a broadcast medium anyway? After all, every Ethernet adapter in the LAN can listen to all the packets, not just ones with its own Machine Address as the intended recipient. Why not just send all of the IP packets as broadcast frames, and let the IP protocol on each computer sort them out?

The reason is two-fold: Ethernet hardware can be much more efficient than the IP protocols at determining which frames should be ignored and which ones should be processed, and Ethernet networks are often partitioned into many small collision domains by bridges and switches in order to decrease contention and increase available bandwidth. Broadcasting defeats this optimization by spilling traffic over into collision domains that contain neither the sender nor the recipient.

Communicating with a Distant Host But what if the destination IP address does not lie on any LAN the computer is connected to? The computer could send out an ARP message, but nobody would reply.

If none of the network addresses of any of the computer's adapters exactly match the destination IP address (as defined by the subnet mask for that adapter), then the computer needs to know where to send the packet so that it will eventually get to its destination. Since it can't send the packet directly to the destination, it needs to know where else it can send the packet that will eventually get it there.

For most networks, that intermediate location is the gateway host or router. As described in the section above on network addresses, subnet masks, and station addresses, the gateway is a machine that has adapters residing on at least two networks. Most LANs connected to the Internet will have one gateway, but some may have more than one. Just one of them should be configured to be the default gateway, where computers in the LAN send an IP packet when they don't otherwise know what to do with it.

All your standard computer needs then is a default gateway entry to send non-local packets to. The gateway can then figure out where to send the packet from there. This means, of course, that the gateway requires a bit more configuration than computers with just one network adapter. The configuration information goes in a routing table that tells the router what to do with packets it receives that have an ultimate destination of somewhere else.

A routing table is simply a list of station and network addresses and a corresponding gateway IP address further along to which it should send packets that match that station or network address. Figure 3.9 shows a sample routing table.


Figure 3.9: The routing table instructs the gateway how to forward IP packets.

The simplest gateway configuration requires just three entries—one for itself ( is IP shorthand for the computer itself), one for IP addresses in the interior LAN, and one for all other IP addresses (its own default gateway when it doesn't know what to do with an IP address).

Things get a little more complicated when you have a more complex network structure behind your gateway, but the principle remains the same—the routing table explicitly lists all of the networks behind the gateway and where the next closest (internal) gateway is for those internal networks, and the routing table lists a default gateway entry to send packets to that the gateway otherwise doesn't know what to do with. See figure 3.10 for a more complex routing example.


Figure 3.10: A gateway should know how to explicitly route to any internal network and also have a default external gateway to send packets it doesn't know what to do with otherwise.

A gateway or router processes a packet as follows (see Figure 3.11 for a graphical view):

  1. Accept Data Link Layer frame.

  2. Verify CRC strip frame header and trailer; discard if invalid.

  3. Verify IP header checksum; discard if invalid.

  4. Check IP parameters; discard if invalid or does not match policy.

  5. Decrease the Time to Live field in the packet. If the field now reads 0, discard the packet and send an ICMP message back to the sender of the packet.

  6. Check the destination IP address against the router's own IP addresses; if there is a match, process the IP packet locally.

  7. Find the network or host entry in the routing table that matches the destination IP address of the packet. If there is no match, use the default entry in the routing table.

  8. Create a new Data Link Layer frame for the packet with the hardware address of the next closest gateway to the destination (or the hardware address of the destination itself if it is on the same LAN).

  9. Send the Data Link Layer frame.

The nice thing about IP routing is that no one computer needs to know how to get the IP packet all the way to the destination—all each computer needs to know is how to get the packet to the next computer on the way. So long as there are no problems along the way, the packet will eventually get to its destination.

ICMP Messages

But what if there is a problem? Let's say, for example, that the default network link for your connection to the Internet has gone down, and (while the network technicians frantically try to get it up) an alternate host has been provided to route data to and from the Internet.

The gateway that would otherwise forward your IP packet to its destination needs a way of telling your computer about the network problem. ICMP packets are the Internet Protocol's way of sending network status information back to the sender. With ICMP, network devices can identify routing problems, congestion problems, quality of service problems, and more. Table 3.1 shows the types of ICMP messages your computer can send or receive.

Table 3.1 ICMP Message with general message type, specific message code, and whether the message is a query or a response to a network event.







Echo reply




Destination Unreachable:




Network Unreachable




Host Unreachable




Protocol Unreachable




Port Unreachable




Too Big/Can't Defrag




Source Route Failed




Destination Network Unknown




Destination Host Unknown




Source Host Isolated (obsolete)




Destination Network Prohibited




Destination Host Prohibited




Network Unreachable for TOS




Host Unreachable for TOS




Prohibited by Filtering




Host Precedence Violation




Precedence Cutoff in Effect




Source Quench








Redirect for Network




Redirect for Host




Redirect for TOS and Network




Redirect for TOS and Host




Echo Request




Router Advertisement




Router Solicitation




Time Exceeded




TTL Exceeds 0 During Transit




TTL Exceeds 0 During Reassembly




Parameter Problem




IP Header Bad




Required Option Missing




Timestamp Request




Timestamp Reply




Information Request (obsolete)




Information Request Reply (obsolete)




Address Mask Request




Address Mask Reply


IP identifies by the Protocol field what kind of packet is being transmitted (see Fig-ure 3.5). ICMP is one of those kinds of packets. The structure of an ICMP packet is shown in Figure 3.11.


Figure 3.11: ICMP messages share a common header format with Type, Code, and Checksum fields.

So what happens when your computer tries to send a packet through the obstructed gateway? The steps that the gateway and your computer go through are as follows:

  1. Your computer sends a packet with the frame address of the gateway machine, but with the IP address of an exterior computer.

  2. The gateway machine reads the packet from the frame and decodes it.

  3. The gateway machine discards the packet (because the packet cannot be forwarded) and creates an ICMP message.

  4. If the gateway has not been configured to redirect traffic to an alternate gateway, it will send a host-unreachable or network-unreachable ICMP packet back to the sending computer.

  5. If the gateway has been configured to redirect traffic, it will send an ICMP redirect packet to the sending computer.

  6. The sending computer receives the ICMP packet and decodes it.

  7. If the packet is a host- or network-unreachable packet, it generates an error message for the program that attempted to send the data.

  8. If the packet is an ICMP redirect packet, it resends the data using a different gateway.

This sort of network reporting and redirection can happen at any point in the string of packet "hops" from the sending computer to the receiving computer. The operations performed are the same.

ICMP Vulnerabilities

ICMP packets do not include any authentication method for the recipient of the message. A clever hacker can forge ICMP packets and cause havoc in an unprepared network. The two greatest threats from malicious ICMP packets are denial-of-service attacks and impersonation or man-in-the-middle attacks.

A forged destination-unreachable packet can isolate a computer from necessary services. Echo Request has been used by hackers to crash computers with a naive implementation of the ICMP protocols.

Once a computer that performs an important service (such as a DNS server, file server, or web server) is out of the way, an ICMP redirect packet can point unwitting victims to the hacker's computer, where the hacker can accept authentication information (usernames, passwords, etc.).

Routers and Route Discovery

Routers (sometimes called gateways) link IP subnets together. It is up to the router to send IP packets toward their destinations when the end computer resides outside of the subnet. How does the router know where to send the packet?

For small networks with just one or two routers the answer is easy—the network administrator enters routes by hand into the router. This is called static routing because the route information does not change automatically according to network conditions—it is up to the administrator to change the router's settings when a new subnet is added or a network link goes down.

The router must have IP forwarding rules that account for any possible IP address because there's no telling which computer, locally or on the Internet, a client computer may want to talk to. On a simple network the rules are correspondingly simple. On a one-router network, for example, the rule may be as follows: If the destination address is on the local subnet, then send the packet directly to its destination, otherwise send it to an upstream router.

Dynamic Routing In larger networks, the static routing tables get to be a real hassle to maintain. In a university with every college maintaining its own LAN, or a corporation with each department having a different subnet, the configuration of the network is always changing and the router tables must be updated to reflect those changes. In addition, the routers must have a consistent view of the network.

The IP routing protocols reduce the work required to keep those routing tables updated and consistent. The protocols enable the routers to automatically update each other of network changes such as new routes between subnets or network links that are down and must be routed around. The administrator makes a change in just one router's table, and the change will propagate automatically to all of the other routers in the network.

Interior Gateways vs. Exterior Gateways Before you take a closer look at the routing protocols, you need to understand that there are two categories of routers—interior routers (or gateways) that reside entirely within your organization, and exterior gateways that convey IP traffic between your network and the Internet (or any other organization's network). The difference between these two types of gateways is primarily a matter of trust; you want routing changes within your network to move from one router to another with minimum hassle, while you may not want routing information from outside your network to be implemented on your border routers unless it comes from an authorized source and until you've had a chance to review it first.

RIP v1 and v2, IGRP The earliest routing protocol in wide-spread use is called (imaginitively enough) Routing Internet Protocol, or RIP. Routers using version 1 of the protocol simply broadcast their entire routing table every 30 seconds on each of the subnets to which that router has network adapters connected. When a router receives a RIP packet, it compares the contents with its own table and updates its table with new information from the packet (modified, of course, to include the extra hop that it takes to get to the router that sent the RIP packet). It removes routes that haven't been updated for a while, so bad routes eventually disappear from the table.

RIP is a distance-vector protocol because it keeps track of the distance (number of network hops) that it takes to get to a destination listed in the routing table. When multiple routes to the same destination show up in the table, the route with the least number of hops is used to send the packet on its way, regardless of the speed of the network links used in the route. RIP packets are broadcast using UDP.

RIP v1 had a significant security problem—there was no authentication included in transmitted RIP packets, and received RIP packets weren't checked to make sure they came from authorized routers. Anybody could forge a RIP packet and reconfigure your router for you. RIP also has the problem that in complex networks with large routing tables and lots of routers, the RIP broadcasts can soak up a lot of network bandwidth. Also, it can take a long time for network changes to propagate through all of the routers in a complex network using RIP.

RIP v2 fixes the authentication problem by including passwords in the RIP packets. The router discards any RIP packets without a correct password. The bandwidth and convergence delay problems of RIP remain, however.

Cisco developed for their high-performance routing hardware a new protocol called IGRP, which was endorsed by the IETF. IGRP maintains more link information, such as bit rate and cost, allowing the routers to make better decisions about possible routes. IGRP has a 90-second update interval, however, and it can take even longer than with RIP for IGRP routers to converge on a consistent set of routing tables.

OSPF In 1988 the Internet Engineering Task Force (IETF) came out with a protocol designed to replace RIP for routing within a single organization's network (i.e. an IGP). That protocol was called Open Shortest Path First, or OSPF. It is a more complicated protocol than RIP, but has reduced network bandwidth use and speedier convergence. This makes RIP a much better protocol for routing in medium-to-large networks.

OSPF is a link-state protocol, unlike RIP (which is a distance-vector protocol). OSPF records in its routing table the state of the link between it and any other routers it can directly connect to, along with those IP domains that its network adapters reside on. In addition to status, it records link characteristics such as bandwidth, cost, and type-of-service restrictions. OSPF uses IP multicast as well as broadcast for transmitting routing table updates. It also performs load-balancing, which sends successive IP packets along different routes to the same destination to reduce congestion on the network.

Route updates in an OSPF routed network propagate much more quickly than they do in a RIP routed network. After the initial update, only the difference between one update and the next is transmitted. This is unlike RIP, which transmits the entire table each update. Also, OSPF imposes a hierarchy on the routers in the network, with Designated Routers for each subnet, a Backbone Router for the network backbone, and Autonomous System Boundary Routers for links between separately administered systems. The hierarchy makes administration a little more difficult, but the centralized collection and redistribution of route data allows the routers to converge on a consistent view of the network in a matter of seconds rather than minutes or hours for a large network.

OSPF, like RIP v2, authenticates the routing packets exchanged between the routers, making it much more difficult for network intruders to subvert them. In addition, the OSPF packets contain sequence numbers, making forgery difficult even if the authentication mechanism is compromised.

Note: You should block all RIP, IGRP, and OSPF traffic at the firewall. Because your firewall will be the only connection to the Internet (otherwise, why have a firewall?), you have no need to maintain route information from the Internet on your internal routers. The only Internet configuration your routers need is that IP packets with destinations exterior to your entire protected network should go to the firewall.

BGP and IDRP Unless you run the network for an Internet Service Provider or Network Access Point, you don't need to worry about Exterior (or Border) Gateway Protocols. We'll touch on them here, however, for the sake of completeness.

The original Border Gateway Protocol was designed for the routers at the edges of private networks. These routers must maintain huge routing tables because the Internet is a large place, and there's no telling where on the Internet an IP subnet is going to be until the router containing the subnet announces the fact and the route is propagated across the public network.

BGP is a distance-vector protocol because it maintains hops like RIP. However unlike RIP, BGP uses TCP rather than UDP to exchange routing information.

With the expansive growth of the Internet, BGP began to show its age and its na ve security assumptions. The IETF developed an Inter Domain Routing Protocol (IDRP) to replace BGP for routing between private networks. Like OSPF, IDRP is a link-state routing protocol, which allows multiple routes to destination, and records link attributes such as throughput, delay, and security characteristics. It also supports authentication of the exchanged route data and supports a hierarchical management of domains called Domain Confederations.

Case Study: Where Is the Data Coming From?

Until you actually take a look at a protocol analyzer, you may not be aware of the importance of knowing exactly how TCP/IP gets data from one place to another. But when you do see all those bytes flowing in and out of your computer, even when (from the user's point of view) the computer isn't actually doing anything, you'll feel much more comfortable knowing which bits are natural and which ones are suspect.

One customer, who manages a medium-size LAN connected to the Internet as well as a number of remote LAN clients that connect over the Internet, called one day after seeing the lights on his modem though he wasn't actually using the computer. He observed that even when he wasn't transferring files or browsing the Web, every second or so the modem lights would flash. Instantly his imagination conjured visions of hackers and Trojan horses burrowing into his hard-drive and sending sensitive corporate data out over the network. An examination of the TCP/IP statistics of his computer (he is relatively knowledgeable in networking) showed that no IP packets were going out.

What the manager did not know was that PPP is a true Data Link Layer protocol, and some PPP implementations (including his) periodically exchange link data even when no protocol data is being transferred over the link. His mind was set at ease after he closely examined what exactly was being sent and why.

About the Authors

Matthew Strebe, MCSE, is the author of NT Server 2 24seven and co-author of NT 4 Network Security (both from Network Press) and owner of Netropolis, a network-integration firm specializing in high-speed networking, security, and Windows NT. Strebe's colorful career includes hacking his high school and a stint in the U.S. Navy where he installed the Navy's first fiber-optic LAN aboard a ship.

Charles Perkins, MCSE, is co-author of NT 4 Network Security and six Network Press MCSE Study Guides. Formerly director of Computing Services for the University of Utah College of Law, he is now a consultant specializing in Windows NT and security.

Copyright © 2000 Sybex, Inc.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Click to order