On Thu, 27 Aug 2020, Yaron Sheffer wrote:
I would also be interested to know what people implemented, because what you're suggesting, while possibly "the right thing", is clearly counter to the RFC. Sec. 6.2 and Sec. 9.8 are rather clear that no matter who deleted the IKE SA, the ticket is revoked and must not be used, and in fact the gateway must keep some limited state to ensure it.
You are right that section 6.2 is clear, but it does not take into account the asynchronous nature of the client or server deleting the IKE SA and the other peer not getting that notify. So the phrase "no matter who deleted the IKE SA" is interesting. If a client "vanishes", it is expected that the server would cleanup state. Otherwise, the RFC would have just been about sending a notify to "freeze DPD/liveness probes" and leaving state dormant on both sides. It is inevitable that the server will either linger the state, or delete it. If deleting it should be interpreted as "no longer suitable for resume" than we are left with "lingering the state". At which point I guess we can accomplish the same with only MOBIKE, and we should move this RFC to Historic. What I liked about resume is that the client can legitimately "vanish" and cheaply restart without the server losing state or having to keep all states around for too long. Eg with MOBIKE you run the risk of the server removing state before the client re-surfaces and sends a MOBIKE UPDATE message, and the client has to go from scratch with a new DH. With resume, we avoid the DH and we can appear from a new location. And the ticket expiry within the ticket ensures the server won't start too old session tickets handed out.
So if you want to stay compliant with the RFC, IMHO you'd need a new notification for this "delete".
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]
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 :) Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
