It was mentioned in previous chapters that policy determines the security services afforded to a packet and the treatment of a packet in the network. However, the issue of policy representation and management of IPSec connections were not discussed. We will address some of these issues in this chapter.
Policy is difficult to describe and define. It is the fuzzy middle between a human desire (“I want to encrypt and authenticate all access that my subcontractors have to my network”) and a machine's definition (“encrypt tcp packets from 10.3.86.5 to 10.4/16 with CAST and authenticate them with HMAC-SHA”). Because it is the security interface between human and computer, it is extremely important. The transition from human to computer involves policy definition, policy representation, policy management, and finally, the interactions between the policy and the various components of an IPSec system—IKE, the IPSec process itself, the SADB, and the SPD.
Policy is not a standard. IPSec protocol standards define various capabilities of policy. However, IETF does not mandate any particular representation of policy nor does it enforce any particular implementation. The policy issues such as definition and representation are left to implementations. Standards bodies typically refrain from dictating how policy is implemented. For instance, the IPSec working group of the IETF discusses the policy issues mostly from IPSec implementation perspective. However, the main challenge with policy is its definition and representation at a higher level, and then mapping it so that IKE and IPSec protocols can access it efficiently and unambiguously.
Another issue associated with policy is its deployment and management. This involves how policy is defined and communicated among various nodes in a network and how the policy is synchronized among various nodes. Network security is complex, and the larger the network being secured the more complex the policy that dictates how that security is achieved. There is, therefore, an obvious scaling problem with policy definition and deployment. If a network manager must visit each and every network entity and manually configure it in compliance with his or her system security policy, it will take an excessive amount of time. It also opens up the network to subtle errors that can manifest themselves as massive holes in the overall security of the network. Obviously, as networks grow, policy management for them will have to be centrally managed.
Policy is not solely the domain of security. Any network service that desires to identify certain classes of traffic (or =flows= of traffic) and apply different services to them require a policy. Network services such as traffic engineering, where certain flows are identified and given a higher quality of service or allocated specified bandwidth, are a prime example of this. In this chapter, we will discuss the capabilities of an IPSec policy system, its representation, distribution, and address the support the policy system has to provide for the kernel and IKE. The implementation issues are discussed in the next chapter.
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.
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.
Policy representation involves two aspects: the physical representation—defining the format in which the policy is represented, where it is stored, how it is updated/modified, and what protocols are used to update the policy; and the interface—defining how the various IPSec components acquire and manage a policy.
The physical representation of policy, to a very large extent, depends on the distribution mechanism. Because of its flexibility and generic design LDAP (Lightweight Directory Access Protocol) has received the most attention as a mechanism to distribute policy. Therefore, the IPSec policy being distributed takes the form of LDAP schemas.
LDAP is an advantageous mechanism because it provides a simple, lightweight (in fact, that's the L in LDAP) method of depositing and retrieving policy from a central repository.
Whatever method is used to represent policy, it should be capable of supporting all the capabilities that were defined in the policy definition section. The policy representation is a database problem. There has been some work in the IETF on the policy representation, specifically discussing a schema. This schema addresses the policy definition requirements. The schema is defined for LDAP. It is not necessary to use this schema for policy representation— any proprietary schema can be used to represent policy. However, using an LDAP schema eases the deployment of IPSec. The LDAP schema provides the ability to define a schema that either a server or a client uses to store the data. If the policy is stored in a central repository, clients can access this data through a well-defined protocol.
If IPSec were to be enabled on individual nodes there are three possible alternatives for configuration:
Configure each node individually.
Configure in a central repository but use a proprietary distribution mechanism to distribute the policy.
Configure in a central repository but use some standard mechanism to distribute the policy.
As corporations begin to deploy IPSec, the first alternative impedes deployment. This is acceptable only for prototyping. The second choice solves the deployment problem. However, using a proprietary mechanism for distribution is questionable. It is always judicious to use standard protocol if one exists.
Storing the policy in a central repository does not solve the problem of modification/update of the policy. An IPSec client has to download all the policy or incrementally update its policy during boot or whenever the server chooses to update the client's policy. The client has to store the policy locally because it needs to know which packets have to be secure and which do not. If the policy is not stored locally, for every packet for which the kernel does not find a policy, it has to invoke the policy client that in turn has to contact the central repository and invoke the key management protocol and also update the kernel policy. This leads to unacceptable delays for the first few packets.
The policy distribution mechanism has to be secure. The server from which the policy is downloaded should be authenticated. In addition, the access to the server should be restricted. If this is compromised, the security of the network is at risk. These are problems associated with any directory system. This is one reason it is better to use a standard directory mechanism such as LDAP for policy storage and retrieval for which security mechanisms have been already defined.
Figure 8.1 shows the most popular paradigm that currently exists for policy configuration and distribution.
The policy is stored centrally in a policy server. The policy server is responsible for maintaining the policy for all nodes (hosts and routers) in the domain. The policy server provides the capability to configure security for all the nodes in the domain. The policy is either downloaded into the various nodes in the network or is fetched dynamically by the nodes using directory services protocol such as LDAP.
Policy management defines the following interfaces:
interface between the directory service and the local database where the policy is stored;
interface between the User Interface application and the local policy database that allows read, write, and modify access to the database;
interface between IKE and policy database;
interface between kernel and the policy database.
The interfaces defined by the policy management should provide the ability to search the database based on one or more selectors. For example, one should be able to look up the policy for a particular <src, dst> pair or the policy for a particular network. It should also be possible to look up both inbound and outbound policy. The policy management should always be deterministic in its matches and should always match the longest prefix.
For example, if you configure a policy for the network 205.15/16 and another policy for the host 205.15.2.1, a search for the policy to 205.15.2.1 should return the policy entry created specifically for the host 205.15.2.1 and not for the network 205.15/16. In cases where it is ambiguous, the policy management should return policy in a deterministic manner. For example, if you configure a policy <205.15/16, 206.1.1.1> (P1) and another policy for <205.15.1.1, 206.1/16> (P2), then a lookup for <205.15.1.1, 206.1.1.1>, you can return either P1 or P2 or both. The proper behavior is to return both and also maintain the same order always.
The interfaces the policy management defines should address all the issues enumerated in the policy definition section. We will not address UI-specific issues in this book as it is impossible to make specific recommendations on UI that are universally acceptable! The interface between the UI application and the database can be similar to the interface between the database and IKE. We will discuss this in the next section.
The IPSec kernel consults the policy to determine the security services afforded to a packet. If the policy database is maintained in the user space, for every packet, the kernel needs to context switch into the user space to look up the policy. This operation is very expensive. It is almost mandatory for the kernel to maintain its own copy of the security policy database.
It is the policy management application's responsibility to update the kernel's SPD. As an implementor, you can define your own interface between the policy management application and the kernel. There has been some work at the IETF in defining the interface between the policy management application and the kernel. This interface is called PF_KEY, and is modeled after PF_ROUTE socket interface into the Kernel's routing table.
The policy management system should modify/delete/add entries to the kernel's SPD instantaneously. It should also provide the ability for bulk updates and not just one policy record at a time. This is critical for boot performance.
The policy management application should also support manual keying. It should be able to add and delete manual SAs.
IKE is invoked by the kernel or by the policy management application or by another IKE peer to establish keys. The kernel invokes IKE when it needs an SA for secure communication or if an SA has expired and it needs to establish new SA. The policy management application invokes IKE if it establishes keys before the kernel needs it to reduce delays for a new connection.
The kernel or the policy management application can invoke IKE in one of two ways:
pass just the selectors, in which case IKE has to consult the user level policy database to determine the policy;
pass the full policy.
If you choose option 1, the access to the user-level policy database has to be synchronized between IKE and the policy management application.
When IKE responds to a key negotiation request, it needs an interface to the user-level SPD to choose the parameters for the connection. The policy database lookup is based on selectors.
Another important aspect of policy management for IKE support is certificates. The IETF is working on standards for storage and retrieval of certificates. It is our belief that these technologies are not mature and it will be a few years before we see actual deployment of a large public key infrastructure. During this period, the certificates will be stored locally and fetched from a directory. The policy management system should provide the ability to store/delete certificates in its database and also provide an interface to fetch certificates from its database to IKE. Certificate support in IPSec is discussed in greater detail in Chapter 11.
So far, we have discussed the capabilities a policy system should provide and how it may be represented, stored, and managed. In this section, we discuss some of the deployment issues. This includes node level and domain level security, gateway traversal, and some issues associated with policy configuration.
As IPSec provides end-to-end security and can be used to build intranets and VPNs, it is desirable to provide the ability to configure security on a node and a domain level. We discussed node-level security in previous sections. The advantages of domain-level security are discussed here. In the networking world, a domain normally refers to a routing domain. A routing domain is delimited by a set of routers. This implies any packet leaving the domain has to hit one of the routers. It is possible, to a certain extent, to control which routers a particular packet traverses. However, if there is more than one exit point from an organization, it is difficult for the host to control which router is used to exit, particularly if a link goes down. Under these circumstances, defining a domain-level policy and distributing it to all the border routers is extremely important. If all the border routers share the same policy, the security service afforded to a flow is the same irrespective of the border router over which the packet exits or enters the domain.
Policy incompatibility is an issue in policy configuration. Two domains that need to talk securely may configure their policy such that their intersection is NULL set. Consider the network shown in Figure 8.2.
RA and RB are the edge routers for domain A and B respectively. RA is configured such that all the packets destined to domain B are secured by ESP in tunnel mode using 3DES. However, RB is configured such that all packets it receives from domain A are configured for ESP in tunnel mode using DES. In this case, the two domains never get to talk to each other as IKE negotiation never succeeds.
In this section, let us try and walk through the steps one has to follow to set up the policy for IPSec.
The first step is to set up the policy for phase I of IKE negotiation. The policy can either be global (i.e., the same IKE phase I policy is used for all the hosts) or it can be host or network prefix-specific, or it can be domain-specific. The following attributes have to be set up for Phase I:
Phase I mode: main or aggressive
Protection suite(s)
Once the phase I policy is set up, IKE is ready for phase II, where it can negotiate the security services afforded to an IP packet. The following attributes can be defined:
The selectors that identify the flow. The granularity can range from being very coarse to being very fine-grained. The spectrum may range from one policy for all packets to a different policy for each flow belonging to a particular identity.
The security attributes for each flow. This includes the protocols, their modes, the transforms they should be using, and various attributes of these transforms such as lifetime and replay windows.
Action (secure, drop, or pass) to be taken for each flow.
The phase I and the phase II policies govern the security services afforded to the IP packets originating or destined to the network/domain/host. IPSec provides a very rich set of options. One drawback of providing a rich set of options is that it makes the process of setting and negotiating complicated. If two entities have to negotiate a set of options or choose from a set of options, they need to talk the same language, that is, they should have the same understanding for values passed in the protocol headers. The values that two entities should use to negotiate security parameters are described in the IPSec DOI (see Chapter 7). The IPSec DOI consolidates the various options and values for Phase II negotiation. Any policy system should support all the options described in this document.