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. 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. Original allocation request: === Contact Name: Frederic Firmin Contact Email: [email protected] Type of Assignment: New item in the "IKEv2 Configuration Payload Attribute Types" of the "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and IETF RFC 7296. Registry: The "IKEv2 Configuration Payload Attribute Types" of the "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and IETF RFC 7296. Description: This IKEv2 attribute is used to provide configuration for performing the liveness checks. Additional Info: ETF RFC 4306 defines the registry for the "IKEv2 Configuration Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to IETF RFC 4306 for the definition of the registry. The following attribute is requested to be registered: - value: (number to be assigned by IANA) - attribute type: TIMEOUT_PERIOD_FOR_LIVENESS_CHECK - multi-valued: no - length: 4 octets - reference: 24.302 13.4.0 http://www.3gpp.org/ftp/Specs/html-info/24302.htm -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
