Subject: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway)

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 24 Jan 2009 17:29:08 +0200

Hi all, 
Hi Tero, 

I would like to close issue #70: 
http://tools.ietf.org/wg/ipsecme/trac/ticket/70

Here is a copy-and-paste from the page: 
"
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? 
"

There are obviously design choices one can make about the way how the
ticket lifecycle looks like. The authors thought it would make sense to
give the client a clue how long the ticket would be valid. 

Instead of letting the client know one could also generate an error
message as you indicated. 

One way is as good as the other one. When we change it in the way
someone else will come along and argue that it should be done similar to
RFC 5077 or to the way Kerberos does it. Subsequently, someone will come
along to tell us that RFC 4962 says that authorization decisions
(including the lifetime) should be synchronized between all involved
parties. Etc. etc. 

I don't believe that the argument regarding changing the encryption
algorithm is super realistic as the lifetime of the ticket is in the
order of hours and not weeks or months where switching of algorithm
makes sense. 

In short, one can always make other design choices and in most cases
there is very little difference between the various mechanisms. 

Regarding "o Allowing a gateway to push state to clients.": I meant this
a bit differently. The ticket per value is a way for the gateway to push
state information to the client. In fact it does so without server-side
state. 
 
I added a sentence regarding the lifetime field of the N(TICKET_OPAQUE)
payload. The value of the Lifetime field in the TICKET_OPAQUE payload is
set to the value that was received when requesting the ticket.

Is this OK for you? 

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Jan 2009 12:46:48 -0800

>give the client a clue how long the ticket would be valid.

Then you should say why that clue is useful in the document. Given what is currently in the document, I would agree with Tero: it is violating the design principle of IKEv2 to get rid of lifetimes.

>One way is as good as the other one.

Without more justification, I would disagree. The current document requires the client to track the lifetime and pre-emptively get a new ticket when it is "about to expire" and so on. At least to me, that seems like more overhead for both parties than requiring them to keep watching the clock and acting when the countdown gets close.

>When we change it in the way

Sure, but you still have to justify your choice, not just say "seems good".

>order of hours and not weeks or months where switching of algorithm

The issue is changing the encryption *key*, not the algorithm. I can see definite reasons to change a key periodically, particularly in systems that stay up for months (or hopefully years) at a time.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 25 Jan 2009 23:31:50 +0200

>>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?
>>
>>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).
>>
>Then you should say why that clue is useful in the document. 
>Given what is currently in the document, I would agree with 
>Tero: it is violating the design principle of IKEv2 to get rid 
>of lifetimes.
>
>Without more justification, I would disagree. The current 
>document requires the client to track the lifetime and 
>pre-emptively get a new ticket when it is "about to expire" 
>and so on. At least to me, that seems like more overhead for 
>both parties than requiring them to keep watching the clock 
>and acting when the countdown gets close.
>
>>someone else will come along and argue that it should be done similar 
>>to RFC 5077 or to the way Kerberos does it. Subsequently, 
>someone will 
>>come along to tell us that RFC 4962 says that authorization decisions 

The client would know how long the ticket is valid. It can therefore
easily make an informed decision of when one of the tickets became
invalid rather than probing the server. 

RFC 5077 follows a similar approach in the sense that the lifetime is
communicated as a hint. 

>The issue is changing the encryption *key*, not the algorithm. 
>I can see definite reasons to change a key periodically, 
>particularly in systems that stay up for months (or hopefully 
>years) at a time.

But the VPN gateway will be able to change the key that is used to
protect the ticket anyway. This is pretty much independent of the
mechanism of how the client presents the ticket to the VPN gateway.
There will be a period where the two or more keys will be active as the
VPN gatewy starts handing out tickets protected with the new key whereas
some tickets are still with some clients utlizing the old key. 

Am I missing the point here a bit? 

Ciao
Hannes

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Jan 2009 13:47:06 -0800

>RFC 5077 follows a similar approach in the sense that the lifetime is

True. Are you saying that you consider the lifetime in draft-ietf-ipsecme-ikev2-resumption to be a hint, not a hard expiry? I did not get that impression from the draft.

>Am I missing the point here a bit?

Possibly. My point (and I think Tero's point) is that having the two sides need to keep watching the time is possibly more fragile than periodic rechecks. On the other hand, if you are now saying that the lifetime is a hint and not definitive, then the two sides don't really need to keep track that closely.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 26 Jan 2009 15:37:19 +0200

It seems to me we are splitting hairs here: what is the different between "hard expiry" and a hint? The protocol as it is today can handle the case when the gateway doesn't like the ticket it receives. And any reasonable client implementation will never send a stale ticket, regardless if this is "expiry" or a "hint". So the behavior is really the same.

If we go for periodic checks, who decides what is a reasonable period? I think one periodic keep-alive per protocol (DPD) is sufficient. And why is it easier to maintain a periodic timer than a timer preset to the value received in the ticket?

Thanks,
        Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Sunday, January 25, 2009 23:47
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Cc: [email-masked]
> Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and
> ticket push from gateway)
>
> True. Are you saying that you consider the lifetime in draft-ietf-ipsecme-
> ikev2-resumption to be a hint, not a hard expiry? I did not get that
> impression from the draft.
>
> Possibly. My point (and I think Tero's point) is that having the two sides
> need to keep watching the time is possibly more fragile than periodic
> rechecks. On the other hand, if you are now saying that the lifetime is a
> hint and not definitive, then the two sides don't really need to keep
> track that closely.
>
> --Paul Hoffman, Director
> --VPN Consortium
> Scanned by Check Point Total Security Gateway.
>
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2009 16:12:54 +0200

Paul Hoffman writes:
> True. Are you saying that you consider the lifetime in
> draft-ietf-ipsecme-ikev2-resumption to be a hint, not a hard expiry?
> I did not get that impression from the draft.

Same here, and I still do not understand why client would be sending
the lifetime to the server when it is presenting the ticket. That does
not make any sense as lifetime isn't expressed as absolute time.

Also what does server does if the lifetime client gives when it
presents ticket is different than what was sent before. Is that fatal
error? Is that silently ignored? 

> Possibly. My point (and I think Tero's point) is that having the two
> sides need to keep watching the time is possibly more fragile than
> periodic rechecks. On the other hand, if you are now saying that the
> lifetime is a hint and not definitive, then the two sides don't
> really need to keep track that closely. 

Another problem with lifetimes is that they do have explicit policy
limits, meaning they will cause negotiations to fail. This happened a
lot in the IKEv1 environment, and in the end it was always mandatory
to make sure that both client and server used EXACTLY same lifetimes,
as otherwise you most likely didn't interop.

This will mean that if client is configured for minimal lifetime of
ticket of 3600 seconds, and server offers ticket which have lifetime
of 3599 seconds, client will fail the negotiation. On the other hand
if we say that there MUST NOT be any policy limitation checks for the
lifetimes, then there is no point of tell them really, as server can
simply start new INFORMATIONAL exchange and send new N(TICKET_OPAQUE)
when the previous one is about to expire.

In general I do not really see that much need for expiring tickets
ever as long as the IKE SA associated to it exists. The expiry only
comes to the play when the IKE SA is removed, and should really be
counted from that point forward. That of course offers a problem that
there is no agreed upon time when the connection between server and
client was lost.

I.e. if we have IKE SA which is set up at and has been active for 5
days. There is no point of setting the ticket lifetime to something
like 1 hour or so and get new tickets every hour during that 5 days.
On the other hand when the IKE SA connection is broken, then it would
be useful to start timer on the server. If it was just network problem
then connection will come back quite quickly, thus 1 hour ticket
lifetime is understandable. If client hasn't resumpted the connection
during that 1 hour timeframe, then it either crashed, or someone
digged up the network cable, and the situation will take so long to
get fixed, that new IKE SA negotiation does not matter.

If we mandate lifetime upkeeping to the protocol that will cause extra
adminstrative work all the time, as both ends needs to keep track of
lifetimes, and request new tickets (or just send them if needed). If
the lifetimes are left to the local policy then server can do whatever
it likes, and client always tries to resumption first if he has ticket
(client usually only have very few tickets, so it really does not need
to delete them to gain more resources).

It seems I completely misunderstood the "Allowing a gateway to push
state to clients." text. I read it as so that gateway can initiate
ticket pushing operations, i.e. it can do following:

   Client                        Gateway
   -------                       ----------
                                 <-- HDR, SK {N(TICKET_OPAQUE)}
   HDR, SK {} -->

I.e. the server can at any time push new ticket to the client, and
client will replace previous ticket with this new one. Most likely
server will always need to push new ticket every time IKE SA is
rekeyed, as the keying material used to calculate the SK_d2, SK_ai,
SK_ar, SK_ei, SK_er changes when SK_d changes, and rekeying IKE SA
changes SK_d. On the other hand the draft does not say which SK_d is
used after rekey. If you do rekey so you can forget the keying
material used before the rekey, it would not be good to keep the old
SK_d still after rekey, so I assume the SK_d should come from the
current IKE SA, i.e. it is recreated after each rekey.  
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Jan 2009 16:41:09 +0200

Hi Tero, 

>Same here, and I still do not understand why client would be 
>sending the lifetime to the server when it is presenting the 
>ticket. That does not make any sense as lifetime isn't 
>expressed as absolute time.

We reused the same payload format for both directions. I added text that
the lifetime in the C->S direction is set to the lifetime previously
received. 

Alternatively, I could also introduce an additional payload format and
exclude the lifetime. 

Do you prefer the latter? 

>
>Also what does server does if the lifetime client gives when 
>it presents ticket is different than what was sent before. Is 
>that fatal error? Is that silently ignored? 

The draft says: 
"
   The four
   octet lifetime field contains the number of seconds until the ticket
   expires (encoded as an unsigned integer).
"

>> lifetime is a hint and not definitive, then the two sides 
>don't really 
>> need to keep track that closely.
>
>Another problem with lifetimes is that they do have explicit 
>policy limits, meaning they will cause negotiations to fail. 
>This happened a lot in the IKEv1 environment, and in the end 
>it was always mandatory to make sure that both client and 
>server used EXACTLY same lifetimes, as otherwise you most 
>likely didn't interop.

Not an issue here as absolute time isn't used. 

>
>This will mean that if client is configured for minimal 
>lifetime of ticket of 3600 seconds, and server offers ticket 
>which have lifetime of 3599 seconds, client will fail the 
>negotiation. On the other hand if we say that there MUST NOT 
>be any policy limitation checks for the lifetimes, then there 
>is no point of tell them really, as server can simply start 
>new INFORMATIONAL exchange and send new N(TICKET_OPAQUE) when 
>the previous one is about to expire.

We can certainly add text to the draft discussing such a case. 
If the client is not happy with what it gets then it can always start a
full exchange. I don't see a problem with that. This is also a policy
issue. In this specific case this is appropriate for the client todo. 

Sending a new message from the server to the client when the ticket is
to expire is also possible and supported by the document. I do, however,
agree that more text could/should be added. 

>In general I do not really see that much need for expiring 
>tickets ever as long as the IKE SA associated to it exists. 
>The expiry only comes to the play when the IKE SA is removed, 
>and should really be counted from that point forward. That of 
>course offers a problem that there is no agreed upon time when 
>the connection between server and client was lost.
>
>I.e. if we have IKE SA which is set up at and has been active 
>for 5 days. There is no point of setting the ticket lifetime 
>to something like 1 hour or so and get new tickets every hour 
>during that 5 days.
>On the other hand when the IKE SA connection is broken, then 
>it would be useful to start timer on the server. If it was 
>just network problem then connection will come back quite 
>quickly, thus 1 hour ticket lifetime is understandable. If 
>client hasn't resumpted the connection during that 1 hour 
>timeframe, then it either crashed, or someone digged up the 
>network cable, and the situation will take so long to get 
>fixed, that new IKE SA negotiation does not matter.

It would be good to always sent the client the ticket right before the
connectivity fades away :-)

Having tickets with a very short lifetime is probably not such a good
idea. 

>
>If we mandate lifetime upkeeping to the protocol that will 
>cause extra adminstrative work all the time, as both ends 
>needs to keep track of lifetimes, and request new tickets (or 
>just send them if needed). If the lifetimes are left to the 
>local policy then server can do whatever it likes, and client 
>always tries to resumption first if he has ticket (client 
>usually only have very few tickets, so it really does not need 
>It seems I completely misunderstood the "Allowing a gateway to 
>push state to clients." text. I read it as so that gateway can 
>initiate ticket pushing operations, i.e. it can do following:
>
>   Client                        Gateway
>   -------                       ----------
>I.e. the server can at any time push new ticket to the client, 
>and client will replace previous ticket with this new one. 
>Most likely server will always need to push new ticket every 
>time IKE SA is rekeyed, as the keying material used to 
>calculate the SK_d2, SK_ai, SK_ar, SK_ei, SK_er changes when 
>SK_d changes, and rekeying IKE SA changes SK_d.

The document does say that the ticket may be exchanged using an
informational exchange but the specific requirement you mention is in my
view not related to this aspect. 

Btw, I don't think requirements in a solution document are particularly
useful. 

>On the other 
>hand the draft does not say which SK_d is used after rekey. If 
>you do rekey so you can forget the keying material used before 
>the rekey, it would not be good to keep the old SK_d still 
>after rekey, so I assume the SK_d should come from the current 
>IKE SA, i.e. it is recreated after each rekey.  

Making a new ticket available to the client after rekeying sounds useful
to me. 
 
Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Jan 2009 16:49:09 +0200

I believe that the "hard expiry" vs. the hint comes from RFC 5077. 
There the text says from Section 5.6 of RFC 5077:

"
5.6.  Ticket Lifetime

   The TLS server controls the lifetime of the ticket.  Servers
   determine the acceptable lifetime based on the operational and
   security requirements of the environments in which they are deployed.
   The ticket lifetime may be longer than the 24-hour lifetime
   recommended in [RFC4346].  TLS clients may be given a hint of the
   lifetime of the ticket.  Since the lifetime of a ticket may be
   unspecified, a client has its own local policy that determines when
   it discards tickets.
"

The lifetime field in
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-
01.txt is mandatory and we don't indicate that it may be set to specific
value to indicate it is not further specified. 

So, Tero, Paul and group: What behavior would you prefer?  

Ciao
Hannes

>From: ext Yaron Sheffer [mailto:[email-masked]] 
>Sent: 26 January, 2009 15:37
>To: Paul Hoffman; Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
>Cc: [email-masked]
>Subject: RE: [IPsec] Ticket #70: Ticket lifetime - explicit or 
>not? (and ticket push from gateway)
>
>It seems to me we are splitting hairs here: what is the 
>different between "hard expiry" and a hint? The protocol as it 
>is today can handle the case when the gateway doesn't like the 
>ticket it receives. And any reasonable client implementation 
>will never send a stale ticket, regardless if this is "expiry" 
>or a "hint". So the behavior is really the same.
>
>If we go for periodic checks, who decides what is a reasonable 
>period? I think one periodic keep-alive per protocol (DPD) is 
>sufficient. And why is it easier to maintain a periodic timer 
>than a timer preset to the value received in the ticket?
>
>Thanks,
>        Yaron
>
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Paul Hoffman
>> Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? 
>> (and ticket push from gateway)
>>
>> draft-ietf-ipsecme- ikev2-resumption to be a hint, not a 
>hard expiry?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Jan 2009 10:56:34 -0800

>I believe that the "hard expiry" vs. the hint comes from RFC 5077.

...which is not part of this document.

>So, Tero, Paul and group: What behavior would you prefer? 

If you believe that that the lifetime really is advisory, say that explicitly in the document, and take it out of the negotiations where it can break interoperability.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Jan 2009 15:54:03 +0200

Yaron Sheffer writes:
> It seems to me we are splitting hairs here: what is the different
> between "hard expiry" and a hint? The protocol as it is today can
> handle the case when the gateway doesn't like the ticket it
> receives. And any reasonable client implementation will never send a
> stale ticket, regardless if this is "expiry" or a "hint". So the
> behavior is really the same. 

Hard expiry means that when it expires then client cannot use the
ticket anymore, which means it will most likely need to get new ticket
before this happens. I.e. client needs to have timer that will expire
before the ticket expires, and do INFORMATIONAL exchange with
N(TICKET_OPAQUE) and server replies to that with N(TICKET_OPAQUE).

This means that there is yet another thing we need to keep up and
running all the time we have IKE SA set up. So I do not want to have
protocol which does following:

     Initiator                Responder
     -----------              -----------
    HDR, SAi1, KEi, Ni  -->

                        <--    HDR, SAr1, KEr, Nr, [CERTREQ]

    HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
    AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)}     -->
            <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
                        TSr, N(TICKET_OPAQUE lifetime=600)
			[,N(TICKET_GATEWAY_LIST)]}
<wait for 600 seconds>
    HDR, SK {N(TICKET_REQUEST)}     -->
            <--    HDR, SK {N(TICKET_OPAQUE lifetime=600)
			[,N(TICKET_GATEWAY_LIST)]}
<wait for 600 seconds>
    HDR, SK {N(TICKET_REQUEST)}     -->
            <--    HDR, SK {N(TICKET_OPAQUE lifetime=600)
			[,N(TICKET_GATEWAY_LIST)]}
<wait for 600 seconds>
    HDR, SK {N(TICKET_REQUEST)}     -->
            <--    HDR, SK {N(TICKET_OPAQUE lifetime=600)
			[,N(TICKET_GATEWAY_LIST)]}
<wait for 600 seconds>
    HDR, SK {N(TICKET_REQUEST)}     -->
            <--    HDR, SK {N(TICKET_OPAQUE lifetime=600)
			[,N(TICKET_GATEWAY_LIST)]}
<repeat the same process for every 10 minutes as long as the IKE SA
    exists> 

I would much prefer following protocol:

     Initiator                Responder
     -----------              -----------
    HDR, SAi1, KEi, Ni  -->

                        <--    HDR, SAr1, KEr, Nr, [CERTREQ]

    HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
    AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)}     -->
            <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
                        TSr, N(TICKET_OPAQUE)
			[,N(TICKET_GATEWAY_LIST)]}

<time passes and server decides to do something that causes tickets to
be recreated, for example changes the encryption key that was used to
encrypt them.>

            <--    HDR, SK {N(TICKET_OPAQUE)
			[,N(TICKET_GATEWAY_LIST)]}
    HDR, SK {}     -->

I.e. during normal operations the tickets are just there. The client
stores the last ticket it has received from the gateway, and tries it
always if it has one when it needs to reconnect. If server does
something that will cause old tickets to expire it will send new ones.
This usually happens for example when the IKE SA is rekeyed or when
the encryption key used to encrypt the tickets is changed.

In this case there is no need for any lifetime parameters in the
tickets, or any periodic timers to get new ticket etc.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Jan 2009 16:18:37 +0200

> Do you prefer the latter? 

I would prefer to remove lifetime completely. I.e. keep the same
payload format for both uses, but do not include lifetime at all.

>    expires (encoded as an unsigned integer).

This does not tell anything whether client is allowed or not allowed
to mess around with the lifetime field of the ticket. It is clear that
if client modifies the ticket data the ticket will not work, but can
it for example send lifetime as zero when it is sending it to the
server at IKE_SESSON_RESUME. For example implementation which only
stores the ticket data, and sets timer to expire before the lifetime
expires (to get request ticket), might not need to store the original
lifetime value at all.

So I can see such implementation sending different values in the
lifetime field than what was originally sent. I can also see some
server implementations which might consider it an error if not same
value is not sent.

Thus if lifetimes are left in to the draft, then it either needs to
say that lifetime is ignored in the IKE_SESSON_RESUME when client
presents the ticket, or it needs to say that client must keep the same
value that was sent to it.

> Not an issue here as absolute time isn't used. 

I do not think absolute time has anything to do with this. In IKEv1
the lifetimes were presented in the same way as in your draft, and
there was lots of problems with them, i.e. other end rejecting the
exchange because the lifetime given in the exchange wasn't something
it was willing to accept.

> issue. In this specific case this is appropriate for the client todo. 

It can only do full exchange after the IKE SA has been deleted, but
for most of the time the IKE SA will still be there for long time.
I.e. when the IKE SA is first created and the ticket is given a 600
second lifetime, then during the 8 hours of working the ticket needs
to be requested again 48 times, and then when IKE SA goes away, then
10 minutes after that both server and client will know that ticket is
no longer valid. 

> Having tickets with a very short lifetime is probably not such a good

But for loaded server it might want to use short lifetime, just so
that it does not need to store too much data for too long time, for no
real benefit.

Lets take example of big www-server protected by IPsec using
resumption. The web server might have million users connecting to it
every day, and each user usually requests a page (and the images on
it) and then reads for it for 5 minutes, and then gets next page and
so on for 30 minutes or so and then comes again next day (lets say
this is some newpaper or similar).

For this usage the lifetime of the ticket on the server end would most
likely be short, around 30 min - 60 min, as if client is away for more
than an hour, then it usually means it comes back only next day. If
server uses tickets by reference, meaning that the server stores the
actual ticket data (0.5 kB each), then storing tickets for all million
users would require 488 MB of storage space.

Storing tickets for those 100 000 users that come every hour requires
48 MB. If the server only tries to recover for cases where user
connection is lost for less than 10 minutes (i.e. it expires tickets
10 minutes after last packet has been received from the user), then it
only needs to store 8 MB of tickets. 

Is the session resumption only meant for very long lived SAs or is it
also meant for this kind of short lived connections?
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 30 Jan 2009 16:50:49 +0200

Hi Tero, 

>> We reused the same payload format for both directions. I added text 
>> that the lifetime in the C->S direction is set to the lifetime 
>> previously received.
>> 
>I would prefer to remove lifetime completely. I.e. keep the 
>same payload format for both uses, but do not include lifetime at all.

Ok. 

>This does not tell anything whether client is allowed or not 
>allowed to mess around with the lifetime field of the ticket. 
>It is clear that if client modifies the ticket data the ticket 
>will not work, but can it for example send lifetime as zero 
>when it is sending it to the server at IKE_SESSON_RESUME. For 
>example implementation which only stores the ticket data, and 
>sets timer to expire before the lifetime expires (to get 
>request ticket), might not need to store the original lifetime 
>value at all.
>
>So I can see such implementation sending different values in 
>the lifetime field than what was originally sent. I can also 
>see some server implementations which might consider it an 
>error if not same value is not sent.
>
>Thus if lifetimes are left in to the draft, then it either 
>needs to say that lifetime is ignored in the IKE_SESSON_RESUME 
>when client presents the ticket, or it needs to say that 
>client must keep the same value that was sent to it.

I agree with you and Paul that this aspect needs to be clarified. 
My intention was that the client does not mess around with the value of the
lifetime field. 

>> >limits, meaning they will cause negotiations to fail.
>> >This happened a lot in the IKEv1 environment, and in the end it was 
>> >always mandatory to make sure that both client and server used 
>> >EXACTLY same lifetimes, as otherwise you most likely didn't interop.
>> 
>I do not think absolute time has anything to do with this. In 
>IKEv1 the lifetimes were presented in the same way as in your 
>draft, and there was lots of problems with them, i.e. other 
>end rejecting the exchange because the lifetime given in the 
>exchange wasn't something it was willing to accept.

I have asked Joe and Hao about their implementation experience with RFC
5077. They did not mention anything along these lines. Sure, there is less
experience with RFC 5077 than with IKEv1. I would, however, expect that an
entity rejects something if it does not comply with the local policy. 

>> If the client is not happy with what it gets then it can 
>always start 
>> a full exchange. I don't see a problem with that. This is also a 
>> policy issue. In this specific case this is appropriate for 
>the client todo.
>
>It can only do full exchange after the IKE SA has been 
>deleted, but for most of the time the IKE SA will still be 
>there for long time.
>I.e. when the IKE SA is first created and the ticket is given 
>a 600 second lifetime, then during the 8 hours of working the 
>ticket needs to be requested again 48 times, and then when IKE 
>SA goes away, then 10 minutes after that both server and 
>client will know that ticket is no longer valid. 
>
>But for loaded server it might want to use short lifetime, 
>just so that it does not need to store too much data for too 
>long time, for no real benefit.
>
>resumption. The web server might have million users connecting 
>to it every day, and each user usually requests a page (and 
>the images on
>it) and then reads for it for 5 minutes, and then gets next 
>page and so on for 30 minutes or so and then comes again next 
>day (lets say this is some newpaper or similar).
>
>For this usage the lifetime of the ticket on the server end 
>would most likely be short, around 30 min - 60 min, as if 
>client is away for more than an hour, then it usually means it 
>comes back only next day. If server uses tickets by reference, 
>meaning that the server stores the actual ticket data (0.5 kB 
>each), then storing tickets for all million users would 
>require 488 MB of storage space.
>
>48 MB. If the server only tries to recover for cases where 
>user connection is lost for less than 10 minutes (i.e. it 
>expires tickets 10 minutes after last packet has been received 
>from the user), then it only needs to store 8 MB of tickets. 
>
>Is the session resumption only meant for very long lived SAs 
>or is it also meant for this kind of short lived connections?
>--

I personally was thinking more of IPsec usage in a VPN gateway scenario
rather than IPsec/IKEv2 usage with a webserver for webbrowsing. 

Ciao
Hannes