I might have put it like this if it wan't so similar to the way things are configured on Check Point gateways :-)
It makes sense to me, but I'm not sure it covers all the use cases. Imagine a topology that is entirely mesh, except for HTTP(S) traffic that is routed to a central site because they have some HTTP inspection gateway there. It's a requirement that came up a while ago. How does that fit the "either mesh or star" topology? Also, a gateway that is part of more than one topologies (at Check Point we call them "communities") would have to have a different view of the network in these two contexts. As far as its peers in community A are concerned, it is protecting all the networks behind any gateways in community B, but for members on community B, it is protecting all the addresses behind gateways in community A. On May 12, 2012, at 10:53 PM, Vishwas Manral wrote: Hi Yaov, If I udnerstand correctly, what you seem to be talking about is a Star-of-meshes or a mesh-of-star topology. In my view this would be dealt with in 2 different iterations of the Mesh VPN topology. So there would be a Mesh VPN for the Star topology and a separate instance of the Mesh VPN for the mesh topology. Let me know if that makes sense. I think we can state that the requirement should allow for such iterative use cases, however at one instance we only look at star or mesh topology. Do I make sense? Thanks, Vishwas On Sat, May 12, 2012 at 11:34 AM, Yoav Nir <y...@checkpoint.com<mailto:y...@checkpoint.com>> wrote: Hi. I think it should be more complicated than this. The suggested solution has a dichotomy of either a full mesh or a start topology. The requirements should cover scenarios such as a mesh within an organization connecting to a hub to gateways outside the organization, or multiple hubs connected among themselves in either a star or a mesh, or even certain "routes" that are manually configured along with all the auto-discovery stuff. Perhaps we can capture the needed complexity by talking about groups of nodes, where nodes that belong to a single group attempt to create a mesh among them, and packets can travel between nodes that do not belong to the same group through group intersection. I'm not sure if this level of detail is part of the problem statement, but it's more high level than a solution. On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: > Hi, > > I would like to start off by trying to resolve the issue. The notes from the > IETF are attached below. > > Description:Some admins prefer a star topology so they can inspect traffic. > They may not want to use this technology. > > Detail arguments: My take is similar to what Yaron and Yaov seem to state. > There is no reason to exclude star topology at all from the Problem > statement/ requirements document. In fact both the proprietary solutions I > know of allow for such a topology. I however understand that some of the > functionality on the Hub (of the star) could be achieved by using PFP flags > in the SPD entry. > > Suggested Resolution: State in the document that Star topology is not > excluded from the solution. The problem of configuration is however mainly > limited to the Hub. For every spoke added/ deleted/ modified the > configuration on the Hub needs to be changed, which is not desirable. May be > update Section 3.2 with the same too. > > Thanks, > Vishwas > =========================================================== > Notes from meeting minutes: > > # 219 Star topology as an admin choice > People don't need to use this if they don't want to > Say this in the security considerations > Yoav Nir: > Has to be a requirement that any solution > can > implement different policies > Yaron Sheffer: > Agrees with Yoav, maybe becomes a use case > Take this to the list > _______________________________________________ > IPsec mailing list > IPsec@ietf.org<mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
