IPSec Model

Now that the function of each component has been explained individually, a comprehensive picture is necessary to complete an understanding of the architecture, as shown in Figure 8.8.

Enlarge figure

Figure 8.8 Overview: the IPSec Process

For simplicity, this is an intranet computer example. Each computer has an active IPSec policy.

1. Alice, using a data application on Host A, sends a message to Bob on Host B.
2. The IPSec driver on Host A checks its stored IP Filter Lists to see whether the packets should be secured.
3. The driver notifies IKE to begin negotiations.
4. The IKE service on Host B receives a message requesting secure negotiation.
5. The two computers establish a Phase I SA and shared master key.

Note

If Host A and Computer B already have an Phase I SA in place from a previous communication (and Phase I PFS is not enabled nor have key lifetimes expired), the two computers can go directly to establishing the Phase II SA.

1. A pair of Phase II SAs are negotiated: one inbound SA, and one outbound SA. The SAs include the keys used to secure the information, and the SPI.
2. The IPSec driver on Host A uses the outbound SA to sign and/or encrypt the packets.
3. The driver passes the packets to the IP layer, which routes the packets toward Host B.
4. Host B's network adapter driver receives the encrypted packets and passes them up to the IPSec driver.
5. The IPSec driver on Host B uses the inbound SA to check the integrity signature and/or decrypt the packets.
6. The driver passes the decrypted packets up to the TCP/IP driver, which passes them to the receiving application on Host B.

Although this appears to be a long series of time-consuming and complicated steps, it actually all happens quickly and transparently to each user.

Any routers or switches in the data path between the communicating computers simply forward the encrypted IP packets to their destination. However, if there is a firewall, security router, or proxy server, it must have IP forwarding enabled, so that IPSec and IKE protocol traffic will pass through and not be rejected. Security negotiations are not able to pass through a network address translator (NAT). The IKE negotiation contains IP addresses in the encrypted messages which can not be changed by a NAT because the integrity hash will be broken, or because the packets are encrypted.

© 1985-2000 Microsoft Corporation. All rights reserved.