Hi Paul, > So here is my first pass: > > Abstract: > > 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. > 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. > 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. > Invalidating the ticket > due to a liveness failure would make session resumption impossible. I think this clarification is not necessary. > 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. Regards, Valery. > This one is also a little tricky: > > Note 3: If the certificate has an iPAddress SubjectAltName, and the > implementation requires it to match the peer's source IP > address, the same check needs to be performed on session > resumption and the required information saved locally or in > the ticket. > > We need to update our implementation to add this ip restriction into the > session ticket so we can compare it on resume without having the CERT. > > Paul > > _______________________________________________ > 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
