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.
Trying to shoehorn the more complex networks into "star of meshes" or
"mesh of stars" topologies would not solve the general problem either,
and instead would complicate things greatly by having to deal with
multi-layer routes.
So stars and full meshes are OK as common use cases. But as/when we move
into requirements, I would suggest that we abandon them in favor of
generic networks/graphs of IPsec endpoints. And implicitly, generic
routing within such networks.
Thanks,
Yaron
On 05/12/2012 11:26 PM, Vishwas Manral wrote:
Hi Yaov,
Perfect. We are on the same page here.
The way I see it is we treat it as a Mesh topology. The hub spoke
tunnels are permanent, with temporary and on-demand (based on data/
time/ activity) spoke to spoke connectivity. This way we do not have the
overload of excess configurations on the spoke, while still allowing
mesh connectivity.
I could specify that as a sub usecase of the Mesh Topology.
Thanks,
Vishwas
On Sat, May 12, 2012 at 1:16 PM, Yoav Nir <y...@checkpoint.com
<mailto:y...@checkpoint.com>> wrote:
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
