IPSec (2nd Edition)

Chapters 3 and 4 discussed the IPSec architecture and the relationship between the various protocols that are traditionally referred to as "IPSec" and databases such as the SADB and SPD, but omitted the details of how the policies are enumerated in the SPD and get defined and installed. IPSec allows for very complex policy definitions. Because of its notion of selectors, the policy rules applied to inbound and outbound packets is very rich. Selectors can be gross an entire subnet or fine a specific port and protocol to a specific host.

The design for a policy definition and management system must not constrain the richness of IPSec. Therefore, there are several requirements imposed on any policy system. These requirements are very high level because there is no single mechanism for policy definition and management. Different IPSec implementations will have different constraints imposed on them for instance, most routers do not have a hard disk or a floppy drive and these constraints will dictate how policy is managed.

As IPSec is neither host-oriented nor router-oriented, the requirements for policy definition should be broad enough to encompass both of them. These are not an all-encompassing set of policy requirements but merely a large set that any system will abide by:

• Ability to configure multiple policies per host: It must be possible to specify security policy for an individual host. The policy may reside on the host or it may reside on a router or firewall in the network. The policy may specify end-to-end security (that is, it is policy between two hosts) or it may specify policy for this host to another network. What is important is that policy with the granularity of a host must be able to be expressed.

• Ability to configure policy per network: It must be possible to specify security policy for an entire network. This policy may, likewise, reside on a host or it may reside on a router or firewall in the network. The network policy may take the form of a network and subnet (this is the most important representation because this is how routing decisions are made on both hosts and routers), or the form of a range of addresses. The important thing is that uniform security policy can be assigned to all entities on a network.

• Ability to configure security at the granularity of an application: Application's traffic is uniquely identified on a network by the tuple <source and destination address, source and destination port, and protocol>. The addresses themselves may be explicit addresses or subnets. For instance, it must be possible to protect all telnet (tcp port 23) traffic destined for a particular subnet. What is important is that it must be possible to specify security policy to the granularity of port and protocol.

• Ability to specify multiple protocols per flow^[1]: It must be possible to specify that, for instance, AH and ESP and IPPCP (see Chapter 11) be used on a targeted flow. Previous requirements dealt with how to identify targeted traffic. This requirement deals with specifying what to do to that traffic once its been identified. It must be possible to apply more than one security protocol to targeted packets that represent a flow.

  ^[1] A flow is always identified by the tuple <src, dst, src port, dst port, protocol>.

• Ability to specify the desired action for each flow: drop, protect, or pass.

• Ability to configure tunnels of more than one level deep: It must be possible to specify a policy that requires nested tunnels. While this will usually be the result of combining various distinct policy requirements into a single unified network policy, it may also be desirable to dictate nested tunnels directly.

• Ability to support different IKE identities for access and authentication: IKE can handle IP addresses, Distinguished Names (DNs), and Fully Qualified Domain Names (FQDN). However, IPSec protocols handle only IP addresses and the policy has to be configured per IP node. This ability is useful for access control. A node can be configured to accept connections by a particular user or by a set of users belonging to a particular domain.

• Ability to selectively disable automated key management: Support for manual keying is required by IPSec and it must be possible to define policy such that manually-keyed SAs are used instead of IKE to protect certain traffic.

• Ability to support multiple security options. This is a very important requirement. IKE provides the ability to offer multiple choices during negotiation so that the two peers can agree on something they both support. For example, host A may want to use ESP and 3DES with nodes that implement 3DES. However, with nodes that do not support 3DES, it may choose to communicate using DES instead of dropping the connection.

• It must be possible to support all of the aforementioned requirements simultaneously.

The various components of a policy system are discussed below.