10.6. Policies

In this section, we discuss how IPsec decides which datagrams to send through a VPN. We might think that a transport-mode VPN, such as that in Figure 10.3, would simply send all datagrams destined to the peer host through the VPN, and, indeed, this is possible. It's also possible, however, to have much finer granularity in the selection of datagrams that the VPN should carry. Similarly, we might think that a tunnel-mode VPN between two networks, such as that in Figure 10.5, would at most carry datagrams that had the peer network as a destination, but this is not correct. The peer network might contain a router or another security gateway that will route the datagram to a completely different network, so the VPN might carry datagrams whose final destinations are not on the peer network.

Thus, IPsec can select datagrams with a granularity that is both finer and coarser than we might expect. A rule stating which datagrams should be sent through an IPsec VPN is called a policy. A simple policy for a transport-mode VPN might simply require that every datagram addressed to the peer host go through the VPN. A more complex policy might say that only TCP traffic addressed to the peer should be sent through the VPN. An even more complex policy might specify that only UDP traffic with a specific destination port should travel through the VPN. Obviously, tunnel-mode VPNs provide for the possibility of even more types of policies.

The possibility of fine-grained selection means that we can have multiple VPNseven between two fixed hoststhat each carry a different type of traffic. So although Figure 10.3 shows a single VPN between the two hosts, and Figure 10.5 shows a single VPN between the two gateways, we can have multiple VPNs if the situation warrants. For example, if the DNS server for the remote network of Figure 10.5 is on the home network, we might want to establish an AH VPN to carry DNS traffic to prevent attacks based on forged DNS information. Although we want to authenticate that the DNS responses are coming from the correct DNS server and that they haven't been tampered with, it might not be worthwhile encrypting this traffic. At the same time, we might want to have another VPN for TCP and UDP traffic that does encrypt its datagrams.

A moment's thought makes clear that when applying a policy, IPsec must examine the IP header and, possibly, the transport header to see whether the datagram satisfies the conditions in the policy. The datagram fields that IPsec can use to make its decisions are called selectors.

We're considering only AH and ESP here. IKE has additional selectors, such as host and user identity, that it can use to decide whether to initiate a VPN.

RFC 2401 lists the following fields as possible selectors:

• Destination address

• Source address

• Security label for networks that support them (see RFC 2401 for details)

• Transport-layer protocol

• Source port

• Destination port

So far, we have talked about policies as a way of determining which datagrams should be sent through the VPN. The policy mechanism is more general in that associated with each policy is an action. That action can be to drop the datagram, to bypass IPsectransmit the datagram normallyor to apply one or both of the IPsec protocols. Thus, a policy is a rule that specifies the disposition of each matching datagram entering or leaving a VPN endpoint. RFC 2401 mandates that any datagram that does not have a matching policy must be dropped, but many implementations have a default policy that applies to datagrams that don't match any explicit policies. This is convenient when we have a VPN to another network, say, and want to send traffic to that network through the VPN but still send all other traffic out normally.

As with security associations, a node's IPsec policies are maintained in a database, called the security policy database (SPD). The SPD is consulted during output processing to determine the disposition of each datagram on the output queue. If the matching policy specifies that IPsec should be applied, there will be a pointer to the appropriate SA or SA bundle. If no SA or SA bundle exists, IPsec will invoke IKE to create one unless manual keying is being used, in which case the datagram will be dropped.

The SPD is also consulted for incoming datagrams. After the decryption and/or authentication of the datagram, the SPD is checked to ensure that the appropriate IPsec processing was performed.