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

From: "Zhen Cao" <[email-masked]>
Date: Thu, 9 Oct 2008 18:14:03 +0800

Dear All,

I have a quick review of these two drafts. Basically, both drafts need
to transfer ticket/stub to gateway from somewhere during session
resumption. In ticket draft, the ticket need to be presented to client
before hand and delivered to gateway in the IKE_SESSION_RESUME message
in session resumption. In the stub draft, the stub need to be
transfered between gateway and stub bank.

My point is that the worth of bandwidth are different for different
ways of transferring. When we transfer the stub between gateways, we
use fiber. If we transfer the ticket to the client, we may even need
to use the luxurious wireless spectrum in the mobile network. And, the
ticket will expire. If the session resumption does not happen for a
long time in the mobile network, the updated tickets will be sent over
the air continuously to the client. In this case, the continuous cost
of ticket presenting will be taken by operator or subscribers in vain.

In this case, I think stub solution should be a mandatory, ticket
maybe optional.

Thanks
Zhen

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Oct 2008 10:12:05 -0400

At 6:14 PM +0800 10/9/08, Zhen Cao wrote:
>...

In the immediately preceding message, from, Sean Shen, he says:

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

In two messages that arrived in my mailbox less than an hour apart, 
we have two radically different views of whether a ticket is big or 
small.  If we can't agree on the size of this data, perhaps because 
they are vendor-specific in detail, then we ought not make decisions 
on mandating the stub vs. the ticket model on this basis.

Steve