Hi Paul and Nupur,
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.
So if you want to stay compliant with the RFC, IMHO you'd need a new
notification for this "delete".
The case of a cluster of gateways is not handled by the RFC. This is alluded to
at the end of the Introduction.
Thanks,
Yaron
On 8/27/20, 03:52, "IPsec on behalf of Paul Wouters" <ipsec-boun...@ietf.org
on behalf of p...@nohats.ca> wrote:
Hi,
We are working on implementing IKEv2 Session Resumption.
https://tools.ietf.org/html/rfc5723
We are only looking at ticket_by_value at this point.
It is unclear to me what is the behaviour related to Delete/Notify.
The RFC only takes into account situations where the connectivity is
lost and any delete/notify messages would no longer be received by
the responder. It states:
When the client wishes to recover from an interrupted session
But a client could use this mechanism when it wants to go to sleep and
tell the server this as well to avoid liveness probes. So the initiator
could send a delete, then come back later and use its ticket. This would
allow the responder to remove the state without waiting on liveness
timeouts to trigger cleanup of the vansihed client's state.
If the responder does not keep any state (which is the goal here) then it
would not know this session ticket belongs to an IKE SA that was deleted
by the initiator versus deleted by the responder's liveness/timeouts. The
RFC gives no guidance on this.
Similarly, if the responder keeps no state of the tickets it issued, it
would not be able to detect a ticket being used more than once without
the lifetime it set within the ticket itself.
When multiple gateways can read each others encrypted tickets, you could
also not prevent a ticket from being used more than once.
We are interested to know if any implementer bothered to track the issued
tickets and remove them from a list when received back (or timed out)
We are also interested to know if anyone prevents resuming a session
on the server side if the server has received delete/notifies for that
IKE SA.
Paul & Nupur
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
