IP policy information VPN

In addition, the client needs IP policy information so it can classify packets and send them throughthe appropriate tunnel. A mechanism is needed todownload this policy information to the client andalso to store it in the SA database corresponding to thetwo VPN sessions on the client. Before consideringwhat modifications will have to be made to a genericVPN client to make it possible to download such policy information let us review how policy informationis currently downloaded. Currently, VPN clients useInternet key exchange (IKE) [10] to exchange thekeys needed to establish a secure IPSec tunnel to aVPN gateway. IKE is based on the framework provided by the Internet security association and keymanagement protocol (ISAKMP) [16, 20]. There aretwo phases to IKE. In phase 1, the peers establish asecure authenticated channel over which to communicate. (In our case, the two peers are the VPN clientand VPN gateway.) In phase 2, IPSec SAs and IPSeckeys are exchanged using the secure authenticatedchannel established in phase 1. The user is then authenticated at the VPN gateway, normally by theXauth mechanism. Finally, IKE informational messages or mode-config messages are used to downloadpolicy information from the VPN gateway to the VPNclient. (The VPN gateway may receive this policy information from an authentication, authorization, andaccounting [AAA] [21] server within the enterprise.)The policy information downloaded includes a set ofsubnet IP addresses. If the destination IP address of a packet falls within one of these subnets, the packet issent through the VPN tunnel to the VPN gateway; ifit falls outside these subnets, the packet is sent directlyto the Internet.