Yoav Nir writes: > There are two things I'm wondering about, though. Why is this draft > written like a mini-RFC5996, instead of just referencing 5996 and > describing a profile. You could skip all of Appendix A and much of > the explanation in section 2.
One of the reasons is that I wanted the document to include things that implementor needs. If I would require implementor to read RFC5996 in addition to this draft, that would not help them to make implementations. Now the current document tries to be short enough that people will see that "ok, this is something we can implement" especially when they see that the most of the pages is simply payload format descriptions, which they can simply read when they are actually writing that payload encoding/decoding, and otherwise skip over. > Also, what happens with SA expiry? According to section 2.1, the > "thing" Cannot send delete payloads in Informational exchanges. SA expiry is not an required feature of IKEv2. It is completely possible that IKEv2 node looses IKE SA without sending delete notification, and starts from the beginning. For the minimal devices they can completely forget the IKEv2 SA (and IPsec SA) when they go to sleep, and recreate it every time they wake up, i.e. the sleeping is more less a "turning off" and "booting up again". Or they can keep the IKE SA and Child SA up and assume the server will is configured so it will keep it up, and do not expire the SA based on the time. Those SAs usually has so little data going through them that there is no need to rekey SA based on the time. For some cases there might be more data (for example video feed from camera), but in that case minimal implementation is not enough anymore, as in that case you do usually need support for rekeys. > I guess it could just create a new IKE SA if its policy says that > the old one has expired. But if the SA expires first on the > controller, either the "thing" is sleeping and will miss the DELETE > payload, or it's not sleeping, and will ignore the DELETE payload. > Either way, you're stuck with an SA that exists on the "thing" but > not on the controller. If the "thing" is configured so that it keeps IKE SA up, then the server should configured so that it does not expire the SA. Most of those protocols include reply anyways, so if no reply is received the "thing" can start over, i.e remove the IKE SA and recrete it from the scratch and then try again. > I can think of three ways to avoid this: You can require that SA > lifetimes be always shorter on the "thing" than on the controller. Or remove the concept of lifetimes, as they are not needed here. > You can require them to explicitly send SA lifetimes. Lifetimes in IKEv2 is local matter, and they are never transmitted. > Or you can require them to implement failure detection. No need for that. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
