Справочник Пользователя для SonicWALL 5.8.1
VPN > Settings
868
SonicOS 5.8.1 Administrator Guide
Aggressive Mode: To reduce the number of messages exchanged during authentication by
half, the negotiation of which cryptographic algorithm to use is eliminated. The initiator
proposes one algorithm and the responder replies if it supports that algorithm:
half, the negotiation of which cryptographic algorithm to use is eliminated. The initiator
proposes one algorithm and the responder replies if it supports that algorithm:
1.
The initiator proposes a cryptographic algorithm to use and sends its public key.
2.
The responder replies with a public key and identity proof.
3.
The initiator sends an identification proof. After authenticating, the VPN tunnel is
established with two SAs, one from each node to the other.
established with two SAs, one from each node to the other.
IKE Phase 2
In IKE phase 2, the two parties negotiate the type of security to use, which encryption methods
to use for the traffic through the tunnel (if needed), and negotiate the lifetime of the tunnel
before re-keying is needed.
to use for the traffic through the tunnel (if needed), and negotiate the lifetime of the tunnel
before re-keying is needed.
The two types of security for individual packets are:
•
Encryption Secured Payload (ESP), in which the data portion of each packet is encrypted
using a protocol negotiated between the parties.
using a protocol negotiated between the parties.
•
Authentication Header (AH), in which the header of each packet contains authentication
information to ensure the information is authenticated and has not been tampered with. No
encryption is used for the data with AH.
information to ensure the information is authenticated and has not been tampered with. No
encryption is used for the data with AH.
SonicOS supports the following encryption methods for Traffic through the VPN.
•
DES
•
3DES
•
AES-128
•
AES-192
•
AES-256
You can find more information about IKE v1 in the three specifications that define initially define
IKE, RFC 2407, RFC 2408, and RFC 2409, available on the Web at:
IKE, RFC 2407, RFC 2408, and RFC 2409, available on the Web at:
IKEv2
IKE version 2 is a new protocol for negotiating and establishing SAs. IKE v2 features improved
security, a simplified architecture, and enhanced support for remote users. In addition, IKE v2
supports IP address allocation and EAP to enable different authentication methods and remote
access scenarios. Using IKE V2 greatly reduces the number of message exchanges needed to
establish an SA over IKE v1 Main Mode, while being more secure and flexible than IKE v1
Aggressive Mode. This reduces the delays during re-keying. As VPNS grow to include more
and more tunnels between multiple nodes or gateways, IKE v2 reduces the number of SAs
required per tunnel, thus reducing required bandwidth and housekeeping overhead.
security, a simplified architecture, and enhanced support for remote users. In addition, IKE v2
supports IP address allocation and EAP to enable different authentication methods and remote
access scenarios. Using IKE V2 greatly reduces the number of message exchanges needed to
establish an SA over IKE v1 Main Mode, while being more secure and flexible than IKE v1
Aggressive Mode. This reduces the delays during re-keying. As VPNS grow to include more
and more tunnels between multiple nodes or gateways, IKE v2 reduces the number of SAs
required per tunnel, thus reducing required bandwidth and housekeeping overhead.
IKE v2 is not compatible with IKE v1. If using IKE v2, all nodes in the VPN must use IKE v2 to
establish the tunnels.
establish the tunnels.
SAs in IKE v2 are called Child SAs and can be created, modified, and deleted independently
at any time during the life of the VPN tunnel.
at any time during the life of the VPN tunnel.