Suresh Melam writes: > Ending up with two IKE SAs, may not be an issue in terms of functionality, > but can be seen as an issue in terms of scalability.
I do not think so. I do not think this is very common situation hapening in the wild. It can happen if both ends decide to try to connect to each other exactly at the same time, which is usually not so common. The more common situation is that the network breaks down and both ends drop connections, and then connection come up again, and both ends try to reconnect, but in this situation this kind of thing can be solved by good implementation solutions, like using random backoff, jitter in the connections, checking out whether other end has already started connecting to us before starting to connect to them etc, or using different timers depending whether the original lost connection was initiated by this end or other end. As this kind of timing issues usually only happen (in large scale) between very similar implementations (i.e. both ends are from same vendor) it is usually enough to have vendor specific implementation solution for this. > Can we come up with a "standard" way of discarding the extraneous IKE SA, > so that both peers will discard the "same" extraneous SA? Any non standard > method to discard, may end up in two peers discarding both the SAs. There is no way to know they are really extraneous, as it is completely legal for other end to create two IKE SAs if he feels like it. So neither one of them is extraneous in that sense. > It may also be just plain confusing to the end user, as you mentioned > below, in a scenario with two CHILD SAs negotiated from two IKE SAs can > continue to rekey forever, and then one peer may use one CHILD SA for its > outgoing traffic whereas other peer use the "other" CHILD SA for its > outgoing traffic. End user does not see any difference. For end user his traffic just goes through and thats it. End users should not see IKE SAs or Child SAs.... > Again not a functionality issue, but could be seen as an usability > issue. Which can be solved by good engineering solutions in the vendors implementations. For example if this is really a scalability issue for the scenario, then the vendor having scalability problems can detect this situation and move his Child SAs from his own IKE SA to the other ends IKE SA, and when that is done (and ole Child SAs have been deleted) delete the old IKE SA. Again the implementation needs to add jitter and bias to make sure that if two of the same vendors implementations are talking to each other, both ends do not start doing this simultaneously. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
