IKE V2 benefits

[Don_Paterson]

Does Check Point have any documentation specifically on IKE V2 and benefits (and limitations) from a Check Point perspective?

I can't find any SK or guide apart from the VPN Admin Guides.

Thanks,

Don

[the_rock]

I never seen any sk about it myself, but I know generally speaking, ikev2 is more secure, faster and more reliable and uses less bandwidth compared to ikev1.

Andy

[Alex-]

I don't think there are specifically for CP, but Wikipedia has an interesting list: https://en.wikipedia.org/wiki/Internet_Key_Exchange

Improvements with IKEv2

This section may be confusing or unclear to readers. Please help clarify the section. There might be a discussion about this on the talk page. (February 2009) (Learn how and when to remove this message)

The IKEv2 protocol was described in Appendix A of RFC 4306 in 2005. The following issues were addressed:

• Fewer Requests for Comments (RFCs): The specifications for IKE were covered in at least three RFCs, more if one takes into account NAT traversal and other extensions that are in common use. IKEv2 combines these in one RFC as well as making improvements to support for NAT traversal (Network Address Translation (NAT)) and firewall traversal in general.
• Standard Mobility support: There is a standard extension for IKEv2 named [rfc:4555 Mobility and Multihoming Protocol] (MOBIKE) (see also, IPsec) used to support mobility and multihoming for it and Encapsulating Security Payload (ESP). By use of this extension IKEv2 and IPsec can be used by mobile and multihomed users.
• NAT traversal: The encapsulation of IKE and ESP in User Datagram Protocol (UDP port 4500) enables these protocols to pass through a device or firewall performing NAT.^[14]
• Stream Control Transmission Protocol (SCTP) support: IKEv2 allows for the SCTP protocol as used in Internet telephony protocol, Voice over IP (VoIP).
• Simple message exchange: IKEv2 has one four-message initial exchange mechanism where IKE provided eight distinctly different initial exchange mechanisms, each one of which had slight advantages and disadvantages.
• Fewer cryptographic mechanisms: IKEv2 uses cryptographic mechanisms to protect its packets that are very similar to what IPsec ESP uses to protect the IPsec packets. This led to simpler implementations and certifications for Common Criteria and FIPS 140-2(Federal Information Processing Standard (FIPS), which require each cryptographic implementation to be separately validated.
• Reliability and State management: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing logistics and shared state management. IKE could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other to initiate an action - which never eventuated. Work arounds (such as Dead-Peer-Detection) were developed but not standardized. This meant that different implementations of work-arounds were not always compatible.
• Denial of Service (DoS) attack resilience: IKEv2 does not perform much processing until it determines if the requester actually exists. This addressed some of the DoS problems suffered by IKE which would perform a lot of expensive cryptographic processing from spoofed locations.

Supposing HostA has a Security Parameter Index (SPI) of A and HostB has an SPI of B, the scenario would look like this:

HostA -------------------------------------------------- HostB
     |HDR(A,0),sai1,kei,Ni-------------------------->   |
     |   <----------------------------HDR(A,0),N(cookie)|
     |HDR(A,0),N(cookie),sai1,kei,Ni---------------->   |
     |   <--------------------------HDR(A,B),SAr1,ker,Nr|

If HostB (the responder) is experiencing large amounts of half-open IKE connections, it will send an unencrypted reply message of IKE_SA_INIT to HostA (the initiator) with a notify message of type COOKIE, and will expect HostA to send an IKE_SA_INIT request with that cookie value in a notify payload to HostB. This is to ensure that the initiator is really capable of handling an IKE response from the responder.

[Timothy_Hall · Accepted solution]

In my classes I summarize IKEv2 as a simplification and roll-up of RFC features like DPD/NAT-T that were tacked on to the original IKEv1 to handle situations not envisioned in the original IKEv1 spec (which was codified in the late 1990s).  IKEv2 also supports IPv6. 

In regards to security of IKEv1 vs. IKEv2, as noted by Wikipedia IKEv2 is more resistant to DoS attacks, but overall IKEv1 is still plenty secure as long as the the proper encryption/hashing algorithms and Diffie Hellman groups are employed. 

My overall recommendation is to use IKEv2 (especially for Check Point to Check Point VPNs) but if functionality or stability issues are encountered with IKEv2 in an interoperable scenario, do not hesitate to return to IKEv1.  It took almost ten years for IKEv1 interoperability to become more or less seamless, and IKEv2 has definitely had some growing pains.  Mention the term "IKEv2 tunnel narrowing" to an experienced Check Point VPN administrator and watch them shudder.

[Don_Paterson]

Thanks Tim and Alex, much appreciated.

It does seem like an SK could be beneficial to have in Support Center to cover IKE V2 from a Check Point perspective.

It could cover FAQs and other things like R82 gateway support for remote access with IKE V2.

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_RemoteAccessVPN_AdminGuide/Content...