Policy Representation and Distribution
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.
Figure 8.1. Policy deployment architecture.
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.
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |