"Introduction IP Security (IPsec) provides confidentiality@ data integrity@ access control@ and data source authentication to IP datagrams. These services are provided by maintaining shared state between the source and the sink of an IP datagram. This state defines@ among other things@ the specific services provided to the datagram@ which cryptographic algorithms will be used to provide the services@ and the keys used as input to the cryptographic algorithms. Establishing this shared state in a manual fashion does not scale well. Therefore@ a protocol to establish this state dynamically is needed. This document describes such a protocol -- the Internet Key Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI]@ 2408 [ISAKMP]@ and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] (RFC 4718). This document replaces and updates RFC 4306 and RFC 4718. IKEv2 was a change to the IKE protocol that was not backward compatible. In contrast@ the current document not only provides a clarification of IKEv2@ but makes minimum changes to the IKE protocol. A list of the significant differences between RFC 4306 and this document is given in Section 1.7. IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) [ESP] or Authentication Header (AH) [AH] and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry. In this document@ the term ""suite"" or ""cryptographic suite"" refers to a complete set of algorithms used to protect an SA. An initiator proposes one or more suites by listing supported algorithms that can be combined into suites in a mix-and-match fashion. IKE can also negotiate use of IP Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. The SAs for ESP or AH that get set up through that IKE SA we call ""Child SAs"". All IKE communications consist of pairs of messages: a request and a response. The pair is called an ""exchange""@ and is sometimes called a ""request esponse pair"". The first exchange of messages establishing an IKE SA are called the IKE_SA_INIT and IKE_AUTH exchanges; subsequent IKE exchanges are called the CREATE_CHILD_SA or INFORMATIONAL exchanges. In the common case@ there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE SA and the first Child SA. In exceptional cases@ there may be more than one of each of these exchanges. In all cases@ all IKE_SA_INIT exchanges MUST complete before any other exchange type@ then all IKE_AUTH exchanges MUST complete@ and following that@ any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. In some scenarios@ only a single Child SA is needed between the IPsec endpoints@ and therefore there would be no additional exchanges. Subsequent exchanges MAY be used to establish additional Child SAs between the same authenticated pair of endpoints and to perform housekeeping functions."
RFC 5996-2010 history
2010RFC 5996-2010 Internet Key Exchange Protocol Version 2 (IKEv2) (Obsoletes: 4306@ 4718)