Paul Wouters writes: > 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?
It is notify from the server to client. I.e. client sends empty TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and server will send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in CFG_REPLY. I.e. the server asks client to use following livenss timeout period. > > 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? This is 3gpp, and what ePDG says is the law. No-one dares to disagree :-) I.e. their specification does not say anything about what happens if client disagrees. It do say that if it does not support this, then it will use whatever preconfigured value it has. On the other hand if client does not follow this request, there is nothing server can do. I.e. this only specifies how client sends those messages after timeout, it does not say that server should act on those messages. I.e., I do not think server can do anything based on the fact that it got them too often, or did not get them often enough... > > 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? No. Server will respond to them as normally as this is normal mandatory behavior from IKEv2, and yes client will close the connection if server does not respond just like with normal IKEv2 liveness check. > > 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) I think that is bad policy and I think it can be silently be allowed, but I do not really think we should encourage it. If connection is completely silent, i.e. no traffic flowing at all in either direction, there is no point of sending any liveness checks over it. In that case those liveness checks are just make dead packets. If your VPN is silent and no messages are going through (you are sleeping), and there is 30 minute network failure during the night, the make dead packets will kill your VPN and in the morning you need to retype your password even when the connection is working at that point. If you do not send make dead packets during the idle period, in the morning when you come to the keyboard and hit first time any key, that will send the packet to the other end and if other end is still up and running, VPN will continue stay up. If the other end has rebooted, it will reply with ICMP or IKE invalid SPI notify, which will trigger liveness check, and then the connection will be deleted quite soon, and new one connection is formed. > > 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. My understanding is that it is notification, i.e. there is no rules in the specification saying that server end should expect those liveness checks, and do something if it gets them or does not get them. > > 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. That is my inderstanding what this is. You can go and download the http://www.3gpp.org/ftp/Specs/html-info/24302.htm and check yourself. > > 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. If we could even get few paragraph explanation that would be really good, thats why I said it would be nice if 3gpp people would run their additions through this list before writing it in their draft. Now I have to check that 116 page document and find out what it is supposed to do :-) > > 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. What is TEG/TLC? > > 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 > > -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
