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 ?
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. 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. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
