IPsec Databases
Figure 1 shows the traffic flow for this example. Table 1 is the Security Policy Database (SPD) and Table 2 to Security Association Database (SAD).
Figure 1
H3 Security Policy Database (SPD)*
Policy | Remote Addr | Local Addr | Trans Protocol | Remote Port | Local Port | IPsec Spec (proto, mode, dst IP) |
SA Bundle Ptr | Dir. Flag | Outbound SA Ptr | Inbound SA Ptr |
1 | Net2 (packet) |
H3 | * (policy) |
* (policy) |
* (policy) |
AH, Trans | 2 | Bi | 2 | 8 |
2 | Net2 (policy) |
H3 | * (packet) |
* (policy) |
* (policy) |
ESP, GWTunnel, SG2 | Null | Bi | 1 | 7 |
3 | H4 | H3 | * (policy) |
* (policy) |
* (policy) |
AH, Trans | 4 | Bi | 4 | 10 |
4 | H4 | H3 | * (policy) |
* (policy) |
* (policy) |
ESP, Tunnel | Null | Bi | 5 | 11 |
Table 1
H3 Security Association Database (SAD)
SAD Entry | SPI | Dst IP Addr | Selectors (dst addr, src addr, proto, dst prt, src prt) |
Chained SA Ptr | Direction Flag | SP Ptr |
1 | 300 | SG2 | Net2, H3, TCP, *, * | 6 | Outbound | 2 |
2 | 500 | H2-a | H2-a, H3, *, *, * | 3 | Outbound | 1 |
3 | 600 | H2-b | H2-b, H3, *, *, * | Null | Outbound | 1 |
4 | 700 | H4 | H4, H3, *, *, * | Null | Outbound | 3 |
5 | 710 | H4 | H4, H3, *, *, * | Null | Outbound | 4 |
6 | 400 | SG2 | Net2, H3, UDP, *, * | Null | Outbound | 2 |
7 | 301 | H3 | H3, Net2, TCP, *, * | 12 | Inbound | 2 |
8 | 501 | H3 | H3, H2-a, *, *, * | 9 | Inbound | 1 |
9 | 601 | H3 | H3, H2-b, *, *, * | Null | Inbound | 1 |
10 | 701 | H3 | H3, H4, *, *, * | Null | Inbound | 3 |
11 | 711 | H3 | H3, H4, *, *, * | Null | Inbound | 4 |
12 | 401 | H3 | H3, Net2, UDP, *, * | Null | Inbound | 2 |
Table 2
The SPD is searched for a policy that matches traffic destined to H2-a. Policy 1 is found to match. A SAD entry already exist since this is the manual key case. In the IKE case, a SA negotiation is started. When the SAs are established, the SAD entry is linked to the SPD. "Outbound SA Ptr" in Policy 1 points to SA 2. The IPsec processing specified in the SA is performed. A check is made to see if more IPsec needs to be done. SPD entry 1 has the "SA Bundle Ptr" set to 2. This indicates that nested IPsec is performed as specified in Policy 2. From Policy 2, the "Outbound SA Ptr" is found and IPsec performed. Since this is the last IPsec for this packet ("SA Bundle Ptr" in Policy 2 is "Null"), the packet is sent to the network.
When the H3 receives traffic from H2-a, the SAD is consulted for a match to the inbound traffic. The SPI/Dst IP Addr/Protocol are used to find the correct SA. For the outer tunnel ESP IP header, SAD entry 7 is found. The "SP Ptr" is used to verify the protocol. After IPsec is performed for ESP, the SA for AH is found to be SAD entry 501. Again, IPsec is performed. The packet is passed to the transport layer. Here, the IPsec processing is verified by searching the SPD for a match; or, if the SA info is cached in the socket, a check against the cached info is done . The match for the AH portion is Policy 1. "Bundle Ptr" indicates the ESP portion is Policy 2. Both the policies match and the packet is allowed to proceed with normal processing.
Note, the same policies are used for inbound and outbound traffic due to the "Dir. Flag" (Direction Flag) set to "Bi" (Bi-directional). Also, the ESP Tunnel (Policy 2) contains the "packet" parameter in the "Trans Protocol" selector. The SAD entry used is different depending on the transport protocol of the packet. In the above example, TCP was the protocol.
If traffic is to H2-b instead of H2-a, the same policies match but different SAD entries are used. For the AH Transport, SAD entry 3 is used for outbound and SAD entry 9 for inbound traffic. The same ESP Tunnel is used if the transport protocol is TCP. For UDP, different SAD entries are used.