I agree, it is a corner case. Example, out of 5000 tunnels, may be we will see 10 to 15 tunnels end up in this scenario. So memory/resource is not a concern. But question is, how do we handle once we are in that state. For example, which phase1/phase2 SA we should continue to hold (Rekey) and which one we need drop it, etc.
This is where the confusion comes. Each vendor may end up choosing different way to handle it and it may cause confusion with other vendor. If there is a clear description on how to handle (which one to choose and which one to drop), will help. Thanks, Praveen On 5/5/14, 6:09 AM, "Paul Wouters" <[email protected]> wrote: On Mon, 5 May 2014, Syed Ajim Hussain wrote: > Thanks for your reply, This problem happened in real scenario, >problem is- both the Tunnel end points are different vendor, > They handle it differently. > > We can defined this behavior in RFC, > > Also we have some other scenarios, it will be better if we define >these extreme case behavior also in RFC, > to make inter-op smooth. In libreswan (openswan) the daemon processes one packet at a time, so by definition one of the child SA's finishes before the other, no matter how close the timing is. It also has a feature "uniqueids" that would (dis)allow identical Child SA's, so the latter one establishing replaces the previous one established. I'm not convinced your issue is a protocol issue. It seems more like an implementation issue? If any of your endpoints involved libreswan/openswan, feel free to contact me. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
