On Fri, 28 Aug 2020, Michael Richardson wrote:
> 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.
It seems that either the client shouldn't send deletes, or:
But not sending a delete will just result in the server sending liveness
probes and deleting the client shortly after the client suspends
quietly. If you want IKE Resume to work in the real world with Liveness,
you basically have to ignore that the client and server delete the SA.
> 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 server should behave the same way regardless of who deleted the SA.
Then IKE Resume as an RFC can simply never work. No connection could
ever be resumed.
I think that maybe the intention was that IKE SAs deleted by the server due to
operator action should never be resumed. Because the user changed their
password, or their 2FA was compromised, or ...
That is all covered by the lifetime of the session ticket. The ike
lifetime timeout (or rather, the re-authentication timeout) should be
set and honoured - whether the connection is active or suspended. So
as long as the server doesn't issue ticket lifetimes beyond the re-auth
lifetime - everything is good.
Maybe the state-lite way is that the identity that involved in the deleted
state is marked as needing re-authentication.
That information is in the encrypted ticket by way of ticket lifetime.
No need for the server to keep state or state-lite.
> 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.
I agree.
Another approach is to add a notify to MOBIKE to tell the server to
disable liveness probes, allowing the client to go to sleep without
fear or losing the state on the server. It can then also sleep for
some time and come back up with an MOBIKE update message. It wouldn't
allow the server to delete the state but it does allow the client to
go to extended periods of sleep without fear of not being able to
continue with the existing Sa.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
