On 10/26/11 9:39 PM, "Yaron Sheffer" <[email protected]> wrote:
>There is a common use case where we don't worry about malicious spokes, >i.e. where they are all trusted. > >We do worry about misconfigured spokes, but that would most likely >result in loss of connectivity, which I expect to be fixed in due time. >Or it can be prevented by (static) configuration on the hub. Malicious/misconfigured/compromised, it doesn't matter. One way or another we have a spoke that is configured to protect the 69.171.0.0/16 subnet, that includes all facebook.com servers. If the hub learns the protected network of the spokes from the spokes, then this information will propagate to the entire network. The configuration is easy, because each protected network needs to be configured in one place only, but we have the security problem. Maybe the use of sidr resource certificates could mitigate this, but I don't think they're in wide use yet. On the other hand, we could have all the protected networks of the spokes statically configured on the hub, as you suggest. Then it doesn't matter if the spoke thinks it owns facebook, because none of the others will agree. This has several implications: - Configuration is harder and error prone - spoke and hub must match - It introduces an asymmetry. IPsec is all about peers with separate but matching configuration. In this scenario there is an all-knowing hub that introduces the spokes to one another. I'm not necessarily saying that the second scenario is bad, but it's not as scalable as the first. I'd rather solve both, but solving just the first may be a good first step. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
