Yaron Sheffer writes: > The exact same thing applies to the gateway-to-gateway situation. Suppose > Gateway C initiated an IKE SA with gateway A. Two hours later GW C goes into > maintenance, so it asks GW A to redirect into Gateway D. GW A cannot just > initiate a connection to D, because it doesn't know that it needs to until > told by GW C. And it doesn't matter who initiated the SA in the first place.
When C goes to the maintenance, it will also change routing so that packets which used to come to him, will go to D. Immediately when first such packet gets to D, the D will initiate connection to A, so C can simply change the routing, and then delete all IKE SAs. > Yes, there is some routing/tunneling magic going on "behind" the gateways, > but why should we rely on it to initiate the IKE redirection, when we have > the mechanism defined in the current draft? Mostly because redirections gets very complicated if both ends can move at will... For example what happens if the gateway A is rebooted, while C is still down. Now C will not reply with redirect to D, thus we still need to rely on some other external mechanism to redirect stuff from C to D, i.e. most likely both of them are configured in the configuration, so A will know that it can connect either C or D. When we were writing MOBIKE, we noticed that things gets very complicated very quickly if such scenarios are allowed, and in that case you cannot really expect the systems to just work, you still need to write new document profiling how nodes should be configured and used in such cases. If we are going to need such profile anyways to get usable protocol, we can write protocol extension at the same time which profiles redirect to be used in gw-gw scenarios and also extends and defines how it should be used in that case. We have way too many protocols already where the actual protocol document does not provide interoperability. The documents are so wide open, that nobody implements all the optional things (or not even all the mandatory to implement things), thus you cannot just take two implementations and assume they work together on your specific scenario. In those cases you need to write profile that tells what features are required, and then you might get interoperability (provided you will find any implementations fulfilling those requirements). My proposal was to say that we do not define that usage in this document, but it is not explicitly forbidden either, so we assume that if such usage is needed, new document extending this one will be written. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
