[IPsec] Resuming the session resumption discussion

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 07 October 2008 17:42 UTC

Return-Path: <ipsec-bounces@ietf.org>
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353A03A6856; Tue, 7 Oct 2008 10:42:48 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CC03A6856 for <ipsec@core3.amsl.com>; Tue, 7 Oct 2008 10:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Level:
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa2kdgIXdfMq for <ipsec@core3.amsl.com>; Tue, 7 Oct 2008 10:42:45 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BE1E53A67F7 for <ipsec@ietf.org>; Tue, 7 Oct 2008 10:42:44 -0700 (PDT)
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97HhIEQ097751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Tue, 7 Oct 2008 10:43:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p062408aec5114d1e42dd@[10.20.30.152]>
In-Reply-To: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com>
References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com>
Date: Tue, 07 Oct 2008 10:43:15 -0700
To: ipsec@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: [IPsec] Resuming the session resumption discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

<co-chair hat on>

We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below.

The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says.

Extra points are awarded for not copying this entire message in your response. :-)

--Paul Hoffman

==========

- A standards-track extension that allows an IPsec remote access client
to "resume" a session with a gateway; that is, to skip certain parts of
IKE negotiation when connecting again to the same gateway (or possibly a
cluster of closely cooperating gateways). The idea is similar to TLS
session resumption without server-side state, specified in RFC 5077.

The main goals for this extension are to avoid public-key computations
(to reduce VPN gateway load when a large number of clients reconnect to
the gateway within a short period of time, such as following a network
outage), and remove the need for user interaction for authentication
(which may be required by some authentication mechanisms). The extension
shall not have negative impact on IKEv2 security features.

Failover from one gateway to another, mechanisms for detecting when a
session should be resumed, and specifying communication mechanisms
between gateways are beyond the scope of this work item. Specifying the
detailed contents of the "session ticket" is also beyond the scope of
this document; if there is sufficient interest, this could be specified
later in a separate document.

To the degree its content falls within the scope of this work item, text
and ideas from draft-sheffer-ipsec-failover will be used as a starting
point.

==========

At 9:17 PM +0800 10/7/08, Peny Yang wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title           : IKEv2 SA Synchronization for session resumption
>	Author(s)       : Y. Xu, et al.
>	Filename        : draft-xu-ike-sa-sync-01.txt
>	Pages           : 18
>	Date            : 2008-10-07
>
>It will take a long time and mass computation to do session
>resumption among IKE/IPsec gateways possibly maintaining huge numbers
>of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded.
>The major reason is that the prcocedure of IKEv2 SA re-establishment
>will incur a time-consuming computation especially in the Diffie-
>Hellman exchange.  In this draft, a new IKE security associations
>synchronization solution is proposed to do fast IKE SA session
>resumption by directly transferring the indexed IKE SA (named stub)
>from old gateway to new gateway, wherein the most expensive Diffie-
>Hellman calculation can be avoided.  Without some time-consuming
>IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption
>procedures can be finished in a short time.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-01.txt
>

At 10:09 AM -0700 10/7/08, Lakshminath Dondeti wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title           : IKEv2 Session Resumption
>	Author(s)       : Y. Sheffer, et al.
>	Filename        : draft-tschofenig-ipsecme-ikev2-resumption-00.txt
>	Pages           : 19
>	Date            : 2008-10-01
>
>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 (SA) 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
>end points.  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 uses a ticket to store state information that
>is later made available to the IKEv2 responder for re-authentication.
>Restoring state information by utilizing a ticket, although the
>format is not specified in this document, is one possible way.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-tschofenig-ipsecme-ikev2-resumption-00.txt

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec