{"draft":"draft-ietf-ipsecme-ikev2-resumption-09","doc_id":"RFC5723","title":"Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption","authors":["Y. Sheffer","H. Tschofenig"],"format":["ASCII","HTML"],"page_count":"26","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"IP Security Maintenance and Extensions","abstract":"The Internet Key Exchange version 2 (IKEv2) protocol has a certain\r\ncomputational and communication overhead with respect to the number\r\nof round trips required and the cryptographic operations involved.\r\nIn remote access situations, the Extensible Authentication Protocol\r\n(EAP) is used for authentication, which adds several more round trips\r\nand consequently latency.\r\n\r\nTo re-establish security associations (SAs) upon a failure recovery\r\ncondition is time consuming especially when an IPsec peer (such as a\r\nVPN gateway) needs to re-establish a large number of SAs with various\r\nendpoints.  A high number of concurrent sessions might cause\r\nadditional problems for an IPsec peer during SA re-establishment.\r\n\r\nIn order to avoid the need to re-run the key exchange protocol from\r\nscratch, it would be useful to provide an efficient way to resume an\r\nIKE\/IPsec session.  This document proposes an extension to IKEv2 that\r\nallows a client to re-establish an IKE SA with a gateway in a highly\r\nefficient manner, utilizing a previously established IKE SA.\r\n\r\nA client can reconnect to a gateway from which it was disconnected.\r\nThe proposed approach encodes partial IKE state into an opaque ticket,\r\nwhich can be stored on the client or in a centralized store, and is\r\nlater made available to the IKEv2 responder for re-authentication.  We\r\nuse the term ticket to refer to the opaque data that is created by the\r\nIKEv2 responder.  This document does not specify the format of the\r\nticket but examples are provided.  [STANDARDS-TRACK]","pub_date":"January 2010","keywords":["[--------]","IKE","Internet Key Exchange","session resumption","failover","high availability","cryptographic ticket","cryptographic token","stateful resumption","stateless resumption"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5723","errata_url":null}