Yoav Nir writes: > Actually, in our implementation, all packets (IKE and ESP) have the > cluster IP address, so the peer doesn't notice a failover, and also > the peer can't tell which member is "active" or which member it is > working with.
Yes, that is also one way doing it, but in that case there is no problem, as IKE and ESP uses same address. > > If the ESP packets have special handling that will change their outer > > source address to match cluster's IP address instead of individual > > member's IP address, then the same mechanims can easily be used for > > IKE SA too. > > Not really. The IPsec stack constructs the ESP header and > encapsulating IP header for tunnel mode SAs. It can put whatever > external IP address it wants in there. IKE is handled by a user > space process that opens a regular UDP socket and sends packets. To > get those packets to have the cluster IP address, we need some > special OS feature that allows you to override the IP stack, or a > NAT mechanism to change the packets. In userspace you can still use the normal bind operation to bind the source IP to specific IP address. You do not need special OS features, those features are usually present in most of the operating systems available, so you just need standard OS features... > > We already have standard track mechanims for updating the outer > > address for both Child SAs and IKE (MOBIKE), so even when the > > cluster's outer IP address is used in normal case, the failover to > > another cluster member (using different IP address) is easy to do > > provided both the cluster member's share the same SA state. > > MOBIKE was intended for mobile clients such as laptops and phones. That is one use. Another use for for gateways to provide high-availability when you have multiple connections to the internet, i.e. multiple ISPs. > It would be weird to use that for the enterprise gateway that uses > clustering to improve scalability or availability. I would expect to see it in all environments where the gateway supports redundant intenet connections, i.e. same box has two connections to the internet using different ISPs (and of course using completely different IP-addresses). > But in any case, at the moment we are only dealing with a problem > statement. Solutions are yet to come. I have not read the draft you mentioned, but I assumed it was also solution document, not problem statement document. I do not know how it relates to MOBIKE, or to anything else, but I think MOBIKE is one of the solutions we are going to be using where it is applicable. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
