Hi Tero, Looks like there were few discussion happened on this topic while writing RFC 5996. Why it was not noted in RFC? Even if it was not decided to address it in RFC, I think there is a good value to note it.
I have few more comments inline. -- Praveen On 12/19/11 6:14 AM, "Tero Kivinen" <[email protected]> wrote: 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, [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. 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. [PRAVEEN] Are you suggesting that add jitter before triggering the negotiation? If so, it is not practical. Adding jitter will result in packet loss. If you are suggesting jitter in state m/c (delay in responding to 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). 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 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. [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. > 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
