D-Link NetDefendOS User Manual page 685

IKE Phase-1 - IKE Security Negotiation
An IKE negotiation is performed in two phases. The first phase, phase 1, is used to authenticate
the two VPN firewalls or VPN Clients to each other, by confirming that the remote device has a
matching Pre-Shared Key.
However, since we do not want to publish to much of the negotiation in plaintext, we first agree
upon a way of protecting the rest of the IKE negotiation. This is done, as described in the
previous section, by the initiator sending a proposal-list to the responder. When this has been
done, and the responder accepted one of the proposals, we try to authenticate the other end of
the VPN to make sure it is who we think it is, as well as proving to the remote device that we are
who we claim to be. A technique known as a Diffie Hellman Key Exchange is used to initially agree
a shared secret between the two parties in the negotiation and to derive keys for encryption.
Authentication can be accomplished through Pre-Shared Keys, certificates or public key
encryption. Pre-Shared Keys is the most common authentication method today. PSK and
certificates are supported by the NetDefendOS VPN module.
IKE Phase-2 - IPsec Security Negotiation
In phase 2, another negotiation is performed, detailing the parameters for the IPsec connection.
During phase 2 we will also extract new keying material from the Diffie-Hellman key exchange in
phase 1 in order to provide session keys to use in protecting the VPN data flow.
If Perfect Forwarding Secrecy (PFS) is used, a new Diffie-Hellman exchange is performed for each
phase 2 negotiation. While this is slower, it makes sure that no keys are dependent on any other
previously used keys; no keys are extracted from the same initial keying material. This is to make
sure that, in the unlikely event that some key was compromised, no subsequent keys can be
derived.
Once the phase 2 negotiation is finished, the VPN connection is established and ready for traffic
to pass through it.
IPsec Tunnel Properties
Below, is a summary of the key properties required of an IPsec tunnel object. Understanding
what these properties do before attempting to configure the tunnel is strongly recommended,
since it is of great importance that both tunnel endpoints can agree.
With two NetDefend Firewalls as IPsec endpoints, the matching process is greatly simplified
since the default NetDefendOS configuration parameters will be the same at either end.
However, it may not be as straightforward when equipment from different vendors is involved in
establishing the VPN tunnel.
• Local and Remote Networks/Hosts
These are the subnets or hosts between which IP traffic will be protected by the VPN. In a
LAN-to-LAN connection, these will be the network addresses of the respective LANs.
If roaming clients are used, the remote network will most likely be set to all-nets, meaning
that the roaming client may connect from anywhere.
• Local ID and Remote ID
The local and remote IDs are values sent by each side of the tunnel during the IKE negotiation
and both can be used with either a pre-shared key or certificate based tunnel.
685
Chapter 9: VPN