Browse Prior Art Database

EFFICIENT LIVENESS CHECK TO A IKEv2 HEADEND

IP.com Disclosure Number: IPCOM000243193D
Publication Date: 2015-Sep-17
Document File: 6 page(s) / 4M

Publishing Venue

The IP.com Prior Art Database

Related People

Graham Bartlett: AUTHOR

Abstract

A liveness check is provided to determine if the Internet Key Exchange version 2 (IKEv2) service is functioning without causing a Denial of Service condition on the IKEv2 service. A lightweight probe allows for fast failover and near seamless Virtual Private Network (VPN) connectivity.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 01 of 6

EFFICIENT LIVENESS CHECK TO A IKEv2 HEADEND

AUTHOR:

Graham Bartlett

CISCO SYSTEMS, INC.

ABSTRACT

    A liveness check is provided to determine if the Internet Key Exchange version 2 (IKEv2) service is functioning without causing a Denial of Service condition on the IKEv2 service. A lightweight probe allows for fast failover and near seamless Virtual Private Network (VPN) connectivity.

DETAILED DESCRIPTION

     Most software Virtual Private Network (VPN) clients only allow a single VPN connection to be initiated at any ones time. Cisco's AnyConnect® VPN software is an example.

    If more than one VPN connection exists on a device there is a requirement that a routing protocol (or similar function) be employed to route traffic across each VPN depending on destination. If a VPN client has multiple VPN Headends configured, it is common for only a single Internet Key Exchange (IKEv2) Security Association (SA) to be initiated at any one time, and the client will attempt to connect to each Headend sequentially until it successfully makes a connection.

    Various reasons could arise why some Headends will be available and some not, such as possible problems with the Headend itself, routing issues on the network between the host and Headend, or firewalls or access control only allowing traffic to certain geographical Headends.

    The IKEv2 protocol (RFC7296) states that retransmission timers MUST increase: To be a good network citizen, retransmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse.

Copyright 2015 Cisco Systems, Inc.

1


Page 02 of 6

    Reference is made to FIG. 1 for an example situation. If a client has 4 Headends configured, such as Headend 1, Headend 2, Headend 3, and Headend 4, and each are attempted sequentially with a 30 sec timeout and only Headend 3 and Headend 4 are available, it will take approximately 60 seconds before an attempt is initiated to Headend
3. Connections to Headends 1 & 2 will timeout.

FIG. 1

    For hardware clients (such as FlexVPN™ Client), which allow for multiple Headends to be configured, but only one to be active at any one time, a Service Level Agreement (SLA) can be used to track connectivity to the Headend (for example using Internet Control Message Protocol (ICMP) echo). However this only ascertains if there is Internet Protocol (IP) connectivity between endpoints and not that the IKE service is functioning on the Headend or that there connectivity using the ports used by IKE.

    IKEv2 requires cryptographic processing when creating the initial handshake (using, for example, Diffie Hellman public value construction/checks). This uses memory and processing power. For this reason most clients will only initiate a VPN session if

Copyright 2015 Cisco Systems, Inc.

2


Page 03 of 6

they are going to connect to the Headend. This could cause a self-inflicted Denial of Service by sending many IKEv2 packets, which is well documented within the IETF.

    If a devic...