Paul Wouters writes:
> On Fri, 28 Aug 2020, Michael Richardson wrote:
>
> > > We added a suspend commend, but since that deleted states on the
> > > initiator, it ended up sending delete's to the server. The server
> > > deleted the IKE SAs. Now the client can resume a connection that
> > > technically was ended by Delete.
> >
> > It seems that either the client shouldn't send deletes, or:
>
> But not sending a delete will just result in the server sending liveness
> probes and deleting the client shortly after the client suspends
> quietly. If you want IKE Resume to work in the real world with Liveness,
> you basically have to ignore that the client and server delete the SA.
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.
> > > It would be really nice if we can keep the server side to need to
> > > require zero state. If we ignore those two issues mentioned, we can
> > > do that.
> >
> > I agree.
>
> Another approach is to add a notify to MOBIKE to tell the server to
> disable liveness probes, allowing the client to go to sleep without
> fear or losing the state on the server. It can then also sleep for
> some time and come back up with an MOBIKE update message. It wouldn't
> allow the server to delete the state but it does allow the client to
> go to extended periods of sleep without fear of not being able to
> continue with the existing Sa.
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 even when it is described in the RFC4621 Section 5.4:
----------------------------------------------------------------------
5.4. Zero Address Set Functionality
One of the features that is potentially useful is for the peer to
announce that it will now disconnect for some time, i.e., it will
not be reachable at all. For instance, a laptop might go to suspend
mode. In this case, it could send address notification with zero
new addresses, which would mean that it will not have any valid
addresses anymore. The responder would then acknowledge that
notification and could then temporarily disable all SAs and
therefore stop sending traffic. If any of the SAs get any packets,
they are simply dropped. This could also include some kind of ACK
spoofing to keep the TCP/IP sessions alive (or simply setting the
TCP/IP keepalives and timeouts large enough not to cause problems),
or it could simply be left to the applications, e.g., allow TCP/IP
sessions to notice if the link is broken.
The local policy could then indicate how long the peer should allow
remote peers to remain disconnected.
From a technical point of view, this would provide following two
features:
o There is no need to transmit IPsec data traffic. IPsec-protected
data can be dropped, which saves bandwidth. This does not provide
a functional benefit, i.e., nothing breaks if this feature is not
provided.
o MOBIKE signaling messages are also ignored. The IKE SA must not
be deleted, and the suspend functionality (realized with the zero
address set) may require the IKE SA to be tagged with a lifetime
value since the IKE SA should not be kept alive for an undefined
period of time. Note that IKEv2 does not require that the IKE SA
has a lifetime associated with it. In order to prevent the IKE SA
from being deleted, the dead-peer detection mechanism needs to be
suspended as well.
Due to its complexity and no clear requirement for it, it was
decided that MOBIKE does not support this feature.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
