But this quickly reduces to hierarchical routing: consider 3
communities, C1, C2, C3. Connectivity is C1 == C2 == C3 (i.e. no
direct connectivity between C1 and C3). The connecting member between
C1 and C2 needs to know everybody in C1 and C2 - that's clear. But it
also needs to know endpoints in C3 in order to route traffic from C1 to
C3 (assuming we prefer end-to-end protection of traffic). So these
connecting members either need to know the complete topology, or you
have some sort of routing/discovery between connecting members.
The end result is a 2-level hierarchy: community-internal traffic is
managed by the community, while cross-community traffic is managed
(somehow) between connecting members.
To repeat: I suggest that we do *not* take this path.
Thanks,
Yaron
On 05/19/2012 09:47 PM, Yoav Nir wrote:
On May 19, 2012, at 3:53 PM, Yaron Sheffer wrote:
Hi Vishwas, Yoav,
Check Point (IIRC) supports communities of IPsec endpoints, arranged
either as a star or a full mesh. This is nice and simple to configure
but obviously does not cover all use cases. Some networks cannot be
represented either as a full mesh or as a simple star.
More complex topologies can be achieved by having some IPsec endpoints be
members of more than one community. That way, traffic can go from any member of
one community to any member of another community through the common member. I
think multiple communities with shared members does cover all the use cases,
because taken to the edge case, an IPsec tunnel is a mesh with two members.
Of course, if you configure your VPN as a large number of communities, each
with two members, you've really lost all traces of simplicity, and you have to
configure as much as simple IPsec, but a more common case would be several
large communities, each either a star or a mesh, and then either an endpoint
that is shared between them, or tunnels (2-member communities) to connect each
pair of communities.
While the configuration for a single star or mesh community is relatively simple, this
moves the complexity to those connecting members. They need to know what is
allowed to pass between the different communities.
Yoav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
