Implementation Architecture
Most IPSec implementations define the following components:
IPSec base protocols: This component implements ESP and AH. It processes the headers, interacts with the SPD and SADB to determine the security that is afforded to the packet, and handles network layers issues such as fragmentation and PMTU.
SPD: The SPD is an important component because it determines the security afforded to a packet. The SPD is consulted for both outbound and inbound processing of the packet. For outbound processing, the SPD is consulted by the IPSec base protocol to decide if the packet needs any security. For inbound packets, the SPD is consulted by the IPSec base protocol component to decide if the security afforded to the packet concurs with security configured in the policy.
SADB: The SADB maintains the list of active SAs for outbound and inbound processing. Outbound SAs are used to secure outgoing packets and inbound SAs are used to process inbound packets with IPSec headers. The SADB is populated with SAs either manually or via an automatic key management system such as IKE.
IKE: The Internet Key Exchange is normally a user-level process, except in embedded operating systems. Typically, in nodes such as routers that are running embedded operating systems, there is no distinction between a user space and kernel space. IKE is invoked by the policy engine when the policy mandates an SA or SA bundle exist for two nodes to communicate securely but the SA(s) is yet to be established. IKE is also invoked by its peer when the node needs to communicate securely.
Policy and SA management: These are applications that manage the policy and SA.
Figure 9.1 indicates the various components of IPSec and the interactions among them.
Figure 9.1. IPSec implementation architecture.
In the rest of this section, the interface and design requirements for each of the components are discussed.
IPSec Base Protocols
The IPSec base protocols interact closely with the transport and the network layer. In fact, IPSec base protocol is part of the network layer. The IPSec base protocol module should be designed to efficiently implement the following capabilities:
Ability to add, possibly multiple, IPSec headers to an outbound packet in both tunnel mode and transport mode.
Ability to process tunnel mode IPSec packets and pass the decapsulated packet onto IP forwarding.
Ability to process transport mode IPSec packets and pass them into the appropriate transport layer such as TCP, UDP, or ICMP, depending on the transport payload carried by the IPSec packet.
The IPSec protocol module provides two interface functions input and output. The input interface function is called for inbound packets and the output interface function is called for outbound packets.
In almost all implementations of IPSec, IPSec is integrated with an existing TCP/IP implementation. The interface between the transport layer and the network layer for both incoming and outgoing traffic is dependent on a particular implementation. For example, in the popular BSD UNIX implementation, the transport layer protocols such as UDP and TCP register with the network layer indicating the input function the IP layer should invoke. TCP registers a function that IP should invoke when the IP layer encounters a TCP payload. The IPSec implementations should not violate the interface between the transport and the network layer. The interface and integration should be seamless. For example, the TCP layer should not be required to know if it was invoked from the IPSec component or the IP component.
SPD and SADB
The choice of the data structure to store the SPD and the SADB is fairly crucial to the performance of IPSec processing. The SPD and SADB implementation depend on the performance requirements of the system and the capabilities of the system. Some of the factors that determine the design of the SPD and SADB are:
Number of expected entries in the SPD and the SADB
System throughput both for outbound and inbound packets.
Cost of allocating memory as needed versus the cost of maintaining large tables, portions of which may be unused.
Any optimizations the system provides to cache pointers to SAs or SPD entries.
The design of SPD and SADB should satisfy the following requirements:
Ability to efficiently look up the structure for exact or most specific match based on the selectors source address, destination address, protocol, and SPI.
Ability to store wildcards, range, or exact values for the selectors.
Synchronization mechanisms for the structure when the implementation is optimized by caching pointers to SADB, SPD.
Ordering of entries so that the match is always deterministic.
As mentioned earlier, the choice of the data structure for SADB or SPD depends, among other things, on the performance requirements and the number of entries in the SADB or the SPD. The lookup for the outbound processing is more complicated than the inbound processing. For outbound processing, the lookups are based on selectors in the SPD. There may not be an exact match, as the selectors for source and destination address can be network prefixes. However, this problem is already solved in routing. In order to find the route to a destination, one has to match the closest network prefix for cases where there are no host routes (host routes have the destination address in the routing table).
The processing can be optimized for SA lookup by caching SA pointers in the SPD entries. If the SA pointers are not cached in the SPD entry, then the lookup for outbound SA is as complicated as the SPD lookup.
The inbound processing of IPSec packets is simpler because the lookups are based on information in the received packet for which the matches are exact. The SPD entry that corresponds to the SA can be cached in the SADB entry. This optimizes the policy checking upon the conclusion of IPSec processing and avoids another lookup.
For inbound IPSec packets, after the IPSec headers are processed, the SPD is consulted to determine if the packet can be admitted based on the security services that were offered. If the policy is not checked, security ofthe system is compromised. Let us consider the example shown in Figure 9.2.[1]
[1] For the sake of brevity, all the elements in the SA record are now shown. The lifetime, sequence numbers, and other fields discussed in the security architecture chapter are not shown in these diagrams.
Figure 9.2. Flow-specific IPSec.
Two hosts, A and B, with IP address 1.1.1.1 and 2.2.2.2 have established two SAs, SA1 and SA2. (The SADB shown in the Figure 9.2 does not have all the fields. The sequence number, lifetime, and other fields have been left out.) SA1 is configured for ESP with 3DES and SA2 ESP with DES. This information is stored in the SPD.[2]
[2] From and to are used instead of source and destination in the SPD intentionally. It was mentioned earlier that IKE does not allow the policy to be asymmetric. This being the case, the terms source and destination are confusing because the inbound and the outbound policies are the same. It does not matter who originated the packet, the same policy is used.
SA1 is used for very secure applications, say banking, which runs on a TCP using port 1000. After IPSec processing, if the policy is not checked to determine if the banking application did in fact use 3DES, then security is compromised. The policy can be checked only after the IPSec processing as the selectors are not available before because they may be encrypted.
For inbound packets that are not IPSec packets, the SPD has to be consulted to determine the type of processing afforded to the packet. The reason is because, if certain traffic is required to be IPSec-protected, one needs to drop any inbound packets that match the SPD definition of that traffic but that do not have the proper IPSec protection.
The inbound and the outbound processing are completely independent. However, it easier to use the same data structures for the SPD and the SADB for both inbound and outbound processing. There are various choices for the data structures sorted hash lists, PATRTICIA trees, radix-4 trees, to name a few.
For connection-oriented connections, in the end hosts the lookups can be optimized further by caching the pointer to the SPD entry in the socket data structure, if such a structure exists. This obviates the need to look up the SPD for each outbound packet generated by the application using the socket. Multiple sockets can cache the same SPD. However, caching pointers in end host or router implementations increases the implementation complexity. In multithreaded operating systems, this implies providing locks to synchronize access to these shared data structures. There is also the additional complexity of removing pointers to SAs and SPD entries when the entries themselves are removed from either SADB or SPD.
The SADB and SPD may be implemented in the same module. In fact, it helps to implement them in the same module because of pointer references between the two entities. The module provides the following interfaces:
Add one or more SA or SPD entries
Delete one or more SA or SPD entries
Look up one or more SA or SPD entries
IKE
The Internet Key Exchange is responsible for dynamically populating the SADB. IKE is in a quiescent state until its services are needed. IKE's services can be requested in one of two waysãthe SPD requests it to establish an SA or a peer requests it to establish an SA.
IKE provides an interface to the SPD to inform it about establishing new SAs. The physical interface between IKE and the SPD and SADB is completely dependent on the Inter-Process Communications (IPC) capabilities of the platform. For example, it could be a socket, or a message queue. More important is the information passed via the IPC mechanism. Through this interface must pass all the information necessary to begin negotiation: the peer and all transforms with all necessary attributes. Since IPSec policy can be complex, and IKE is capable of expressing complex policy, it is imperative that the information exchanged between IKE and the SPD contain all the required conjunctions to maintain the policy complexity. For example, if the policy states that the SA bundle of AH-HMAC-MD5 and ESP-CAST-CBC (no authenticator), and IPPCP-LZS is needed, then the conjunctive nature of the request ("...and...and...") must be retained. This can be achieved by sending each protocol as an individual IPC message but including a logical operator field in the message, which indicates the relationship this message has to the next, or by passing the entire bundle of information in a single message. Either way, the interface between the SPD and IKE must not hamstring policy declaration and negotiation.
IKE also provides an interface for the remote IKE peer to request SA establishment. The remote peer requests the establishment of a new SA through Phase II negotiation if ISAKMP SA is already established or through Phase I if ISAKMP SA is not established.
The interface between IKE and SPD is bidirectional. This is necessary for IKE to support both ways of the SA establishment. IKE receives policy information from the SPD to present to its peer (in the case of IKE as the initiator) and receives offers from its peer (in the case of IKE as the responder) which it must present to the SPD for a local policy check.
IKE communicates with the SADB either after it has received a message from the SPD (if it is the initiator of the protocol), or after it has received a message from a remote IKE peer (if it is the responder of the protocol). The SADB manages itself and therefore determines which SPIs are used, unused, or in a larval state. When IKE takes part in a quick mode exchange, it must request SPIs from the SADB to be reserved for its negotiation. These SPIs are for SAs that have not yet been fully created and are therefore larval. Upon completion of the quick mode, IKE has all the information necessary to instantiate the SA. This interface must be bi-directional since IKE sends messages to the SADB (SPI request and SA instantiation) and receives messages back from the SADB (SPI response).
IKE provides the following interfaces:
A bidirectional interface for communicating with the SPD.
An interface for the SADB to communicate the SPIs IKE can use.
Policy Management System
In the previous chapter, policy requirements, capabilities, and design implications were extensively discussed. The policy management (PM) system module is implemented at the user level. The user interacts with this module for all policy-related processing. This module interacts with the kernel to update the kernel's SPD. This module is also responsible for handling manual keying. This PM module provides the following capabilities and interfaces:
Add, lookup, and delete policies. This may involve interfacing with a directory protocol to fetch policy from a central repository or provide a UI for the user to manage the policy.
Add, create, and delete SAs manually.
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 |