Cisco Cisco ASA 5512-X Adaptive Security Appliance トラブルシューティングガイド

ページ / 7
Conventions
For more information on document conventions, refer to Cisco Technical Tips Conventions.
Why Migrate to IKEv2?
IKEv2 provides better network attack resilience. IKEv2 can mitigate a DoS attack on the network
when it validates the IPsec initiator. In order to make DoS vulnerability difficult to exploit, the
responder can ask for a cookie to the initiator who has to assure the responder that this is a normal
connection. In IKEv2, the responder cookies mitigate the DoS attack so that the responder does not
keep a state of the IKE initiator or does not perform a D−H operation unless the initiator returns the
cookie sent by the responder. The responder uses minimal CPU and commits no state to a Security
Association (SA) until it can completely validate the initiator.
• 
IKEv2 reduces the complexity in IPsec establishment between different VPN products. It increases
interoperability and also allows a standard way for legacy authentication methods. IKEv2 provides a
seamless IPsec interoperability among vendors since it offers built−in technologies such as Dead Peer
Detection (DPD), NAT Traversal (NAT−T), or Initial Contact.
• 
IKEv2 has less overhead. With less overhead, it offers improved SA setup latency. Multiple requests
are allowed in transit (for example, when a multiple of child−SAs are set up in parallel).
• 
IKEv2 has a reduced SA delay. In IKEv1 the delay of SA creation amplifies as the packet volume
amplifies. IKEv2 keeps the same average delay when the packet volume amplifies. When the packet
volume amplifies, the time to encrypt and process the packet header amplifies. When a new SA
establishment is to be created, more time is required. The SA generated by IKEv2 is less than the one
generated by IKEv1. For an amplified packet size, the time taken to create an SA is almost constant.
• 
IKEv2 has faster rekey time. IKE v1 takes more time to rekey SAs than IKEv2. IKEv2 rekey for SA
offers improved security performance and decreases the number of packets lost in transition. Due to
the redefinition of certain mechanisms of IKEv1 (such as ToS payload, choice of SA lifetime, and SPI
uniqueness) in IKEv2, fewer packets are lost and duplicated in IKEv2. Therefore, there is less need to
rekey SAs.
• 
Note: Because network security can only be as strong as the weakest link, IKEv2 does not interoperate with
IKEv1.
Migration Overview
If your IKEv1, or even SSL, configuration already exists, the ASA makes the migration process simple. On
the command line, enter the migrate command:
migrate {l2l | remote−access {ikev2 | ssl} | overwrite}
Things of note:
Keyword definitions:
l2l − This converts current IKEv1 l2l tunnels to IKEv2.
♦ 
remote access − This converts the remote access configuration. You can convert either the
IKEv1 or the SSL tunnel groups to IKEv2.
♦ 
overwrite − If you have a IKEv2 configuration that you wish to overwrite, then this keyword
converts the current IKEv1 configuration and removes the superfluous IKEv2 configuration.
♦ 
• 
It is important to note that IKEv2 has the ability to use both symmetric as well as asymmetric keys for
PSK authentication. When the migration command is entered on the ASA, the ASA automatically
creates an IKEv2 VPN with a symmetric PSK.
•