Hi,
I as an IANA expert got request from 3gpp to allocate new
configuration attribute called TIMEOUT_PERIOD_FOR_LIVENESS_CHECK for
IKEv2. This is used to set the timeout after which the UE will do
liveness check with other end if no cryptographically protected IKEv2
or IPSec messages are not received.
I.e. it is mostly same procedure as RFC7296 but in this case the the
parameter is not locally configured, but sent by the server end.
I can see some merit for this as this allows the server to limit the
number of liveness checks by sending larger number, for example 600
seconds. Some implementations use really short liveness check timeouts
and send the liveness checks ever n seconds when connection is silent.
Some implementaions simply do one liveness check after the connection
goes silent, but after that assumes that connection is ok as long as
there is no packets going out, and only redo the liveness check after
they have sent something out and not received anything back.
This is more in align with first use, i.e. the text asks to send
liveness check this often even if the connection is completely silent.
The IKEv2 text says we do liveness checks to avoid black holes, and
there cannot be black holes for packets if we do not send packets,
thus we are not supposed to send liveness checks if both ends are
silent.
I am thinking of saying "go ahead" for IANA for this allocation even
when this do change the IKEv2 bit, as I think there are
implementations using same interpretation out there, and I think this
configuration attribute is mostly harmless. If we would have done it
here in the IPsecME WG, I think we would have used notifications
instead of configuration payloads, as this attribute do affect the
whole IKE SA and is not configuration attribute related to IPsec SA.
So unless people object I will say "go ahead" in few days.
I don't strongly object, however I have a concern:
how server can enforce the timeout period it sent to the client?
The client can ignore it and do liveness check more often
(for a good reason, if it has some data to send and has
no reply from server) or less often. It seems that this
notification could be ignored by the client completely and the server
cannot do anything about this (otherwise than tear down the
connection with "bad boy", but is it an intention?).
Or is this notification just a hint, not an enforcement?
Ps, I still think it would be better for 3gpp to run their additions
to IKEv2 through the IPsecME WG first to get some feedback for them
before adding them to their drafts (i.e. send email to the list and
ask for comments, no need to write internet drafts about proposals,
but just explain why and what they plan to do). I at least would be
more than happy to provide them feedback earlier, as I think this IANA
allocation phase is too late phase to do such things.
Yes.
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
