Subject: Re: [IPsec] [ipsecme] #73: Ticket location: preferserver-side ticket

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Jan 2009 18:14:02 +0200

Hi Hui, 
 
I appreciate that you raise this issue. There are certainly different design
directions that can be taken and I understand why you propose the usage of
IKE_SA_INIT. I even believe that it was described in the former draft
versions. 

The reason for not going along that path was the fact that you you are very
unlikely going to observe this performance optimization by falling back to a
regular IKEv2 exchange.

The problem is just that this should not happen since you only provide the
ticket to someone that previously gave it to you. You also know how long the
ticket is considered to be valid. Hence, the "optimization" would only work
in extremely rare cases when something went wong. 

Let's see what the other folks think. 
 
Ciao
Hannes

Hannes,

	Thanks for pointing out one implementation example,
	let's not tightly coupled with simplicity and complexity.
	 
	What we would like to raise is that one possible advantage of our
proposed text has been missed is falling back to regular IKE session.
	 
	Thanks for the discussion.
	 
	-Hui 

	2009/1/21 Hannes Tschofenig <[email-masked]>

		Tero, Hui,

		>Hui Deng writes:
		>> 5.3 Location of ticket
		>> The full-bodied content of ticket could be stored on
client
		>or network side.
		>> If it's stored on client, it will be put in TbV. TbV
presenting and
		>> requesting can be found in section 4.  The way of TbV
encryption can
		>> be found in section 7.
		>> If it's stored in the network side, the operators shall
allocate the
		>> non-volatile memory space for gateways to store the
tickets
		>of all the
		>> clients. How to build the ticket storage is out of the
scope. This
		>> ticket storage must be reachable for IKEv2 gateway. The
reference of
		>> the ticket is defined in 5.4.
		>
		>I am not really sure, how much this kind of implementation
		>details is needed here. I think it would be better to just
let
		>this kind of details for the implementors to decide, not
try
		>to dictate something here.
		>
		>For example that text says that you cannot make
implementation
		>where the network crypto processors who normally take care
of
		>IKE SAs cannot offload unused IKE SAs to the slowpath
central
		>processor with much bigger RAM, as that RAM is not
non-volatile.
		>
		>I think it is much better to just let that kind of
		>implementation details to the implementors to decide, as
they
		>heavily depend on the scenario where the implementation is
aimed for.
		>
		>I think it is good to say things that mandate that tickets
by
		>value MUST be encrypted, as that affects security. And it
is
		>good to say that tickets by reference does not need to be
		>encrypted, as they do not contain any sensitive material
(i.e
		>all the sensitive material (i.e. crypto keys and so on) is
		>stored on the location pointed by the reference), but that
		>storage where that sensitive material is stored MUST be
		>protected so that only unauthorized access is not allowed.
		>

		I again have to agree with Tero. These are nice details but
go far too much
		into the implementation space.

		>> 2) Protocol of ticket presenting
		>> (a)
		>> Proposed text: section 4.2. after the third paragraph The
document
		>> supports two methods to present a ticket by client.
		>> o A new IKEv2 exchange type called IKE_SESSION_RESUME.
It's
		>defined in
		>> section 4.2.1 o A extension to generic IKEv2 IKE_SA_INIT
exchange.
		>> It's defined in section 4.2.2
		>
		>I do not think we want to add yet another complication to
the
		>IKE_SA_INIT by adding new extension for it. I think we
should
		>stick to the simple and understandable exchanges, meaning
lets
		>just use the separate IKE_SESSION_RESUME exchange. That
allow
		>modular building of new exchanges, and that offers simplier
		>implementations, meaning less bugs...
		>
		>We already had earlier discussion about this, but wanted to
		>just send my email telling that I am still against
modifying
		>IKE_SA_INIT exchange for session resumption, and want to
use
		>separate IKE_SESSION_RESUME exchange for it.

		I am not seeing any need to change the current approach
outlined in the
		document.
		
		At http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74 some
arguments were
		provided by Peng for re-using the IKE_SA_INIT exchange,
namely
		* simpler implementation
		* more efficient.
		
		As mentioned previously, Florian Tegeler has implemented the
session
		resumption code and  he did not find it complex to
implement. Sure, there is
		a learning curve to get into the specific IKEv2 code but it
is not a large
		enhance nor a large specification. For sure, the exact
amount of time it
		takes to implement this extension depends on the specific
implementation of
		IKEv2 and how easy it is to extend the code.
		
		I had a hard time to see the efficiency argument given that
you are
		presenting the ticket to a server that has previously
provided you that
		ticket.
		
		I am a bit reluctant to change the currently described
approach just for the
		fun of it.
		
		Ciao
		Hannes
		
		>--
		>[email-masked]
		
		>_______________________________________________
		>IPsec mailing list
		>[email-masked]
		>https://www.ietf.org/mailman/listinfo/ipsec
		>

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