Hi Paul, > >> 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 > client > > > > The following text: > > > >> MUST NOT send Delete Notifications and > > > > is 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".
I fail to understand this. RFC7296 is very clear, that if exchange is timed out, IKE SA is silently deleted (Section 2.1): IKE is a reliable protocol: the initiator MUST retransmit a request until it either receives a corresponding response or deems the IKE SA to have failed. In the latter case, the initiator discards all state associated with the IKE SA and any Child SAs that were negotiated using that IKE SA. Note, that RFC7296 doesn't say that you may/should/must send a Delete payload in this case, it says that IKE SA state is discarded. You cannot send DELETE notification over discarded SA. And I disagree that "cannot" is just a subset of "MUST NOT". "MUST NOT" means that you are able to do this, but it is forbidden. You don't say: "you MUST NOT use TCP/UDP port number greater than 65535" or "you MUST NOT exceed speed of light". > >> 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/ Works for me. > >> 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? No, it is not necessary. You put all the requirements not to invalidate ticket in this case in the preceding text. This sentence adds no additional requirements, it just explains why these requirements are imposed. You may leave it, but I don't think it's necessary... Regards, Valery. > >> 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
