Greetings All, Please note that we are resending this RFC announcement because were notified that it did not appear in the ietf-announce archives. Please note that the date of publication is January 2010. Please let us know if you have any questions. Thank you. RFC Editor/sg On Thu, Jan 07, 2010 at 04:52:40PM -0800, RFC Editor wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5723 > > Title: Internet Key Exchange Protocol Version > 2 (IKEv2) Session Resumption > Author: Y. Sheffer, H. Tschofenig > Status: Standards Track > Date: January 2010 > Mailbox: yaronf@checkpoint.com, > Hannes.Tschofenig@gmx.net > Pages: 26 > Characters: 59201 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipsecme-ikev2-resumption-09.txt > > URL: http://www.rfc-editor.org/rfc/rfc5723.txt > > 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] > > This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
