Computer Networking: A Top-Down Approach Featuring the Internet Chapter 8 -- 7.1: What is Network Security?

7.1: What is Network Security?

Let us introduce Alice and Bob, two people who want to communicate "securely." This being a networking text, we should remark that Alice and Bob may be two routers that want to securely exchange routing tables, two hosts that want to establish a secure transport connection, or two e-mail applications that want to exchange secure e-mail--all case studies that we will consider later in this chapter. Alice and Bob are well-known fixtures in the security community, perhaps because their names are more fun than a generic entity named "A" that wants to securely communicate with a generic entity named "B." Illicit love affairs, wartime communication, and business transactions are the commonly cited human needs for secure communications; preferring the first to the latter two, we're happy to use Alice and Bob as our sender and receiver, and imagine them in this first scenario.

7.1.1: Secure Communication

We said that Alice and Bob want to communicate "securely," but what precisely does this mean? Certainly, Alice wants only Bob to be able to understand a message that she has sent, even though they are communicating over an "insecure" medium where an intruder (Trudy, the intruder) may intercept, read, and perform computations on whatever is transmitted from Alice to Bob. Bob also wants to be sure that the message that he receives from Alice was indeed sent by Alice, and Alice wants to make sure that the person with whom she is communicating is indeed Bob. Alice and Bob also want to make sure that the contents of Alice's message have not been altered in transit. Given these considerations, we can identify the following desirable properties of secure communication:

Secrecy. Only the sender and intended receiver should be able to understand the contents of the transmitted message. Because eavesdroppers may intercept the message, this necessarily requires that the message be somehow encrypted (its data disguised) so that an intercepted message cannot be decrypted (understood) by an interceptor. This aspect of secrecy is probably the most commonly perceived meaning of the term "secure communication." Note, however, that this is not only a restricted definition of secure communication (we list additional aspects of secure communication below), but a rather restricted definition of secrecy as well. For example, Alice might also want the mere fact that she is communicating with Bob (or the timing or frequency of her communications) to be a secret! We will study cryptographic techniques for encrypting and decrypting data in Section 7.2.
Authentication. Both the sender and receiver need to confirm the identity of other party involved in the communication--to confirm that the other party is indeed who or what they claim to be. Face-to-face human communication solves this problem easily by visual recognition. When communicating entities exchange messages over a medium where they cannot "see" the other party, authentication is not so simple. Why, for instance, should you believe that a received e-mail containing a text string saying that the e-mail came from a friend of yours indeed came from that friend? If someone calls you on the phone claiming to be your bank and asking for your account number, secret Personal Identification Number (PIN), and account balances for verification purposes, would you give that information out over the phone? Hopefully not. We will examine authentication techniques in Section 7.3, including several that, perhaps surprisingly, also rely on the cryptographic techniques we study in Section 7.2.
Message integrity. Even if the sender and receiver are able to authenticate each other, they also want to ensure that the content of their communication is not altered, either maliciously or by accident, in transmission. Extensions to the checksumming techniques that we encountered in reliable transport and data link protocols will also be studied in Section 7.4; these techniques also rely on cryptographic concepts from Section 7.2.

Having established what we mean by secure communication, let us next consider exactly what is meant by an "insecure channel." What information does an intruder have access to, and what actions can be taken on the transmitted data? Figure 7.1 illustrates the scenario.

Figure 7.1: Sender, receiver, and intruder (Alice, Bob, and Trudy)

Alice, the sender, wants to send data to Bob, the receiver. In order to securely exchange data, while meeting the requirements of secrecy, authentication, and message integrity, Alice and Bob will exchange both control messages and data messages (in much the same way that TCP senders and receivers exchange both control segments and data segments). All or some of these messages will typically be encrypted. A passive intruder can listen to and record the control and data messages on the channel; an active intruder can remove messages from the channel and/or add messages into the channel.

7.1.2: Network Security Considerations in the Internet

Before delving into the technical aspects of network security in the following sections, let's conclude our introduction by relating our fictitious characters--Alice, Bob, and Trudy--to "real-world" scenarios in today's Internet.

Let's begin with Trudy, the network intruder. Can a "real world" network intruder really listen to and record network messages? Is it easy to do so? Can an intruder actively inject or remove messages from the network? The answer to all of these questions is an emphatic yes. A packet sniffer is a program running in a network-attached device that passively receives all data-link layer frames passing by the device's network interface. In a broadcast environment such as an Ethernet LAN, this means that the packet sniffer receives all frames being transmitted from or to all hosts on the LAN. Any host with an Ethernet card can easily serve as a packet sniffer, as the Ethernet NIC needs only be set to promiscuous mode to receive all passing Ethernet frames. These frames can then be passed on to application programs that extract application-level data. For example, in the Telnet scenario shown in Figure 7.2, the login password prompt sent from A to B, as well as the password entered at B are "sniffed" at host C. Packet sniffing is a double-edged sword--it can be invaluable to a network administrator for network monitoring and management (see Chapter 8) but also used by the unethical hacker. Packet-sniffing software is freely available at various WWW sites, and as commercial products. Professors teaching a networking course have been known to assign lab exercises that involve writing a packet-sniffing and application-level data reconstruction program.

Figure 7.2: Packet sniffing

Any Internet-connected device necessarily sends IP datagrams into the network. Recall from Chapter 4 that these datagrams carry the sender's IP address, as well as upper-layer data. A user with complete control over that device's software (in particular its operating system) can easily modify the device's protocols to place an arbitrary IP address into a datagram's Source Address field. This is known as IP spoofing. A user can thus craft an IP packet containing any payload (upper-layer) data it desires and make it appear as if that data was sent from an arbitrary IP host. Packet sniffing and IP spoofing are just two of the more common forms of security "attacks" on the Internet.

A third broad class of security threats are denial-of-service (DoS) attacks. As the name suggests, a DoS attack renders a network, host, or other piece of network infrastructure unusable by legitimate users. Typically, a DoS attack works by creating so much work for the infrastructure under attack that legitimate work cannot be performed. In a so-called SYN flooding attack [CERT SYN 1996], the attacker deluges a server with TCP SYN packets, each having a spoofed IP source address. The server, not being able to differentiate between a legitimate SYN and a spoofed SYN, completes the second step of the TCP handshake (see Section 3.5.7) for a spoofed SYN, allocating data structures and state. The third step of the three way-handshake is never completed by the attacker, leaving an ever-increasing number of partially open connections. The load of SYN packets to be processed and depletion of free memory eventually brings the server to its knees. A "smurf" DoS attack [CERT Smurf 1998] operates by having a large number of innocent hosts respond to ICMP echo-request packets (see Section 4.4.5) that contain a spoofed source IP address. This results in a large number of ICMP echo-reply packets being sent to the host whose IP address is being spoofed. RFC 2267 and RFC 2644 outline several simple steps that can be taken to help prevent these and other DoS attacks.

Various network attacks and security threats are discussed in the collection of essays [Denning 1997]. A summary of reported attacks is maintained at the CERT Coordination Center [CERT 2000]. See also [Cisco Security 1997; Voydock 1983; Bhimani 1996].

Having established that there are indeed real bogeymen (a.k.a. "Trudy") loose in the Internet, what are the Internet equivalents of Alice and Bob, our two friends who need to communicate securely? Certainly, "Bob" and "Alice" might be human users at two end systems, for example, a real Alice and a real Bob who really do want to exchange secure e-mail. They might also be participants in an electronic commerce transaction. For example, a real Alice might want to securely transfer her credit card number to a WWW server to purchase an item online. Similarly, a real Alice might want to interact with her bank online. As noted in RFC 1636, however, the parties needing secure communication might also themselves be part of the network infrastructure. Recall that the Domain Name System (DNS, see Section 2.5), or routing daemons that exchange routing tables (see Section 4.5) require secure communication between two parties. The same is true for network management applications, a topic we examine in Chapter 8. An intruder that could actively interfere with, control, or corrupt DNS lookups and updates, routing computations, or network management functions could wreak havoc in the Internet.

Having now established the framework, a few of the most important definitions, and the need for network security, let us next delve into cryptography, a topic of central importance to many aspects of network security.