The IPSec Roadmap

   

The IPSec protocols include AH, ESP, IKE, ISAKMP/Oakley, and transforms. In order to understand, implement, and use IPSec, it is necessary to understand the relationship among these components. The IPSec roadmap defines how various components of IPSec interact with each other. This is shown in Figure 4.1..

Figure 4.1. IPSec Roadmap (this figure has been reproduced from the draft with permission of the authors)

graphics/04fig01.gif

IPSec is a suite of protocols and it is important to understand how these protocols interact with each other and how these protocols are tied together to implement the capabilities described by the IPSec architecture.

The IPSec architecture, as described in the previous chapter, defines the capabilities the hosts and gateways should provide. For example, IPSec architecture requires the host to provide confidentiality using ESP, and data integrity using either AH or ESP and antireply protection. However, the architecture document does not specify the header formats for these protocols. The architecture discusses the semantics of the IPSec protocols and the issues involved in the interaction among the IPSec protocols and the rest of the TCP/IP protocol suite.

The ESP and the AH documents define the protocol, the payload header format, and the services they provide. In addition these documents define the packet processing rules. However, they do not specify the transforms that are used to provide these capabilities. This is because the new transforms can be defined when the algorithms used by the older transforms are proved to be cryptographically insecure. However, this does not mandate any change to the base protocols.

The transforms define the transformation applied to the data to secure it. This includes the algorithm, the key sizes and how they are derived, the transformation process, and any algorithmic-specific information. It is important to be specific about the necessary information so that different implementations can interoperate. Let us consider the DES-CBC transform that is defined for ESP. If we do not specify how the Initialization Vector is derived, the two implementations end up deriving the Initialization Vector in different ways, and they will never be able to interoperate.

IKE generates keys for the IPSec protocols. IKE is also used to negotiate keys for other protocols that need keys. There are other protocols in the Internet that require security services such as data integrity to protect their data. One such example is OSPF (Open Shortest Path First) routing protocol. The payload format of IKE is very generic. It can be used to negotiate keys for any protocol and not necessarily limit itself for IPSec key negotiation. This segregation is achieved by separating the parameters IKE negotiates from the protocol itself. The parameters that are negotiated are documented in a separate document called the IPSec Domain of Interpretation.

An important component that is not yet a standard is "policy." Policy is a very important issue because it determines if two entities will be able to communicate with each other and, if so, what transforms to use. It is possible, with improperly defined policies, for two sides to be unable to communicate with each other.

The issues with policy are representation and implementation. Representation deals with definition of policy, storage, and retrieval. The IETF is currently working on defining the policy standards. The implementation addresses the application of policy for actual communication. It is important that the keys established by the key management protocol are applied appropriately in the communication. It is equally important to apply the appropriate filters and rules. This chapter discusses the implementation issues of policy and how these rules are applied to the IPSec traffic. The policy representation is discussed later.


   
Top


IPSec(c) The New Security Standard for the Internet, Intranets, and Virtual Private Networks
IPSec (2nd Edition)
ISBN: 013046189X
EAN: 2147483647
Year: 2004
Pages: 76

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net