On Thu, 27 Aug 2020, Michael Richardson wrote:
Paul Wouters <p...@nohats.ca> wrote:
> Or update the RFC with a clarification that delete's are allowed, but
> that the server who deleted a state, upon getting a ticket MUST check:
> - It's configuration is unchanged from when the ticket was issued (we do
that)
> - The ticket's issue time plus the configuration's lifetime is not in
> the past
> - The IKE SA should not have been rekeyed [tricky without keeping
> state]
If the ticket was issued at time A (which is in the ticket), and the IKE SA
rekey time is intervals of time B, then had the SA been active alive at time
A+B, it would have been rekeyed, right?
So, if the current time is > A+B, then the IKE SA should have been rekeyed?
Yes, so that part is not the problem.
But, you alude to it requiring state, so there must be something I don't
understand.
We added a suspend commend, but since that deleted states on the
initiator, it ended up sending delete's to the server. The server
deleted the IKE SAs. Now the client can resume a connection that
technically was ended by Delete.
This is similar to the client not sending deletes, and the server
triggering its own deletes based on liveness - the client isn't going to
respond to liveness probes while suspended.
If the client comes back with a valid ticket within the valid expiry
time, the server does not know if A) the IKE SA was already deleted
and the ticket theoretically should no longer be valid or B) the server
deleted the IKE SA due to liveness timeouts and the client comes back
with tickets to resume this.
>> The case of a cluster of gateways is not handled by the RFC. This is
>> alluded to at the end of the Introduction.
> that was an unfortunate easy way to not address the problem of syncing
> state between servers :)
Can you explain what the problem is if the ticket is used more than once
(with different gateways) within the time B?
So this indeed is the important question for all of these cases. What is
the harm? Because why does the RFC state that deleted IKE SAs should not
be resumed?
We are re-using an SK_d, but does that influence the amount of crypto
done under an IKE SA (FIPS issue)? The livetimes would already be
covered by the above - just don't let the ticket be valid for longer
than the creation time plus rekey time.
It would be really nice if we can keep the server side to need to
require zero state. If we ignore those two issues mentioned, we can
do that.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
