Yoav Nir writes: > IKEv2 has an underlying assumption that peers are always available > to respond (for example to liveness check).
Can you point me to that in RFC5996, I think I might have missed that. I am under the understanding that either end of the IKEv2 protocol can crash/shutdown/go silent at any point and after that point it will not answer to any IKEv2 messages anymore and this is allowed by the protocol and all complient implementations should be able to cope with it. > If you're doing a special profile for minimal implementation that > are not always available (because they're in a low-power mode), you > should also profile the server that talks to them. Note, that the draft-kivinen-ipsecme-ikev2-minimal-00 does explicilty mention how to respond to the DPD etc message, i.e. the minimal implementation implemented based on the draft do know how to answer to requests sent by the server, provided the device is still active. After the device is powered off, it of course cannot answer anymore. For example the appendix B.1 describes one additional useful feature for such devices, i.e the ability to send delete notification to the IKEv2 SA before going to sleep so server end does not waste resources while trying to do DPD, and then noticing that other end has disappeared, and tearing down the IKEv2 SA. > These should > include: > - no liveness checks, as these would lead to timeouts and dropping > of SAs. Liveness checks are optional anyways and only performed if the device thinks there is some reason to belive that the other end is no longer up. No sane IKEv2 implementation should ever implement periodic liveness checks, and I do agree that using periodic liveness checks breaks lots of other things too, and in my opinion rfc5996 should have prohibited them. Unfortunately some people go for the easy implementation route, and do implement them and then we do have all kind of problems. > - no initiating (this I think violates 4301, but it's OK if IKE > retransmits a couple of times and fails) I do not think RFC4301 forbids to have responder only setups. For most cases that is the most common setup anyways, as for road warriors the SGW cannot initiate to the road warrior as it does not know its IP address. If the device is up and server tries to create new IPsec SA, then it will answer NO_ADDITIONAL_SAS as is allowed by the RFC5996. Anyways neither one of those affects the implementation of the other end at all, only to their policy setup and configuration, and in general configuration of the SGW depends so heavily about the scenario that I see no point of start documenting or dictating what kind of policy is allowed or not allowed in the different scenarios. > One of the use cases that we hear about is small battery-powered > sensors and actuators communicating via 802.15.4 at rates of 10-20 > kbps with 6lowpan. At those rates, it takes several seconds to set > up an IKE and child SA, and that is not fast enough for many uses. > So I think the general way of doing things should be that the > "things" keep the SAs when they go to sleep. Speed of 10-20kbps means the IKEv2 setup time is will be less than second (not counting crypto calculations), as the actual data transmitted during the initial setup is less than 1kB. Anyways I would except that in such environments the minimal device could be configured to keep the IKEv2 SA and IPsec SA up, and the other end should be configured accordingly for that environment. > Most IKE products that I know of don't keep SAs forever. Looking at > the StrongSwan code, it looks like the longest time you can keep an > IKE or IPsec SA is 1 day. And I assume it would be around few lines of code change to remove that limit if someone is forced to use such implementation. At least our product can be configured to keep SAs up for long time (even years depending on the platform). Also RFC4301 mandates support for both time and byte count based lifetimes, and allows either one of them or both of them to be configured. If you have configured SA to use only byte lifetimes, then the time lifetime should not be active at all. > The problem is that the peer might be sleeping when the SA expires > on the server, and we don't want to wait for a timeout when it > wakes. So there has to be a pre-agreement on lifetime. This doesn't > have to be negotiated using AUTH_LT, though. You can specify in your > draft that SAs last 24 hours. 24 hours is way too short for some uses. I would expect it to be around month or a year or so. The data transfer on those links is so slow that before they reach for example 2^32 bytes it takes long time (more than month with your example link). To reach byte count where AES cipher really needs to be rekeyed because we have transmitted too much data over it it takes almost forever :-) > Then you have to deal with failure detection. A failure of the > server would mean that for 24 hours all devices that try to > communicate time out using the old SA, before they restart. It may > be OK to live with it, but this should be stated in the draft. As my draft does not specify any lifetime nor does it assume that SA is up all the time, I do not think there is need to add text specific to one scenario, especially when most of that would be text describing what kind of configuration might be required in some scenarios. I think that text belongs more or less to the exact profile document for that specific environment, i.e. for example the smartmetering profile document or similar could specify that no server initiated DPD is ever done, and lifetime of the SA should be assumed to be more than a year. > Anyway, the thing that's really missing is requirements or profile > for the server, as you can't take a normal IKE implementation and > have it work well with those minimal implementations. The idea of the draft is that it DOES NOT require any requirements or profiling of the server. It works with standard normal complient IKEv2 implementation without any changes. Depending on the scenario some specific configuration of the server is REQUIRED, for example it needs to be configured to allow pre-shared key authentication using the ID sent by the minimal node, and it must be configured to support AES, and its lifetime policy needs to be configured to match the environment where this setup is used. None of those affect the protocol, they are only configuration options which usually are already there in the complient full implementation of IKEv2. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
