1.3 Overview

Internet Key Exchange (IKE) Protocol Extensions (IKEE) apply to the IKE Protocol versions 1 and 2, as specified in [RFC2407], [RFC2408], [RFC2409], [RFC3947], and [RFC4306]. These extensions provide additional capabilities to IKE, including interoperation between different revisions of the network address translation traversal (NAT-Traversal or NAT-T) specification, fragmentation of large IKE version 1 messages, authentication by using cryptographically generated addresses (CGAs), fast failover when communicating with a cluster of hosts, easier interoperation with non-Internet Protocol security (IPsec)–capable peers, acknowledgment of security association (SA) deletion messages, denial of service protection, IKE security association correlation (IKEv2), and IKE server internal addresses configuration attributes (IKEv2).

The IKE protocol version 1 (IKEv1) is specified in [RFC2409] and is closely tied to [RFC2407] and [RFC2408]. IKE is clearly the most commonly implemented protocol that uses these RFCs. IKE version 1 is used to negotiate security associations (SAs), as specified in [RFC2409], for the purpose of keying authentication header (AH) and Encapsulating Security Payload (ESP) packet transformations. For more information, see [RFC4302] and [RFC4303]. For the general security architecture of IPsec, see [RFC4301].

IKE protocol version 2 (IKEv2) is specified by [RFC4306]. Industry practice supports use of the term IKE to collectively refer to [RFC2407], [RFC2408], [RFC2409], and more recently, [RFC4306].

In the remainder of this document, the term IKE collectively applies to [RFC2407], [RFC2408], [RFC2409], and [RFC4306]. Where applicable, the appropriate section of each RFC is referenced in the document.<1>

This document specifies the extensions to IKE. Each of these IKE extensions is independent and can be implemented in isolation. There is no sequencing between the individual extensions. An implementation of this protocol can support any combination of these IKE extensions.<2>