Worth repeating is that an access control rule can be stated only using the subjects, objects, and operations that the reference monitor understands. At the hardware device level of the network, access control is specified in terms of hardware IDs. At the next higher layer, rules are defined in terms of network addresses or host names. Any concept that is understood at a particular layer is fair game for appearing in an access control rule. For example, if network traffic contains timestamps, one can declare an access control rule that limits inbound network traffic from a range of network addresses only within a given time interval. This is only an example, though. Unless the incoming timestamp can be trusted, the rule is probably of little value.

Application level access control can be configured independently or in conjunction with network level limits. Any subjects or objects that the application regulates could appear in the access control rule. A packet filter rule might limit whether telnet traffic is permitted between two networks, but the telnet application itself can further control which users in the network are allowed to telnet between the networks. Packet filters work at a level of the network stack that does not know about users or groups. Only the application knows about these concepts.

Someone might want to make the packet filter access control layer smarter and try to imbed some of the application’s intelligence into the packet layer. If this is possible, the packet filtering code can make more granular access control decisions. In practice this solution is not scaleable, and both packet filtering and application level access control are needed in networks. The packet filter operates at a lower network layer than the application. To make access control decisions that are as complex as an application, the lower packet layer would need to incorporate a good deal of the application’s knowledge. You can see that this practice is impractical and that the proper solution is to keep application level access control decisions in the application itself.

The Importance of Naming

At the heart of network security is the requirement that each entity in the network, such as each computer, be uniquely identifiable. This process is no different from the way I&A worked for users and groups. Recall that some type of repository for user names is stored on the local computer or in a network-wide repository. The security officer responsible for adding users and groups to this repository determined the universe from which names and UIDs were assigned. The same requirement exists for network I&A. Some naming authority must be responsible for assigning network IDs to entities that need to communicate in the network.

When the network is entirely private, and no communications are needed beyond the company’s boundaries, the network administrators can assign arbitrary, but related, network IDs. In practice, this is rarely the case and most companies are connected to the Internet in some fashion. Communicating with other entities on the Internet requires adherence to naming conventions regulated by the Internet Engineering Task Force. The Domain Name System (DNS) is the most widely used naming scheme on the Internet today. DNS supports a hierarchical namespace with different authorities responsible for various segments of the name tree. Obtaining assigned and preferred names is an out-of-band process regulated by the IAB for networks attached to the Internet. Naming of nodes in private networks is the responsibility of the site network administrators.

Before widespread connectivity to the Internet, some network administrators assigned arbitrary network addresses to internal nodes. Rather than reassigning a new number to hundreds or thousands of nodes, the addressing scheme was left unchanged. You could find your internal node had the same network address that was officially assigned to another company’s public Web server. This practice led to some humorous situations.

A local user running inside a secure network relies on the routers and gateways to correctly delivery packets to their destination. If someone inside your private network tried to send you a message, your buddy could end up communicating with the gateway for another company if it had the same IP address. This accident might happen if your node is down or if someone misconfigured your company’s routers or gateways.

The Internet Protocol (IP)

The Internet is a collection of hundreds of thousands of computers and networks. A vital component of this infrastructure is the network software layer known as IP (Postel, 1981). The Internet has its roots in an open and trusting environment. During the early days, not many sites could afford computers or the network connections to the Internet. The first version of the Internet was the Advanced Research Projects Agency Network (ARPAnet), which was designed as a means for researchers to easily exchange research information. The various network nodes responsible for routing Internet traffic were tightly controlled and administered. However, the IP traffic itself was assumed to be trustworthy.

Morris (1985) and Bellovin (1989) were among the first to publicly identify shortcomings in the IP layer itself, although many weaknesses already were known in Internet layers above IP. Most of the attacks that these two authors described have occurred numerous times on the Internet. The weaknesses and how they are exploited will be described shortly. As a result of these problems and others in the IP protocol, a new set of standards for IP security (IPsec) have been defined and implemented. Most firewalls today provide a virtual private network (VPN) using IPsec. Before you can understand how IPsec improves upon weaknesses in IP, take a look at the original standard.

As Figure 4.3 shows, the IP layer sits on top of the network device drivers. Each entity in the network is identified by a 32-bit address. Thus, an IP connection specifies at least a 32-bit source address and a 32-bit destination address for the packet. IP Version 6 expands this original limited definition by providing for variable length IP addresses which require that the packet header include a length field for the address. Because the Internet was quickly running out of valid addresses, this new approach was needed. Regardless of the version of IP running, the important point is that the protocol uses a network address to uniquely identify communicating entities. As noted previously, in a private network, addresses can be arbitrarily chosen. Addresses that are publicly visible on the Internet are controlled by a registration authority which governs the Internet.

Figure 4.3  Layers in the IP standard.