On Thu, 25 Feb 2016, Tero Kivinen wrote:
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 am confused. Is this a notify of the server to the client, or a
configuration item by the server instructing client behaviour?
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.
So this seems like it is a configuration dictated by the server for
the client to use. What if the client disagrees? Does it ignore this
and use its own local policy?
Some implementations use really short liveness check timeouts
and send the liveness checks ever n seconds when connection is silent.
So with this option, is the server now allowed to not answer a liveness
probe and should the client not close the connection if it receives no
answer?
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.
That's something that could go into an 7296 update as it is a useful
policy change in general (and likely already implemented by some. We
do this already as well)
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.
Sure, that text could use an update.
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.
The text below cities still does not make it clear to me if this is
a notification or an instruction.
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.
But a notify is something that is informative, not instructive. So now
I am all confused again.
So unless people object I will say "go ahead" in few days.
I would _really_ prefer a 2 page draft that states the problem and
the solution, so that it becomes clear if these are local policy
suggestions or actual configuration requirements the client has to
accept or reject.
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. The IKEv2 registries are filling up with non-ikev2 entries. It
would really make sense to run this through the working group. I'll
bring this issue up in the TEG/TLC next week.
Paul
Original allocation request:
===
Contact Name:
Frederic Firmin
Contact Email:
frederic.fir...@etsi.org
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
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
