Subject: Re: [IPsec] Resuming the session resumption discussion

From: 胡泊 <[email-masked]>
Date: Tue, 21 Oct 2008 21:53:54 +0800

Hello, Yoav,

Snip---

IKEv2 recommends short messages, but then goes on to include in the last IKE_AUTH packet the traffic selectors (which may include the entire protected networks), the configuration payload (which may also include the entire protected networks, but in a different format, certificates (which have no upper bound on size) and potentially even CRLs.  So that packet is already in danger of being too large, and adding a chunky payload like the ticket increases the likelihood of fragmentation.

As for the negative effects, there is obviously the problem of packet loss. In a high packet loss environment (wireless devices come to mind) if, say, 30% of packets get lost, 50% of 2-fragment packets will be lost, and 65% of 3-fragment packets. Also, as the IKEv2 document says, some operating systems will have a limit on assembly, as will some firewalls that reassemble fragments to inspect the packet in full.

In the early 2000's a lot of wireless access points, home routers, DSL modems and such were broken - they dropped all fragments, so any packet larger than the MTU was doomed to be dropped. Things were so bad, that my company had to invent a proprietary IKE-over-TCP just to get client connections working. This has vastly improved. Today most such equipment is working well, and fragments are passed through correctly. Operating systems in use today are also in better shape, and I can't think of any current version that won't handle UDP packets as large as the standards allow. Packet loss is still an issue, but for regular wired and wireless access, even most cellular, packet loss is reasonably low.

I admit that my experience may not be representative of all the world, but IMO some fragmentation is not as big a problem as it used to be.

Yoav

Snip--

sorry for my late reply, I am getting swamped with test recently,
I guess that your experience doesn't represent the huge world where doesn't use checkpoint product.
at least, I experienced too many fragment  configuration related issue based on my testing.
thanks for your explanation.

-Po 

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: 胡泊 <[email-masked]>
Date: Tue, 21 Oct 2008 21:55:00 +0800

Hello all

Based on the discuss in the mailing list, 
I don't like the potential Internet RFC has to been based on some propritary solution,
As far as my testing experience, most of product doesn't implement that part.
In that case, Stub based solution should be recommended other than ticket.

Thanks,

-Po

<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