Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt lifetimes

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Nov 2008 00:19:13 +0200

What is the reason for sending the lifetime of the ticket along with
ticket? We have mostly tried to get rid of lifetimes visible on
protocol level on the IKEv2 and made all those local policy matters,
so why do we need externally visible lifetime for the ticket?

What purpose does it serve? Why does the client need to know the
ticket lifetime?

It would be much simplier if this was left as local matter, i.e.
client would always use the latest ticket is has, and every time if he
has ticket (i.e. the last IKE SA was NOT deleted, but was
interrupted), it would send that to the server (i.e. use the
IKE_SESSION_RESUME). If ticket is no longer valid in the server,
server will reply with N(TICKET_NACK) and client will restart with
full exchange. In most of the cases the resumption happens quite
quickly after the connection was interrupted, so most likely the
ticket is still valid.

Then for the server side when the ticket is about expire, it would
simply push new ticket to the client using informational message (this
is set as one of the requirements "o Allowing a gateway to push state
to clients.", but I do not see the actual description how to do it in
document).

This way server could use also non-time based policies for the ticket
lifetimes, i.e. it could for example decide to change the ticket
encryption key every now and then, and then slowly generate new
tickets for those sessions using old key, and when all sessions have
been sent new ticket, it can forget the old ticket encryption key.

Also what is the meaning of the lifetime field of the N(TICKET_OPAQUE)
in IKE_SESSION_RESUME? Does it need to be copied from the original
notification or what? 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec