Hi Paul & Nupur, > 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 don't (as for now). We implemented ticket_by_value, so server is stateless. > 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. We don't (as for now). We rely on client's honesty :-) This is probably wrong and needs to be fixed... Regards, Valery. > 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
