IKE version 2 at a glance.

Blog

Dec 21, 2010 7:13 AM
Dec 21st, 2010

1. IPSec/IKE of yesterday.

I think we've been using IPSec VPN tunnels for a bit over a decade.

People treat IPSec and IKE/ISAKMP as the same thing, rightfully so since former cannot exist without the latter.

By now we're mostly used to some of the shortcomings of IKE, have learned to live with them or address them - sometimes in a proprietary way (think invalid SPI recovery or various vendor IDs).

2. IPSec/IKE of tomorrow - IKEv2.

So why reinvent the wheel?

Well the world move forward, we can do things better/faster, but most of all we have learned a few lessons - about what works and what doesn't work with currently adopted standard.

Thus IKEv2 has been created.

3. Major benefits of IKEv2.

From my perspective those are the most vital:

  1. Negotiation is shorter (you need typically 4 messages to establish a CHILD_SA)
  2. Simplicity 1 ; 4 message types IKE_SA_INIT , IKE_AUTH, CREATE_CHILD_SA, Informational.(2 messages of each type have to be exchanged)
  3. Simplicity 2 ; No more aggressive and main mode.
  4. Simplicity 3 ; No more huge amount of separate policies. Multiple "ORed" encryption, hash, Diffie-Hellman groups and prf functions supported in one policy.
  5. IKEv2 policies are agnostic to authentication method. Previously you had to define authentication mechanism in policy.
  6. Standardized essential features: liveness/DPD check, NAT detection, DoS (IP spoofing) protection.
  7. Informational messages have to be acknowledged. This should address some synchronization issues we saw with IKEv1.
  8. Xauth and mode config (phase 1.5 as it was called) is now done in standard way via EAP and CP (Configuration Payload).
  9. Asymmetric authentication. E.G. you can authenticate yourself with pre-shared-key and authenticate peer with certificates.

4. Considerations when implementing IKEv2.

Of course, I want everyone to be realistic. While I believe IKEv2 is the future, there are things to consider.

Vendors started implementing this feature recently, there will be problems ... Their names: bugs, crashes and interoperability - one cannot avoid it.

In new code, new bugs will be hidden.
If you're running an 24/7/365 business I would advise to carefully test this feature before implementation.

5. Platforms supporting IKEv2.

IOS supports following features with IKEv2:

- DVTI& SVTI with IKEv2

- DMVPN

- Lan-to-Lan with crypto maps.

and more (check feature navigator and configuration guide for your release).

ASA - soon (Q1 2011).

Anyconnect - soon (Q1 2011).

6. Further reading.

RFC 4306 http://tools.ietf.org/html/rfc4306

Wikipedia article on IKE and IKEv2: http://en.wikipedia.org/wiki/Internet_Key_Exchange

IOS 15.2M&T configuration guide for IKEv2/Flex:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/15-2mt/sec-flex-vpn-15-2mt-book.html

7. Comments? Feedback?

Drop a comment to this post!

Average Rating: 0 (0 ratings)

Comments

golly_wog Thu, 01/27/2011 - 13:20

Hi Marcin

Can you elaborate on the following for me please, in my limited testing I can always get a responder to respond to an initial packet?


Denial of Service (DoS) Attack Resilience

IKEv2 does not process a request until it determines the requester. This  addresses to some extent the DoS problems in IKEv1, which can be  tricked to perform much cryptographic (expensive) processing from false  locations (spoofing).


http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_ikev2.html

My findings of using the cookie-challange is that the responder does not calculate a cookie, from my limited understanding this is a prf and is processor intensive? Is that what the text above relates to?

Many thanks,

Marcin Latosiewicz Fri, 01/28/2011 - 00:27 (reply to golly_wog)

Golly_Wog,

Behavior on a IKEv2 peer regarding DoS will depend on implementation and configuration.

For example (as far I remember) IOS will send cookie only if in-progress negatiations are over a certain thershold.

The quote refers to cookie/DoS protection as a way for responder not to send IKE_SA_INIT which is both computationally intensive, but with cookie sent also no state kept on responder yet.

What is done in practice is that to initial request is "ignored" and IKEv2 peer sends header with cookie only.

Cookie itself is not computationally intensive. No state will be kept on responder until we receive the cookie back.

More info

http://tools.ietf.org/html/rfc4306 -> section.

2.6.  Cookies

Hope this helps,
if you have further questions, feel free to send me a message.

Marcin
Marcin Latosiewicz Tue, 02/22/2011 - 01:50 (reply to golly_wog)

Hello again Golly_Wog :-)

That's a cool article (one you linked here), especially since Tech Doc team on our side has not described this, yet.

Regarding ASA and IOS + PKI, I do not foresee many problems, both IOS and ASA IKEv2 implementation are based on exact same toolkit (with all good and bad that comes out of it).

I'm out of office for next few days, without access to lab, if you can remind me about this next Monday I'll gladly run some test :-)

Marcin

golly_wog Tue, 03/01/2011 - 11:21 (reply to golly_wog)

Hi Marcin

IOS - ASA wont work with PKI...

IOS uses http-url cert, whereas ASA doesn't. But, being a Security Genius, I bet that you would disable this on the IOS (no crypto ikev2 http-url cert), but.. then you would realise that the ASA fails on the authentication of the digital signature...

A bug will be raised and it will be fixed...


Many thanks mate.

CiscoCVS1 Tue, 07/19/2011 - 22:16

How does IKEv2 handle named tunnel-groups? With IKEv1 you had to use agressive mode, but now that is gone can you use named tunnel-groups still when using PSK?

Marcin Latosiewicz Wed, 07/20/2011 - 02:45 (reply to CiscoCVS1)

Hi,

"It depends" is smartest answer. On ASA you can still tweak "crypto iskamp identity" and land on a names tunnel on responder ASA.

With identity "hostname"

bsns-asa5505-19# show vpn-sessiondb det l2l

Session Type: LAN-to-LAN Detailed

Connection   : bsns-asa5505-30.cisco.com

Index        : 8                      IP Addr      : 10.48.67.54

Protocol     : IKEv2 IPsec

Encryption   : AES256                 Hashing      : SHA1

Bytes Tx     : 0                      Bytes Rx     : 0

Login Time   : 09:33:40 UTC Wed Jul 20 2011

Duration     : 0h:00m:45s

IKEv2 Tunnels: 1

IPsec Tunnels: 1

With identity "auto"

bsns-asa5505-19# show vpn-sessiondb l2l

Session Type: LAN-to-LAN

Connection   : DefaultL2LGroup

Index        : 9                      IP Addr      : 10.48.67.54

Protocol     : IKEv2 IPsec

Encryption   : AES256                 Hashing      : SHA1

Bytes Tx     : 0                      Bytes Rx     : 0

Login Time   : 09:39:12 UTC Wed Jul 20 2011

Duration     : 0h:00m:03s

Edit (forgot to mention IOS)

And for IOS, you can tweak local identity in profile which should do the trick:

http://www.cisco.com/en/US/partner/docs/ios/security/command/reference/sec_i1.html#wp1088877

Actions

Login or Register to take actions

This Blog

Posted December 21, 2010 at 7:13 AM
Stats:
Comments:9 Avg. Rating:0
Views:13437   
Shares:0

Related Content

Blogs Leaderboard