Paul Wouters writes: > On Mon, 31 Aug 2020, Tero Kivinen wrote: > > > That should not matter, the server should not invalidate tickets even > > if there is liveness failures, as if it does that every time there is > > transient network failure the resumption is useless. > > I agree, but that is not what the RFC says. Perhaps this would qualify > for an Errata ?
Note, that when liveness check fails there is NO delete to be sent over the IKE SA, thus IKE SA is not deleted, it was just deemed to have failed. If any implementation sends Delete notification when liveness check fails that is a bug... RFC7296 says: ---------------------------------------------------------------------- 2.1. Use of Retransmission Timers ... 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. ---------------------------------------------------------------------- I.e., there is no delete notification sent, and IKE sa is not deleted, initiator just discards all state associated with IKE SA (and this would be the SGW side doing and failing the liveness checks). If the stateless resumption is used, then there is no state in SGW side anyway to be stored, so when client comes back with resumption request then server recreates the state. RFC5723 explitly says that "In particular, when an IKE SA is deleted by the client or the gateway, the client MUST delete its stored ticket.", which would mean active delete operation, not just destroying of state because of liveness failures. Also 3 is quite clear that losing network connection and ike sa timing out because of liveness tests does NOT invalidate ticket, as this is expected case where ticket is used to reconnect. Same with suspending laptop. > > At one point I did propose an option for MOBIKE to send address update > > without any addresses, i.e., saying that I will go to sleep so I will > > not have any addresses you can use to connect to me, do not call me, I > > will call you when I am back... > > > > If I remember right people considered it too complex, and this was not > > accepted > > But it is possible, sort of. The client just sleeps and upon wake up > sends the UPDATE without any addresses specified and the responder > will update to the address and port of the IKE header (after packet > was authenticated). But you are right in that with MOBIKE, we have no > way of saying "please suspend any liveness tests - I will be out of > the office". > > I do think overall it would have been better to have 1 solution instead > of 2. But I think with supporting both, things can work the way we want. > > For unexpected network outages we can switch interface using MOBIKE. > Like phone losing wifi briefly in the elevator. For expected downtime, > eg "phone is going to sleep mode" we can use RESUME to reconnect. You use mobike if your IP-addresses changes, but IKE SA is still active. You use resume if you were away so long that IKE SA state was cleared out on the SGW. > Resume does take two roundtrips over mobike taking one. So perhaps it > would still be nice to have the "out of office notify" to instruct > the server to disable liveness so MOBIKE can be used instead of RESUME. > However, that does take more resources on the server. But looking at > realy busy servers now - it is a stream of (re)connecting clients, > so I'll take any solution even if it needs state as it is less work > than all these new DH exchanges. Modifying MOBIKE so that there is one new NO_ADDRESSES notification which says there will not be any addresses for the client, not even the one over which this message came in, and then server should simply blackhole all communications for this client until it comes back and gives some addresses (and of course disable liveness checks). If IKE SA or Child SA expires or needs to be rekeyed then as packets are blackholed, the SGW acts just like the operation timedout, i.e. descards IKE SA state). In that case when client comes back and tries to do mobike, it will fail with INVALID_IKE_SPI as the SGW has descarded state for that IKE SA, so client can do resumption to get IKE SA back. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
