Forward: RFC 5723 on Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption

[RFC Editor <[e-mail]>]

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:    [e-mail], 
>                     [e-mail]
>         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 [e-mail].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
>