Subject: [IPsec] Fw: I-D Action:draft-xu-ike-sa-sync-01.txt

From: "Peny Yang" <[email-masked]>
Date: Tue, 7 Oct 2008 21:17:09 +0800

Folks:

Sorry, I am afraid this poster should be fowarded instread for convenience.
Forget the one I posted just now. :)

Thanks a lot
BRG
- Peny

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-xu-ike-sa-sync-01.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 07 Oct 2008 10:09:49 -0700

FYI

-------- Original Message --------
Subject: I-D Action:draft-tschofenig-ipsecme-ikev2-resumption-00.txt
Date: Wed,  1 Oct 2008 08:45:10 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Oct 2008 10:43:15 -0700

<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.

==========

>http://www.ietf.org/internet-drafts/draft-tschofenig-ipsecme-ikev2-resumption-00.txt

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Oct 2008 01:20:42 +0200

On Oct 7, 2008, at 7:43 PM, Paul Hoffman wrote:

> <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.
>

 From a cursory read of both, the "stub" concept is very similar to  
the "ticket" concept. The difference is that the ticket is stored  
client-side, and therefore needs encryption, while the stub is stored  
server-side (or in some repository) and the security measures needed  
may or may not require encryption. draft-xu-ike-sa-sync also addresses  
failover due to overload, but that seems to me to be outside the scope  
of this work item.

I think we have three resumption scenarios:
- single gateway fails, and reboots
- a gateway fails, and a backup gateway with the same Identities,  
certificates and IP addresses takes over
- a gateway fails, and the client connects to a different gateway with  
another IP address. I'm not sure whether this scenario is even in scope.

Both proposals can handle all three cases. To implement the  
synchronization proposal, you need some kind of persistent storage,  
large enough to carry as many stubs as there are IKE SAs. This can be  
a local disk (synchronized between the gateways in case #2), an  
external storage module or database, or some other form of persistent  
storage. It also needs a process for transferring the stubs between  
gateways or between a gateway and the storage module. The resumption  
proposal does not need this extra piece of infrastructure and network  
traffic, which IMO gives it an edge.

In terms of bandwidth, the synchronization proposal has the edge,  
since the stub need not be transmitted to the client. The ticket  
shares the packet with traffic selectors, configuration payload,  
authentication, certificates and other payloads. That packet can be  
quite large, which leads to fragmentation and potentially packet loss.

The amount of work done is session resumption seems about similar, so  
there's nothing there to tell the proposals apart.

I think that on balance, the stub bank requirement is harder than the  
bandwidth requirements. I personally like session resumption better.

---

From: "Peny Yang" <[email-masked]>
Date: Wed, 8 Oct 2008 20:00:40 +0800

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

Hi, Paul:

Thanks a lot for your consideration.

Firstly, to make this discussion more smooth, may I propose to clarify
the terminology in this discussion beforehand. How about calling these
two drafts with "ticket solution" and "stub solution". In emails
previously, it seems the word of "resumption solution" is used for the
ticket solution somewhere, which is a little confusing. IMHO, the stub
solution DOES do the session resumption as well. Is this suggestion
acceptable? Thanks.

I just compared the two solution: "ticket solution" and "Stub Solution".

These two solutions have the same protocol round trips if the session
resumption can be successfully finished.

However, if we could consider the case when the session resumption CAN
NOT be continued by the gateway, these two solutions are different in
protocol round trips. The stub solution adds the payload in the
IKE_INIT message. The gateway can choose the normal procedure by
sending the normal IKEv2 IKE_INIT response without any other round
trips. The ticket solution have 1 more round trips in this case to
deliver the ticket to gateway.

And, these messages may be sent over the air. If we also include the
ticket provision procedure from GW to client, in this case, the big
ticket packet will be transferred over the air at least *TWICE*, which
may even possibly make nothing help to the protocol in case of no
unsuccessful session resumption.

Lastly, the stub solution does not need to extend the base IKEv2
protocol with new messages. It re-use the IKE_INIT messages to do the
session resumption with good flexibility. From the view of protocol
implementation, it's easier.

Thanks again.

regards,
Peny

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 8 Oct 2008 17:14:00 -0700 (PDT)

Hello,

On Tue, October 7, 2008 10:43 am, Paul Hoffman wrote:
[snip]
> 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.

  I prefer the approach in draft-tschofenig-ipsecme-ikev2-resumption.
A "stub bank" is not very attractive to me and requiring one will impose
restrictions on solutions.

  The charter vaguely says, "The extension shall not have negative impact
(sic) on IKEv2 security features" so I'm happy to see the Security
Considerations of draft-tschofenig-ipsecme-ikev2-resumption touch on some
of the things that could impact IKEv2 security features. Of the two, I
think it's the more complete document and something of interest to the WG.

  regards,

  Dan.

---

From: Sean Shen <[email-masked]>
Date: Thu, 09 Oct 2008 17:17:41 +0800

Hi, 
I went through the draft-tschofenig draft and have't finished reading the
draft-xu draft. Right now I have a few comments on the first draft as
following , hopefully more questions on both coming soon, :)

Section 1:  "Using only symmetric cryptography to minimize CPU consumption."
Sean: A ticket is not huge and ticket generation can be out of the SA setup
precedure, it can be done at  "spare time". Why bother to specify it.

Section 1:  "Allowing a gateway to push state to clients."
Sean: The coverage of the "state" should be given.

Section 3:
Sean: This section gives two senarios, but which one does the "In this
scenario" refer to?

Section 3:
Sean:  I was confused by the 5th paragraph of section 3. But eventually I
guess that "remote network", "remote access gateway" below to oppsite sides
of an IPSec  connection, am I right?

Section 4.2:
  " Tickets are intended for one-time use: a client MUST NOT reuse a
   ticket, either with the same or with a different gateway.  A gateway
   SHOULD reject a reused ticket.
   However, a responder is not required to maintain the state for
   terminated sessions."
Sean: I did not see how a gateway know that a ticket is reused. 

Section 4.2:    HDR, Ni, N(TICKET_OPAQUE), [N+,]
Sean: what's the "N+"?

Section 4.2:  
"   o  When the responder receives a ticket for an IKE SA that is still
      active and if the responder accepts it, then the old SAs SHOULD be
      silently deleted without sending a DELETE informational exchange. "
Sean:  I want to know an example for such a senario. Why will a initiator
start a resume session when the current session is not terminated. Is it an
accident or an attack?

Regards,

Sean

---

From: <[email-masked]>
Date: Fri, 24 Oct 2008 12:01:59 +0300

<not wearing any hats>

Based on a quick look, draft-tschofenig-ipsecme-ikev2-resumption looks
like draft-sheffer-ipsec-failover minus the bits that went beyond the
scope of this work item (like failover), so it would seem to fit the
charter text "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" pretty well.

It's also similar to RFC 5077, also mentioned in the work item
description -- unlike draft-xu-ike-sa-sync, which is closer to
the original RFC 2246 session resumption than RFC 5077.

Best regards,
Pasi 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Paul Hoffman
> Sent: 07 October, 2008 20:43
> To: [email-masked]
> Subject: [IPsec] Resuming the session resumption discussion
> 
> <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.
> 
<snip>

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 24 Oct 2008 23:29:47 +0800

Hello, all

I guess most Guru here only had a quick look other than detail technology
analogy.
some also said that one is attractive, the other is not. other than
detail analysis here.

Based on my observation, it is quite clear that most technical comments
favoriate draft-xu-ike-sa-sync, and sevearl critical issues have been raised
for draft-tschofenig-ipsecme-ikev2-resumption.

draft-xu-ike-sa-sync doesn't know what is RFC 2246 origianlly, we guess
that the best solution is not based on who is more looks similar.

One more comment is that draft-tschofenig-ipsecme-ikev2-resumption has
removed failure over support, but name of draft and authors from failure
over still there.

Lastly speaking for our mobile operator, we are interested in
draft-xu-ike-sa-sync, we don't want send so many SAs information to the
terminal, and in the case of huge number of mobile subscriber experience,
the air interface consumption is also quite criticial.
and I have no idea that is there any other scale operator interesting in
draft-tschofenig-ipsecme-ikev2-resumption and really consider to deploy it.

Many thanks

-Hui

---

From: Yoav Nir <[email-masked]>
Date: Sat, 25 Oct 2008 15:59:18 +0200

Hello Hui

This is strange, because that is not the impression I got from the  
discussion here.

There were basically two issues raised about draft-tschofenig. One was  
that pushing state to the handset was less secure that storing it on  
your own server farm. I don't think the case for that was made. The  
other issue was that it adds content to a message that is already  
bloated, which may lead to fragmentation, which may lead to dropped  
connections in environments with either high packet loss or defective  
middleboxes. That, however, is an inherent problem of IKE, that may  
appear even without session resumption because of certificates and/or  
large traffic selectors and CFG payloads.

Draft-xu, on the other hand, requires new infrastructure (the stub  
bank) which was not required in IKE before that. I would be hesitant  
to add such a requirement. Adding a synchronization box may be  
acceptable to a mobile operator with a huge number of mobile  
subscribers, but it's not acceptable to an small- or medium-sized  
enterprise trying to run a remote access VPN.  What's more, I don't  
see why such an infrastructure cannot be used for synchronizing the  
entire IKE SA rather than a stub. That would make failover even  
easier, and potentially transparent to the handset (and then there's  
no need for any new standard at all). That synchronization is fairly  
easy when the failover servers and the stub bank are just a rack away  
in the server room.  It gets considerably harder when you want to have  
the different servers in different geographical locations, and maybe  
have two geographically-separated stub banks.  That infrastructure,  
along with the communication channels between all those servers,  
becomes terribly expensive, whereas storing each clients ticket on the  
client costs just a little memory on each handset.

I do not work in the mobile operator space, but it seems to me, that  
data traffic (whether voice, video or plain data) would far dominate  
signaling, and that signaling would far dominate IKE, so that adding  
0.5K-1K to IKE (that's just my estimate of the ticket size) should be  
negligible, so IMO draft-tschofenig wins.

Yoav

On Oct 24, 2008, at 5:29 PM, Hui Deng wrote:

> Hello, all
>
> I guess most Guru here only had a quick look other than detail  
> technology analogy.
> Based on my observation, it is quite clear that most technical  
> comments favoriate draft-xu-ike-sa-sync, and sevearl critical issues  
> have been raised for draft-tschofenig-ipsecme-ikev2-resumption.
>
> draft-xu-ike-sa-sync doesn't know what is RFC 2246 origianlly, we  
> guess that the best solution is not based on who is more looks  
> similar.
>
> One more comment is that draft-tschofenig-ipsecme-ikev2-resumption  
> has removed failure over support, but name of draft and authors from  
> failure over still there.
>
> Lastly speaking for our mobile operator, we are interested in draft- 
> xu-ike-sa-sync, we don't want send so many SAs information to the  
> terminal, and in the case of huge number of mobile subscriber  
> experience, the air interface consumption is also quite criticial.
> and I have no idea that is there any other scale operator  
> interesting in draft-tschofenig-ipsecme-ikev2-resumption and really  
> consider to deploy it.
>
> Many thanks
>
> -Hui

---

From: "Hui Deng" <[email-masked]>
Date: Sat, 25 Oct 2008 23:34:29 +0800

Hello, Yoav,

Thanks for the discussion, reply inline.
2008/10/25 Yoav Nir <[email-masked]>

> This is strange, because that is not the impression I got from the
==> Fine.

> that pushing state to the handset was less secure that storing it on your
> own server farm. I don't think the case for that was made.
>
==> Replicated sim card has been a critical issue for mobile communication,
this is the existed case that we can't igmore them.

>  The other issue was that it adds content to a message that is already
> middleboxes. That, however, is an inherent problem of IKE, that may appear
> even without session resumption because of certificates and/or large traffic
> selectors and CFG payloads.
>
==> Other cases listed here are not quite usual case, here we are discussing
the usual scenario. That need special configuration, and this configuration
may not always correct.

>  Draft-xu, on the other hand, requires new infrastructure (the stub bank)
> which was not required in IKE before that. I would be hesitant to add such a
> requirement. Adding a synchronization box may be acceptable to a mobile
> operator with a huge number of mobile subscribers, but it's not acceptable
> to an small- or medium-sized enterprise trying to run a remote access VPN.
>
==> If it is small or medium sized enterprise, I guess cluster based server
could work for them

>  What's more, I don't see why such an infrastructure cannot be used for
> synchronizing the entire IKE SA rather than a stub. That would make failover
> even easier, and potentially transparent to the handset (and then there's no
> need for any new standard at all).
>
==> but it cann't handle the geographically seperated solution, that will
change the server IP address.

>  That synchronization is fairly easy when the failover servers and the
> stub bank are just a rack away in the server room.  It gets considerably
> harder when you want to have the different servers in different geographical
> locations, and maybe have two geographically-separated stub banks.  That
> infrastructure, along with the communication channels between all those
> servers, becomes terribly expensive, whereas storing each clients ticket on
> the client costs just a little memory on each handset.
>
that infrastrucutre is cost deservable. and not that much.
but leave too many things to mobile make lots of technical potential issue,
it also need cost additional expenditure to guarantee several issues.

>  I do not work in the mobile operator space, but it seems to me, that data
> traffic (whether voice, video or plain data) would far dominate signaling,
> and that signaling would far dominate IKE, so that adding 0.5K-1K to IKE
> (that's just my estimate of the ticket size) should be negligible, so IMO
> draft-tschofenig wins.
>
to save air interface, Hokey has been targeting to save this, especially in
the special APN case. IKE fragmention will lead to more signalings, it
really air cost.

thanks again.

-Hui

  Yoav