Subject: [IPsec] Issue #219 - Star topology as an admin choice

From: Vishwas Manral <[email-masked]>
Date: Fri, 11 May 2012 15:11:51 -0700

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

---

From: Yoav Nir <[email-masked]>
Date: Sat, 12 May 2012 21:34:37 +0300

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
>                           People don't need to use this if they don't want to
>                                   Has to be a requirement that any solution can
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 12 May 2012 12:53:17 -0700

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 <[email-masked]> 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.
>
> > 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

---

From: Yoav Nir <[email-masked]>
Date: Sat, 12 May 2012 23:16:34 +0300

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi.

On May 12, 2012, at 1:11 AM, Vishwas Manral wrote:

> [email-masked]<mailto:[email-masked]>

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 12 May 2012 13:26:44 -0700

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 <[email-masked]> wrote:

> 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.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 May 2012 15:53:04 +0300

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:
> 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.
>
> On Sat, May 12, 2012 at 1:16 PM, Yoav Nir <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I might have put it like this if it wan't so similar to the way
>     things are configured on Check Point gateways :-)
>
>     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.
>
>>     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
>>
>>         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.
>>
>>         > 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
>>         > [email-masked] <mailto:[email-masked]>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 May 2012 21:47:05 +0300

> 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

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 May 2012 22:23:53 +0300

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