RFC 5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
In plain English — editorial summary, not part of the RFC
The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS-TRACK]
Document record
- Document ID
- RFC5723
- Published
- January 2010
- Authors
- Y. Sheffer; H. Tschofenig
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 26
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6027IPsec Cluster Problem StatementCurrent
October 2010
- RFC 4430Kerberized Internet Negotiation of Keys (KINK)Current
March 2006
- RFC 4308Cryptographic Suites for IPsecCurrent
December 2005
- RFC 4307Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)Obsoleted
December 2005
- RFC 4304Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)Current
December 2005
- RFC 4303IP Encapsulating Security Payload (ESP)Current
December 2005
- RFC 4302IP Authentication HeaderCurrent
December 2005
- RFC 4301Security Architecture for the Internet ProtocolUpdated
December 2005
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?