IPv4 was designed with a network of relatively trusted users in mind where the network infrastructure was likely to be relatively secure and the information that was being transmitted was relatively public. Consequently, it did not seem important at the time to include security features, like non-repudiation or authentication, directly into the protocol.
But over its lifetime, the way the IPv4 Internet has been used has changed radically. The huge number of users of the Internet mean that trusting them all is simply not an option. The network infrastructure itself now involves cooperation between a large number of public and private organizations, with wildly differing agendas. Most significantly, the data that is being transmitted on the Internet now is often commercially, financially or personally sensitive. From a security perspective, IPv4 is way out of its depth.
As a consequence of its origin, security in the IPv4 world has not been provided by the basic, underlying transport protocol. Instead, as the need has arisen, application level security (one time passwords, SSH, TSIG, etc.) or manipulation of the protocols (packet filters and firewalls) have been introduced to provide security. These solutions have often had an ad-hoc character, and have suffered the attendant limitations: different management schemes, different levels of security provided, and duplicated effort. SSL, the most successful of these compromises, has been designed in such a way that it can be applied in situations other than HTTP, for which it was originally devised.
We'll briefly consider the implications of security not being provided by IPv4 itself—particularly in the case of DNS—but the same issues apply to most IP-based protocols, and protocols underlying IP, such as ARP (see the Section 1.4 later in this chapter).
From a security perspective, the gods have not smiled on DNS over IPv4. Most queries are conducted over UDP. The UDP protocol, while being lightweight and kind to small CPUs, is easily tampered with. The protocol fields can be guessed in many cases, and where they can't, it's possible to use a flooding technique to populate the wire with candidate packets, one of which may be mistaken for the real one. DNS itself has a few additional protections, but they do not amount to much. To fake a response to a DNS request you must correctly guess an ephemeral port number and a query-ID. In the case of DNS the port numbers are often easy to determine and some DNS implementations produce guessable query-IDs.
If you can fake DNS responses, it is then possible to direct people to the wrong host. If a convincing enough fake of some e-commerce site has been put up on an attacker-controlled web page, passwords or credit card numbers might then be stolen very easily. In the case of the web, some protection is possible if you are using SSL, but if a mail server were impersonated for example, few would notice that email had gone to the wrong destination until it was too late.
Table 1-2. 7 Layer OSI model
Applications and associated protocols
Data syntax and semantics
Session management for applications
Packetization, retransmission, ...
How subnets interoperate
Management of interface
Ethernet (upper level)
Physical operation of the medium
Ethernet over UTP