IKEv2 improves on IKEv1 by reducing bandwidth usage, supporting EAP authentication and mobile devices, incorporating NAT traversal, and enabling automatic reconnection of broken tunnels.
IKEv2 improves on IKEv1 by reducing bandwidth usage, supporting EAP authentication and mobile devices, incorporating NAT traversal, and enabling automatic reconnection of broken tunnels.
IKEv2 improves on IKEv1 by reducing bandwidth usage, supporting EAP authentication and mobile devices, incorporating NAT traversal, and enabling automatic reconnection of broken tunnels.
IKEv2 improves on IKEv1 by reducing bandwidth usage, supporting EAP authentication and mobile devices, incorporating NAT traversal, and enabling automatic reconnection of broken tunnels.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1/ 3
Difference Between IKEv1 and IKEv2
IKEv1 vs IKEv2
“IKE,” which stands for “Internet Key Exchange,” is a protocol that belongs to the IPsec protocols suite. Its responsibility is in setting up security associations that allow two parties to send data securely. IKE was introduced in 1998 and was later superseded by version 2 roughly 7 years later. There are a number of differences between IKEv1 and IKEv2, not the least of which is the reduced bandwidth requirements of IKEv2. Freeing up bandwidth is always a good thing as the extra bandwidth can be used for the transmission of data.
Another difference between IKEv1 and IKEv2 is the inclusion of EAP authentication in the latter. IKEv1 does not support EAP and can only choose between a pre-shared key and certificate authentication which IKEv2 also supports. EAP is essential in connecting with existing enterprise authentication systems. IKEv2 also introduces MOBIKE; a feature not found on IKEv1. MOBIKE allows IKEv2 to be used in mobile platforms like phones and by users with multi-homed setups.
Another difference between IKEv1 and IKEv2 is the incorporation of NAT traversal in the latter. NAT traversal is necessary when a router along the route performs Network Address Translation. This is when a router captures the packets sent and modifies the destination address on the packets. This is typical when multiple users are using the same Internet connection thus giving them the same IP address. This is not a problem with ordinary activities like browsing but can be a significant problem when IPsec is needed. That is why IKEv2 has a significant advantage over IKEv1
Lastly, IKEv2 has been improved so that it is able to detect whether the tunnel is still alive or not. This is commonly referred to as a “liveness” check. If the liveness check fails, caused by the tunnel breaking down, IKEv2 is then able to re-establish the connection automatically. IKEv1 does not have this ability and would just assume that the connection is always up thus having quite an impact on reliability. There are several workarounds for IKEv1, but these are not standardized.
Summary:
1.IKEv2 does not consume as much bandwidth as IKEv1.
2.IKEv2 supports EAP authentication while IKEv1 doesn’t. 3.IKEv2 supports MOBIKE while IKEv1 doesn’t. 4.IKEv2 has built-in NAT traversal while IKEv1 doesn’t. 5.IKEv2 can detect whether a tunnel is still alive while IKEv1 cannot.
Share this:
Read more: Difference Between IKEv1 and IKEv2 | Difference Between | IKEv1 vs IKEv2http://www.differencebetween.net/technology/protocols-formats/difference-between-ikev1-and- ikev2/#ixzz4EJE1WtrQ Appendix A: Summary of changes from IKEv1
The goals of this revision to IKE are:
1) To define the entire IKE protocol in a single document, replacing
RFCs 2407, 2408, and 2409 and incorporating subsequent changes to support NAT Traversal, Extensible Authentication, and Remote Address acquisition;
2) To simplify IKE by replacing the eight different initial exchanges
with a single four-message exchange (with changes in authentication mechanisms affecting only a single AUTH payload rather than restructuring the entire exchange) see [PK01];
3) To remove the Domain of Interpretation (DOI), Situation (SIT), and
Labeled Domain Identifier fields, and the Commit and Authentication only bits;
4) To decrease IKE's latency in the common case by making the initial
exchange be 2 round trips (4 messages), and allowing the ability to piggyback setup of a CHILD_SA on that exchange;
5) To replace the cryptographic syntax for protecting the IKE
messages themselves with one based closely on ESP to simplify implementation and security analysis;
6) To reduce the number of possible error states by making the
protocol reliable (all messages are acknowledged) and sequenced. This allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2;
7) To increase robustness by allowing the responder to not do
significant processing until it receives a message proving that the initiator can receive messages at its claimed IP address, and not commit any state to an exchange until the initiator can be cryptographically authenticated;
8) To fix cryptographic weaknesses such as the problem with
symmetries in hashes used for authentication documented by Tero Kivinen;
9) To specify Traffic Selectors in their own payloads type rather
than overloading ID payloads, and making more flexible the Traffic Selectors that may be specified;
10) To specify required behavior under certain error conditions or
when data that is not understood is received, to make it easier to make future revisions that do not break backward compatibility;
Kaufman Standards Track [Page 96]
RFC 4306 IKEv2 December 2005
11) To simplify and clarify how shared state is maintained in the presence of network failures and Denial of Service attacks; and
12) To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be enhanced to support IKEv2 with minimum effort.
