navbarPDF
Strip_SecurityNotices

Cisco Security Response: Internet Key Exchange Resource Exhaustion Attack

Document ID: 70810

http://www.cisco.com/warp/public/707/cisco-sr-20060726-ike.shtml

Revision 2.3

Last Updated 2008 July 25 1900 UTC (GMT)

For Public Release 2006 July 26 1600 UTC (GMT)

Please provide your feedback on this document.

Contents

Cisco Response
Additional Information
Revision History
Cisco Security Procedures

Cisco Response

This is a Cisco response to an advisory published by an unaffiliated third party, Roy Hills, of NTA Monitor Ltd posted as of July 26, 2006 at http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html, and entitled: Cisco VPN Concentrator IKE resource exhaustion DoS.

This issue is being tracked by the following Cisco Bug IDs:

We thank Roy Hills from NTA Monitor Ltd for reporting this issue to Cisco. We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in product reports.

Additional Information

Vulnerability Impact Overview

Cisco devices which implement the IKE version 1 protocol may be vulnerable to an attack that attempts to exploit limitations of the IKE version 1 protocol in order to deplete available resources to negotiate IKE SAs (Security Associations) and block legitimate IPSec peers from establishing new IKE SAs or rekey existing IKE SAs. The vulnerability is inherent to the IKE version 1 protocol and is not specific to any vendor implementation.

This attack may cause IKE resource depletion and VPN termination devices that are under attack may not allow legitimate VPN connection requests or in some cases drop already established connections during rekey. IOS devices without Call Admission Control for IKE configured may exhibit high CPU utilization if attacked and may not perform as expected. IKE CAC is not enabled by default on those IOS releases that support it.

Networks designed with multiple dedicated VPN termination points at different ingress locations should only be minimally impacted as long as VPN client devices are configured to connect to alternate VPN termination points if their primary VPN termination point is not available.

Organizations should follow their standard risk mitigation process to determine the potential impact of this issue. A document that may be used to aid in risk triage is available at http://www.cisco.com/web/about/security/intelligence/vulnerability-risk-triage.html.

Mitigation Overview

On IOS platforms, the Call Admission Control for IKE feature will aid in preventing an attacker from exploiting this issue to exhaust CPU resources and impact service for non-IKE traffic. For Site-to-Site IPSec tunnels, Interface access-lists may also provide some mitigation though the source IP addresses of IKE messages may be spoofed, which may limit the effectiveness of these access-lists.

On PIX, ASA, Firewall Service module Firewalls, and the VPN 3000 Series Concentrators there are built-in resource protection mechanisms to prevent an attacker from exploiting this issue to exhaust CPU resources and impact service for non-IKE traffic.

Device-Specific Mitigation and Identification

Internet Edge Router

The Internet Edge router does not terminate IPSec but is positioned to mitigate and detect attempted exploitation of this issue.

Mitigation

Identification

IOS VPN Routers

Mitigation

Networks designed with multiple dedicated VPN termination points at different ingress locations should only be minimally impacted as long as VPN client devices are configured to connect to alternate VPN termination points if their primary VPN termination point is not available.

Identification

IOS-XR Routers

Mitigation

GSR (c12000) and CRS-1 routers running IOS-XR software support software-based IPSec for locally sourced and terminated traffic only (used mostly for routing protocols). IKE and IPSec support was added on Release R2.0 for CRS-1 and on Release R3.2 for GSR. The IOS-XR software is designed to limit the impact of such an attack on system resources consumed by users already connected. IOS-XR has a hard-coded limit of 500 IKE SAs (which includes both established and embryonic IKE connections). If new IKE initiator packets are received and the available IKE negotiation slots are full, the new request will be discarded. This prevents CPU processing power and memory resources from being fully consumed by incoming IKE requests. The finite IKE negotiation slot design prevents new tunnel requests from degrading existing tunnels and other functions performed by the router. The design goals of IOS-XR software are to allow the box to survive an attack without jeopardizing the tunnels already established.

Legitimate IKE initiator packets from valid users will have to compete for slots with an attacking stream of packets. An incoming attack stream of IKE initiator requests does not render the GSR/CRS-1 running IOS-XR incapable of connecting a valid user, it simply reduces the likelihood that an IKE negotiation slot will be available when the user request arrives.

While under this type of attack, the GSR/CRS-1 running IOS-XR software:

Peer requests for IKE Phase-1 re-keys have to contend for IKE negotiation slots with attacking packets and will be discarded if no slots are available. However, if a tunnel re-key has not already been initiated by the peer, the GSR or CRS-1 running IOS-XR software will initiate one itself as the negotiated lifetime approaches. Re-keys initiated by the GSR/CRS-1 are not subject to the concurrent IKE negotiation limits since the IKE initiator request in this case is outbound. Given this, no re-keys of valid peers should be blocked by this type of attack.

Identification

Cisco ASA 7.X Firewalls for VPN

Mitigation

When valid IKE initiator packets are presented to a PIX or ASA running 7.X from an attacker, they will compete with IKE initiator packets from legitimate users attempting to connect. PIX and ASA running 7.X have a finite number of slots to use for incoming IKE negotiation as shown in the table below.

PIX/ASA 7.X Platform

Embryonic IKE SA Limit

PIX 515

400

PIX 525

600

PIX 535

1000

ASA 5510

50

ASA 5520

250

ASA 5540

1000

ASA 5550

1000

ASA software version 7.X is designed to limit the impact of such an attack on system resources consumed by users already connected. If new IKE initiator packets are received and the available IKE negotiation slots are full, the new request will be discarded. This prevents CPU processing power and memory resources from being fully consumed by incoming IKE requests. The finite IKE negotiation slot design prevents new tunnel requests from degrading existing tunnels and other functions performed by the firewall. The design goals of ASA software version 7.X are to allow the box to survive an attack without jeopardizing the tunnels already established.

Legitimate IKE initiator packets from valid users will have to compete for slots with an attacking stream of packets. An incoming attack stream of IKE initiator requests does not render the PIX or ASA running 7.X incapable of connecting a valid user, it simply reduces the likelihood that an IKE negotiation slot will be available when the user request arrives.

While under this type of attack, the PIX or ASA running 7.X:

Peer requests for IKE Phase-1 re-keys have to contend for IKE negotiation slots with attacking packets and will be discarded if no slots are available. However, if a tunnel re-key has not already been initiated by the peer, the PIX or ASA running 7.X will initiate one itself as the negotiated lifetime approaches. Re-keys initiated by the ASA are not subject to the concurrent IKE negotiation limits since the IKE initiator request in this case is outbound. Given this, no re-keys of valid peers should be blocked by this type of attack.

SSL VPN (WebVPN) with the SVC Client is a functionally equivalent alternative to IPSec for Remote Access users. SSL has been shown to not be vulnerable to the same attack. For additional information on configuring SSL VPN refer to the following link:

http://www.cisco.com/en/US/products/ps6120/products_configuration_guide_chapter09186a0080334071.html

Identification

More IKE connection attempts than there are Embryonic IKE SA connection slots on the PIX or ASA will result in the generation of an informational level (severity 6) Syslog message. The Syslog message is %PIX | ASA-6-713905 which has this format:

%PIX-6-713905: IP = 192.0.2.145, Duplicate first packet detected. Ignoring packet.

OR

%ASA-6-713905: IP = 192.0.2.145, Duplicate first packet detected. Ignoring packet.

Additional information on those syslog messages can be found at http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_system_message_guide_chapter09186a008055fd2b.html#wp1304348.

The IP = shown is the source IP address of the IKE connection attempt. Multiple or continuous %PIX | ASA-6-713905 messages should be investigated to determine if this issue is being exploited.

show crypto isakmp stats - There is a statistics value that is incremented every time an IKE negotiation fails because the peer (as Initiator) does not respond. The value is Responder Fails under the global IKE/isakmp stats. An abnormally high number of Responder Fails may indicate that the device has been attacked.

Here is an example output:

ASA(config)#show crypto isakmp stats

Global IKE Statistics
Active Tunnels: 1
Previous Tunnels: 13
In Octets: 31161
In Packets: 91
In Drop Packets: 0
In Notifys: 0
In P2 Exchanges: 13
In P2 Exchange Invalids: 0
In P2 Exchange Rejects: 0
In P2 Sa Delete Requests: 0
Out Octets: 16648
Out Packets: 120
Out Drop Packets: 0
Out Notifys: 62
Out P2 Exchanges: 0
Out P2 Exchange Invalids: 0
Out P2 Exchange Rejects: 0
Out P2 Sa Delete Requests: 12
Initiator Tunnels: 0
Initiator Fails: 0
Responder Fails: 8405
System Capacity Fails: 0
Auth Fails: 0
Decrypt Fails: 0
Hash Valid Fails: 0
No Sa Fails: 0

In the above example 8405 IKE negotiations failed because the responder did not reply.

Cisco PIX 6.X Firewalls for VPN

Mitigation

When valid IKE initiator packets are presented to a PIX from an attacker, they will compete with IKE initiator packets from legitimate users attempting to connect. PIX's have a finite number of slots to use for incoming IKE negotiation as shown in the table below.

PIX 6.X Platform

Embryonic IKE SA Limit

All PIX Firewall platforms running 6.X software

500

The PIX is designed to limit the impact of such an attack on system resources consumed by users already connected. If new IKE initiator packets are received and the available IKE negotiation slots are full, the new request will be discarded. This prevents CPU processing power and memory resources from being fully consumed by incoming IKE requests. The finite IKE negotiation slot design prevents new tunnel requests from degrading existing tunnels and other functions performed by the firewall. The design goals of the PIX are to allow the box to survive an attack without jeopardizing the tunnels already established.

Legitimate IKE initiator packets from valid users will have to compete for slots with an attacking stream of packets. An incoming attack stream of IKE initiator requests does not render the PIX incapable of connecting a valid administrator, it simply reduces the likelihood that an IKE negotiation slot will be available when the user request arrives.

While under this type of attack, the PIX:

Peer requests for IKE Phase-1 re-keys have to contend for IKE negotiation slots with attacking packets and will be discarded if no slots are available. However, if a tunnel re-key has not already been initiated by the peer, the PIX will initiate one itself as the negotiated lifetime approaches. Re-keys initiated by the PIX are not subject to the concurrent IKE negotiation limits since the IKE initiator request in this case is outbound. Given this, no re-keys of valid peers should be blocked by this type of attack.

Identification

More IKE connection attempts than there are Embryonic IKE SA connection slots on the PIX will result in the generation of an error level (severity 3) Syslog message. The Syslog message is %PIX-3-ISAKMP: Exceeded embryonic limit.

Cisco 3000 Series VPN Concentrators

Mitigation

When valid IKE initiator packets are presented to a VPN3000 Concentrator from an attacker, they will compete with IKE initiator packets from legitimate end-users attempting to connect. VPN3000 Concentrators have a finite number of slots to use for incoming IKE negotiation as shown in the table below.

VPN3000 Platform

Embryonic IKE SA Limit

VPN 3005

15

VPN 3015

15

VPN 3020

40

VPN 3030

40

VPN3060

40

VPN 3080

40

The VPN3000 system is designed to limit the impact of such an attack on system resources consumed by users already connected. If new IKE initiator packets are received and the available IKE negotiation slots are full, the new request will be discarded. This prevents CPU processing power and memory resources from being fully consumed by incoming IKE requests. The finite IKE negotiation slot design prevents new tunnel requests from degrading existing tunnels. The design goals of the VPN3000 are to allow the box to survive an attack without jeopardizing the tunnels already established and other functions performed by the device.

Legitimate IKE initiator packets from valid end users will have to compete for slots with an attacking stream of packets. An incoming attack stream of IKE initiator requests does not render the VPN3000 incapable of connecting a valid user, it simply reduces the likelihood that an IKE negotiation slot will be available when the user request arrives.

While under this type of attack, the VPN3000:

Peer requests for IKE Phase-1 re-keys have to contend for IKE negotiation slots with attacking packets and will be discarded if no slots are available. However, if a tunnel re-key has not already been initiated by the peer, the VPN3000 will initiate one itself as the negotiated lifetime approaches. Re-keys initiated by the VPN3000 are not subject to the concurrent IKE negotiation limits since the IKE initiator request in this case is outbound. Given this, no re-keys of valid peers should be blocked by this type of attack.

Identification

If an IKE initiator request is received by a VPN3000 Concentrator but there is no available slot to process it, an event will be generated to indicate this condition. The event generated is defined as:

An example of this event is:

28304 07/10/2006 08:08:33.500 SEV=4 IKE/191 RPT=278 192.0.2.111 Maximum concurrent IKE negotiations exceeded.

Note that the Repeat Count (RPT) and source IP Address are indicated in the event header.

The occurrence of this event does not always indicate a malicious attack. This can occur when valid user connection requests are received close together. This condition can also be induced if there are a number of hardware clients all attempting to re-establish connection if there was a network outage or after a maintenance reboot of the VPN3000 Concentrator. The software clients and hardware clients will retry their requests and ultimately connect as negotiation slots open up.

Firewall Services Module

Mitigation

When valid IKE initiator packets are presented to a Firewall Service Module (FWSM) from an attacker, they will compete with IKE initiator packets from legitimate administrators attempting to connect. FWSMs have a finite number of slots to use for incoming IKE negotiation as shown in the table below.

FWSM Software Version

Embryonic IKE SA Limit

FWSM 2.X Single Mode

5

FWSM 2.X Multi Mode

10

FWSM 3.X All Modes

50

The FWSM is designed to limit the impact of such an attack on system resources consumed by administrators already connected. If new IKE initiator packets are received and the available IKE negotiation slots are full, the new request will be discarded. This prevents CPU processing power and memory resources from being fully consumed by incoming IKE requests. The finite IKE negotiation slot design prevents new tunnel requests from degrading existing tunnels. The design goals of the FWSM are to allow the box to survive an attack without jeopardizing the tunnels already established.

Legitimate IKE initiator packets from valid administrators will have to compete for slots with an attacking stream of packets. An incoming attack stream of IKE initiator requests does not render the FWSM incapable of connecting a valid administrator, it simply reduces the likelihood that an IKE negotiation slot will be available when the administrator request arrives.

While under this type of attack, the FWSM:

Peer requests for IKE Phase-1 re-keys have to contend for IKE negotiation slots with attacking packets and will be discarded if no slots are available. However, if a tunnel re-key has not already been initiated by the peer, the FWSM will initiate one itself as the negotiated lifetime approaches. Re-keys initiated by the FWSM are not subject to the concurrent IKE negotiation limits since the IKE initiator request in this case is outbound. Given this, no re-keys of valid peers should be blocked by this type of attack.

Identification

MDS

Mitigation

Identification

Revision History

Revision 2.3

2008-July-28

Added bug id CSCsb50996 to the list of bugs affecting Cisco PIX firewalls running pre-7.x code.

Revision 2.2

2006-September-01

Added information about GDOI to IOS mitigation sections.

Revision 2.1

2006-August-17

Added Cisco Bug ID for IOS-XR devices. Edited IOS-XR section to fix typos.

Revision 2.0

2006-August-08

Added detection and mitigation steps for affected devices.

Revision 1.3

2006-August-08

Added Cisco Bug ID for SAN-OS on MDS devices.

Revision 1.2

2006-August-01

Added Cisco Bug IDs for FWSM, ASA, and PIX devices running v7.x code.

Revision 1.1

2006-July-26

Updated Cisco Bug ID for VPN 3000 concentrators.

Revision 1.0

2006-July-26

Initial public release.

Cisco Security Procedures

Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt.

Related Information

Toolbar

Updated: Sep 01, 2006Document ID: 70810