The term SAD has been used throughout this chapter without much detailed expla-nation. While the SPD is policy driven and is concerned with system relationships, the SAD is responsible for each SA in the communications required by the SPD. Each SA has an entry in the SAD. The SA entries in the SAD are indexed by the three SA properties: destination IP address, IPSec protocol, and SPI. The SAD database contains nine parameters for processing IPSec protocols and the associated SA.
1. Sequence number counter for outbound communications: This is the 32-bit sequence number provided in the AH or ESP headers. Once again, the sequence number is always applied, but not necessarily used by the recipient.
Therefore, this particular selector is only required for outbound traffic. Oth-erwise, the recipient not providing replay resistance would have to check the sequence number anyway.
2. Sequence number overflow counter: This sets an option flag to prevent further communications utilizing the specific SA. As discussed above, if replay resis-tance is applied, there must be a mechanism to delete the SA in the event the sequence number is near duplication.
3. A 32-bit anti-replay window: This is used to identify the packet for that point in time traversing the SA and provides the means to identify that packet for future reference. Given the nature of TCP/IP, packets can arrive out of order;
therefore, if anti-replay is enabled, packets must be given time to make it to the destination. As each packet is received, the window is shifted. If a packet is not received by the time the window has shifted, it will be dropped when it does arrive.
4. Lifetime of the SA: This is determined by a byte count or time frame, or a combination of the two. Once the lifetime is met, the SA must be deleted and a new one created — or simply deleted. When both are implemented, the first to be met will take precedence.
Of the two types of lifetimes, the SAD is also responsible for the management of the SA when the lifetime limit is met. There are two type of lifetime settings:
soft lifetime and hard lifetime. Soft lifetime determines a point when to initiate the process to create a replacement SA. This is typical for re-keying procedures.
Hard lifetime is the point where the SA expires. If a replacement SA has not been established, the communications will discontinue.
5. The algorithm used in the AH and the associated key. By default, IPSec must support HMAC-MD5 or HMAC-SHA, both of which require a key.
6. The algorithm used in the authenticating portion of the ESP header. As with AH, ESP must support message authentication codes that utilize a key; therefore, the SAD will have references to the key.
7. The algorithm used in the encryption of the ESP and its associated key infor-mation.
8. IPSec mode of operation — transport or tunnel mode: This entry indicates the mode the AH or ESP is applied to the packet.
9. Path MTU (PMTU). This is data that is acquired from ICMP data over the SA.
Each of these parameters is referenced in the SPD for assignment to policies and applications.
SA Configurations
With the two basic modes of IPSec communication, there are several valid IPSec VPN configurations. Hosts must support both tunnel and transport modes of operations, while security gateways must only support tunnel mode. Depending on the environ-ment, the combinations can become staggering.
Note: In the exhibits shown, there is one “tube” that represents an SA or SA bundle. At minimum, there are really two SAs (as shown before) for each SA in the following examples. To add another layer of com-plexity, if the SAs depicted are using AH and ESP for protection, then there are four pure tubes represented in the following exhibits.
Host-based VPN. Two hosts can establish an IPSec VPN in either tunnel mode or transport mode; both are supported. As shown in Exhibit 7-3, two hosts can establish a VPN between each other, regardless of what is in between. As long as a TCP/IP session can be maintained, a VPN can be created.
It can be argued that transport mode without the use of AH is not secure because the IP header is not authenticated if ESP is utilized. If AH is not desirable, then ESP tunnel mode would provide security to the original IP header. Transport mode is used
Exhibit 7-3. Host-to-host VPN using tunnel or transport mode.
Transport / Tunnel H1/H2
H1 H2
when end-to-end protection is desired and represents the endpoints of the SAs and the encryption. Host-based VPNs are not widely used; the reasoning and issues are discussed in the next section.
Gateway-based VPN. As shown in Exhibit 7-4, two security gateways can establish a VPN between them to provide connectivity for their respective networks. This imple-mentation represents the bulk — if not all — of the network-to-network solutions being utilized. Data created on one network destined for the other gets forwarded to the SGW to be tunneled to the IPSec partner. Once received by the other SGW, the data is decrypted and forwarded to the network based on its original properties.
Host to Gateway. In Exhibit 7-5, host to gateway represents how remote access VPNs are being established. As shown in Exhibit 7-5, a remote system can establish a tunnel mode VPN to a SGW.
This example represents what is typical among VPN solutions. A remote host estab-lishes an IP connection to the Internet. As the requirement for connectivity to the network hosted by the SGW, a tunnel mode VPN is established to allow the remote system to interact with the internal network.
Hosts and Gateways. There are several configurations of SAs and combinations of tunnel modes and transport modes beyond the typical gateway-based and host-based.
However, it is necessary to understand that these examples are simply not being leveraged. There are many implementations that can take advantage of the options, but very few do so.
Exhibit 7-6 shows an example of when a remote system uses tunnel mode for remote access, much like the previous example, but extends the security into the internal network to the final destination.
For many organizations, this is very desirable. It provides end-to-end protection of the information. Typically, this configuration would employ ESP tunnel mode from the host to the SGW and create an AH or ESP transport mode to the internal host.
Exhibit 7-4. Gateway-to-gateway VPN using tunnel mode only.
Exhibit 7-5. Host-to-gateway VPN using tunnel mode: a typical remote access solution.
Tunnel R1/R2
H1 H2
R1 R2
Tunnel H1/R1
H1 H2
R1
Tunnel mode can also be used. Establishing a VPN from a remote host to an SGW in tunnel mode is common, as discussed earlier. However, nesting a transport, or tun-neling more SA within the tunnel to the SGW is not typical. This can be categorized as an extended remote access solution.
In Exhibit 7-7, a network-to-network VPN is augmented with extended protection, much like the extended remote access solution previously explained. In the event that two networks are connected via a tunnel mode VPN and two systems require end-to-end protection, a nested mode is needed. In the example, two SGWs are providing a tunnel mode for protection of data between the two networks. However, two hosts on the internal network require protection from prying eyes on the internal networks. For that reason, a nested transport or tunnel mode SA is established between the two hosts.
In this environment, the internal networks are not entirely trusted.
There are several cases in which the client may reside on an untrusted network and need a secured channel to a remote network that already has a VPN established with the remote network. Exhibit 7-8 details this scenario.
At first glance, this may seem odd; but there are many examples where this has been very desirable. The following example has presented itself to the author many times. An organization has established a limited access VPN with another organization — in a network-to-network configuration — possibly the competition, to share certain information for payment or the betterment of both organizations. None-theless, this exists in more environments than expected. Yet an employee from the Exhibit 7-6. Host-to-gateway VPN using tunnel mode with transport or tunnel mode to inter-nal host.
Exhibit 7-7. Gateway-to-gateway VPN using tunnel mode with transport or tunnel mode between internal hosts.
Exhibit 7-8. Host-to-gateway VPN using tunnel mode with tunnel mode between internal host and remote network.
H1 H2
R1
Tunnel H1/R1 Transport/Tunn H1/H2
H2
R1 R2
Tunnel R1/R2 Trans/Tunn H1/H2 H1
H2
R1 R2
Tunnel R1/R2 Tunnel H1/R2
H1
primary organization is working from the competition’s network. The user needs access to crucial information that could be devastating if discovered by the competi-tion. To provide the necessary access and protection for the remote user on an untrusted network, a tunnel mode SA can be established to the remote network nested in the existing tunnel. The SA is not extended into the home network because it is trusted.
The remote user could establish a standard tunnel to the remote SGW without leveraging the existing tunnel between the networks, but that does not convey the available option.