On Thu, 3 Sep 2020, Valery Smyslov wrote:
Current:A client can reconnect to a gateway from which it was disconnected. New: A client can reconnect to a gateway from which it was disconnected, due to a network issue between the client and server.I don't like this change - it's too narrow and only talks about network issue. The disconnection can also be a result switching off power on a CPE, or rebooting the device.
You are right.
Section 6.2: Current: Each ticket is associated with a single IKE SA. In particular, when an IKE SA is deleted by the client or the gateway, the client MUST delete its stored ticket. Similarly, when credentials associated with the IKE SA are invalidated (e.g., when a user logs out), the ticket MUST be deleted. New: Each ticket is associated with a single IKE SA. In particular, when an IKE SA is deleted by administrative actions initiated by the client or due to the client receiving a Delete Notification from the gateway, the client MUST delete its stored ticket. Similarly, when credentials associated with the IKE SA are invalidated (e.g., when a user logs out), the ticket MUST be deleted. When the client deletes the IKE SA due to a failed liveness probe, the clientThe following text:MUST NOT send Delete Notifications andis unnecessary and technically incorrect, because if there is no connectivity (as turned out after liveness probe failed), the client _cannot_ send any message to the server. Please, remove it.
There are cases where the client thinks it can send them, but it should not. Eg if it connected to a wifi AP that has no more uplink. If it sends the delete, and the connection would briefly allow packet flow, then the server would delete the state and invalidate any tickets. So I think it is important to clarify. And "cannot" is just a subset of "MUST NOT".
SHOULD keep the ticket to allow it to attempt a Session Resumption Exchange when the network outage has cleared. Section 9.8: Current: A misbehaving client could present a ticket in its possession to the gateway resulting in session resumption, even though the IKE SA associated with this ticket had previously been deleted. This is disallowed by Section 6.2. New: A misbehaving client could present a ticket in its possession to the gateway resulting in session resumption, even though the IKE SA associated with this ticket had been terminated by the client or server during regular operations that included processing Delete Notifications. This is disallowed by Section 6.2. Note that during an outage, deletion of the IKE SA that is the result of failed liveness probes MUST NOT invalidate the ticket for resumption, as this behaviour is expected to occur during a network outage.Again, the network outage is not the only reason for deleting SAs - switching off power or rebooting the device can also occur.
How about: s/outage/interruption of service/ or: (planned or unplanned) interruption of service s/during a network outage/in some situations, such as a network outage/
Invalidating the ticket due to a liveness failure would make session resumption impossible.I think this clarification is not necessary.
I think this discussion on the list shows that it is neccessary?
I am confused a bit about 4.3.1: Current: a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected by a gateway. Why is there a SHOULD and not a MUST NOT ? With the SHOULD I guess I can now ignore it (as we do in our implementation currently). We could clarify here that the timing interactions of ike lifetime, re-auth lifetime and ticket lifetime should prevent it from being used after the user credentials have expired, but I don't think it is really needed in the errata?I guess that it's SHOULD, because if it were MUST, a stateless server implementation would not be possible, even with ticket by value.
But that is a cop out. It should have explained in which cases it should not be rejected. If this section had clarified the liveness probe failure case, we would not be having any of this discussion and everyone would have implemented it properly :) Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
