On Mar 21, 2014, at 7:20 PM, Yaron Sheffer <[email protected]> wrote:
> Hi Yoav, > > I like your attempt at reducing the requirement set to the minimum. > > Parts of the text I think do not distinguish well between IPsec hosts (such > as remote access clients) and (simple) hosts, that are non-IPsec hosts > protected behind a gateway. Presumably simple hosts will be unaffected by > this protocol. > > And in the spirit of minimizing the set of requirements: isn't your #3 > solution components just an optimization? I think in many cases a protocol > that includes #1 and #2 but not #3 could be sufficient for scale. And then #3 > could be added as an extension. Or we can decide that we do not need a fully > general #3, and we're good enough with simple shortcuts between two spokes of > the same hub. > Without #3 we are left with the easy configuration - a few hubs meshed together, and all other nodes know about 1 hub each. This has some issues: - The hubs have very large peak loads. - A failure of a hub is catastrophic - the VPN goes away. - Increased latency because traffic goes through multiple hops. Both of these points together make the hubs insanely expensive. They need to have hardware (both in the gateways themselves and in the network links) that will carry the peak load without introducing even more latency, and they need to have enough redundancy to practically never go down. Both of these are solved problems, but they’re problems you need to throw a lot of money at to solve. So without #3, I am not sure the effort is worthwhile. As for a lightweight #3, that only shortcuts the spokes of a single hub, it’s better than nothing, but I can use the example of my company (medium sized by any measure) that still manages to have two hubs. I’d rather that VoIP calls between two remote access clients connected to the different hubs (think me and Bob) not have to go through both hubs. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
