Praveen Sathyanarayan writes: > [PRAVEEN] It is not very common, but common enough. We have seen several > customer running into it. Again this is more of scalability issue. Takes > more CPU and memory in maintaining this extraneous SAs. Also it is a > source of confusion for several customers.
If it is ont very common, it should not really affect scalability, I mean you should not design system so that adding 1% of more SAs will cause it to run out of CPU or memory... And if this happens more than 1% of all IKE SA, then I think there is something in the scenario or implementation which causes it to happen. > [PRAVEEN] Are you suggesting that add jitter before triggering the > negotiation? If so, it is not practical. Adding jitter will result in > packet loss. Adding jitter before triggering after the connection has been lost because network breakdown should not affect that much. When the network connection broke down you already lost packets regardless what you did. The only way I could think how this could happen a bit more often is the case where there is already IPsec connection between the peers, and networks breaks down, and both ends try to reconnect the IKE SA simultaneously. > If you are suggesting jitter in state m/c (delay in responding to m/c? No idea what that state is. > 2nd or 3rd packet so that one of the negotiation will be completed > soon), then it should be done only after authenticating peer (for > security reasons). And this can be too late in IKEv2 (as there are > only 2 pair of exchange). I was suggesting jittering and random backoff for the retransmissions of the IKE SA INIT. I.e. when the network comes up again after the break, both ends (or only one end) might detect that link came up and it might want to add some random 2 second jitter before retransmission of its packet. > Thus I don't see a practical solution for it. IMO, we should let > negotiation to complete and come up with tie breaker to cleanup > extraneous SAs. As I do not think this is problem really happening that often, that adding special code for it will most likely just cause more problems than solve issues. For example I am not sure how many implementations actually implement the current simultaneous exchanges stuff we have in the RFC5996. My guess is that there are several implementations implementing at least some parts of it, but not that many who implement every single parts of it. > [PRAVEEN] In our opinion, there should be a optional standard way of > cleaning up extraneous SAs. It is shouldn't be mandatory but it can be > optional. Vendor can decide if they want to implement it or not. I believe > there are vendors already doing it in non standard way if both devices > belongs to same vendor. And I think this kind of solution is best to be left to the vendors. Especially if we do not mandate it, then either end still needs to be able to cope with implementations not implementing it. Having vendors specific way of solving this is fine, as this kind of timing issues mostly only occur when you have two similar implementations (i.e. from same vendor) talking to each other. Usually different vendors use so different timers, and jitters etc that this kind of problems do not occur between implementations of different vendors. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
