Cisco ASA IKEv2 PKI Site-Site VPN

Cisco ASA IKEv2 PKI Site-Site VPN

 

 

Hi

For the last couple of weeks I’ve been trying to get a IKEv2 site-to-site VPN working between a 2921 running 15.13T and an ASA running 8.4.1. After spending long into the night tearing my hair out, I’ve found out that it’s not working due to a bug, seems that the ASA doesn’t like authenticating the digital signature of the IOS device…  I can’t believe that Cisco released ASA 8.4.1 without testing this with it’s own products… L

One thing I did learn in my troublesome experience is that the ASA currently (8..4.1), does not support the transport of certs using http, as defined in RFC 5996 “Implementations MUST support the HTTP [HTTP] method for hash-and-URL lookup.  The behavior of other URL methods [URLS] is not currently specified, and such methods SHOULD NOT be used in the absence of a document specifying them.“

Once the bug with IOS – ASA IKEv2 using PKI is fixed, assuming that the ASA still doesn’t support HTTP Certs, then the IOS device should disable sending these using the command no crypto ikev2 http-url cert

To create the IKEv2 PKI VPN between two ASA’s I used the following setup, both ASA’s have a default route to each other.  Router R1 has a default route of ASA1, with router R2 having a default route of ASA2. The CA server was a 2921 setup to automatically grant certs. The CA was setup as a NTP Master, so both ASA’s could sync time. Although I haven’t shown it, both ASA’s were authenticated and enrolled to the CA, to gain a PKI certificate.

 

 

The following relevant code is off the devices

 

 

ASA1(config)# sh run

!

interface Ethernet0/0

nameif outside

security-level 0

ip address 172.16.1.10 255.255.255.0

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 1.1.1.1 255.255.255.0

!

access-list 100 extended permit ip 1.1.1.0 255.255.255.0 2.2.2.0 255.255.255.0

route outside 0.0.0.0 0.0.0.0 172.16.1.20 1

crypto ipsec ikev2 ipsec-proposal prop1

protocol esp encryption 3des

protocol esp integrity sha-1

crypto map mymap 10 match address 100

crypto map mymap 10 set peer 172.16.1.20

crypto map mymap 10 set ikev2 ipsec-proposal prop1

crypto map mymap 10 set trustpoint CA

crypto map mymap interface outside

crypto ca trustpoint CA

enrollment url http://172.16.1.1:80

crypto ikev2 policy 10

encryption aes

integrity sha

group 5

prf sha

lifetime seconds 86400

crypto ikev2 enable outside

ntp server 172.16.1.1

tunnel-group 172.16.1.20 type ipsec-l2l

tunnel-group 172.16.1.20 ipsec-attributes

ikev2 remote-authentication certificate

ikev2 local-authentication certificate CA

!

ASA2(config)# sh run

: Saved

:

ASA Version 8.4(1)

!

hostname ASA2

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface Ethernet0/0

nameif outside

security-level 0

ip address 172.16.1.20 255.255.255.0

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 2.2.2.1 255.255.255.0

!

access-list 100 extended permit ip 2.2.2.0 255.255.255.0 1.1.1.0 255.255.255.0

route outside 0.0.0.0 0.0.0.0 172.16.1.10 1

crypto ipsec ikev2 ipsec-proposal prop1

protocol esp encryption 3des

protocol esp integrity sha-1

crypto map mymap 10 match address 100

crypto map mymap 10 set peer 172.16.1.10

crypto map mymap 10 set ikev2 ipsec-proposal prop1

crypto map mymap 10 set trustpoint CA

crypto map mymap interface outside

crypto ca trustpoint CA

enrollment url http://172.16.1.1:80

crl configure

crypto ikev2 policy 10

encryption aes

integrity sha

group 5

prf sha

lifetime seconds 86400

crypto ikev2 enable outside

ntp server 172.16.1.1

tunnel-group 172.16.1.10 type ipsec-l2l

tunnel-group 172.16.1.10 ipsec-attributes

ikev2 remote-authentication certificate

ikev2 local-authentication certificate CA

!

 

 

Once interesting traffic was sent to initiate the VPN, the IKEv2 tunnel was built, this can be seen below;

 

 

ASA1(config)# sh crypto ikev2 sa detail

IKEv2 SAs:

Session-id:1, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id                 Local                Remote     Status         Role

2783320215       172.16.1.10/500       172.16.1.20/500      READY    RESPONDER

Encr: AES-CBC, keysize: 128, Hash: SHA96, DH Grp:5, Auth sign: RSA, Auth verify: RSA

Life/Active Time: 86400/94 sec

Session-id: 1

Status Description: Negotiation done

Local spi: E20EE7647CF3B613       Remote spi: 24694BEFF9BA836B

Local id: hostname=ASA1

Remote id: hostname=ASA2

Local req mess id: 1              Remote req mess id: 3

Local next mess id: 1             Remote next mess id: 3

Local req queued: 1               Remote req queued: 3

Local window: 1                   Remote window: 1

DPD configured for 10 seconds, retry 2

NAT-T is not detected

Child sa: local selector  1.1.1.0/0 – 1.1.1.255/65535

remote selector 2.2.2.0/0 – 2.2.2.255/65535

ESP spi in/out: 0x7f862e62/0x819dc0ef

AH spi in/out: 0x0/0x0

CPI in/out: 0x0/0x0

Encr: 3DES, esp_hmac: SHA96

ah_hmac: None, comp: IPCOMP_NONE, mode tunnel

From the above output we can tell that ASA2 must have initiated the setup o the VPN as ASA1 is the RESPONDER.

 

The IPSEC tunnel is exactly the same as in an IKEv1 established tunnel;

ASA1(config)#  sh crypto ipsec sa detail

interface: outside

Crypto map tag: mymap, seq num: 10, local addr: 172.16.1.10

access-list 100 extended permit ip 1.1.1.0 255.255.255.0 2.2.2.0 255.255.255.0

local ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (2.2.2.0/255.255.255.0/0/0)

current_peer: 172.16.1.20

#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5

#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 5, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#pkts no sa (send): 0, #pkts invalid sa (rcv): 0

#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0

#pkts invalid prot (rcv): 0, #pkts verify failed: 0

#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0

#pkts invalid pad (rcv): 0,

#pkts invalid ip version (rcv): 0,

#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0

#pkts replay failed (rcv): 0

#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0

#pkts internal err (send): 0, #pkts internal err (rcv): 0

local crypto endpt.: 172.16.1.10/500, remote crypto endpt.: 172.16.1.20/500

path mtu 1500, ipsec overhead 58, media mtu 1500

current outbound spi: 819DC0EF

current inbound spi : 7F862E62

inbound esp sas:

spi: 0x7F862E62 (2139500130)

transform: esp-3des esp-sha-hmac no compression

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 4096, crypto-map: mymap

sa timing: remaining key lifetime (kB/sec): (4101119/28638)

IV size: 8 bytes

replay detection support: Y

Anti replay bitmap:

0x00000000 0x000007FF

outbound esp sas:

spi: 0x819DC0EF (2174599407)

transform: esp-3des esp-sha-hmac no compression

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 4096, crypto-map: mymap

sa timing: remaining key lifetime (kB/sec): (4239359/28638)

IV size: 8 bytes

replay detection support: Y

Anti replay bitmap:

0x00000000 0x00000001

It’s well known that IKEv1 is vulnerable to a DOS attack, whereby an attacker can send many IKE phase 1 packets that can exhaust a devices resources, this is documented below

 

http://www.cisco.com/en/US/products/products_security_response09186a00806f33d4.html

 

I now wanted to test the cookie-challenge feature of IKEv2, this mitigates this attack by sending back a cookie challenge and storing no state on the device, this is explained below

 

http://www.it-book.co.uk/814/cisco-ike-version-2-site-to-site-vpn-using-psk

 

I enabled the following command on ASA1

 

crypto ikev2 cookie-challenge always

 

I thought that enabling cookie challenge would mitigate the IKE DOS vulnerability; however my findings below make interesting reading…

 

I captured an initial IKEv2 packet (KE_INIT_SA, from ASA2 to ASA1 and replayed this using tcpreplay, ASA1 would correctly reply to the packet with a cookie challenge packet,  the following are the syslog from ASA1 when it  receives a IKE_INIT_SA

 

Mar 04 2011 11:07:55: %ASA-5-750002: Local:172.16.1.10:500 Remote:172.16.1.20:500 Username:Unknown Received a IKE_INIT_SA request

Mar 04 2011 11:07:55: %ASA-5-750004: Local:172.16.1.10:500 Remote:172.16.1.20:500 Username:Unknown Sending COOKIE challenge to throttle possible DoS

I  decided to send 100000 packets to see how much ASA1 could handle, these were sent in in 9.11 Seconds, running @ 41.83Mbps (10965.19 pps)
As you can see the  IKEv2 daemon was nailed! J

 

ASA1(config)# sh processes cpu-usage sorted

PC         Thread       5Sec     1Min     5Min   Process

0x081362ad   0xd71b3fa0    88.9%    21.0%     4.8%   IKEv2 Daemon

I then crafted a IKE_INIT_SA packet to appear to come from another IKEv2 host (172.16.1.30), destined to ASA1, I replayed this 100000 times with the same result – the IKEv2 daemon being nailed, this was although  there was no entry in the crypto map.

 

So it seems that if you enable IKEv2, it would be a good idea to only allow IKE traffic from known peers. Here’s a neat trick I was taught by  the Cisco Firewall legend, David White Jnr…
We create an ACL on ASA1 to only allow IKE packets from ASA2, all other IKE traffic will be dropped. A standard ACL applied to an interface will only block traffic moving through the ASA, not to the ASA itself, however we can filter traffic to the device itself by amending the control-plane command to the end of the line. Note: In testing sometimes I need to bounce the ASA after applying this  code for it to take effect

 

access-list 150 extended permit udp host 172.16.1.20 eq isakmp host 172.16.1.10 eq isakmp

access-list 150 extended deny udp any eq isakmp host 172.16.1.10 eq isakmp

access-list 150 extended permit ip any any

access-group 150 in interface outside control-plane

The above command will drop any non-legit IKE traffic to ASA1.

 

I now replay 100000 copies of the IKE_INIT_SA packet from 172.16.1.30 to ASA1, which results in the packets being dropped before they hit the CPU, I believe that the Dispatch Unit is what takes packets off the wire. Here we can see that the IKEv2 daemon is not effected by rouge packets.

 

ASA1(config)# sh processes cpu-usage sorted

PC         Thread       5Sec     1Min     5Min   Process

0x081ecc51   0xd71c0f3c    65.6%     5.3%     1.1%   Dispatch Unit

0x08e5f07c   0xd71b9c58     6.3%     0.5%     0.1%   Logger

Attached is the pcap that I replayed  from ASA2 to ASA1

 

 

 

Comments 1

Leave a Reply

Your email address will not be published. Required fields are marked *