Hi Tero. IKEv2 has an underlying assumption that peers are always available to respond (for example to liveness check). 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. These should include: - no liveness checks, as these would lead to timeouts and dropping of SAs. - no initiating (this I think violates 4301, but it's OK if IKE retransmits a couple of times and fails)
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. 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. 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. 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. 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. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
