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

[Vishwas Manral]

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  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  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
>> > https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity

[Vishwas Manral]

Hi Yaov,

I do see NAT traversal as a requirement and should be made part of the
problem statement. I however do not see it as a resolution of #213 or #214.
I see resolution for #218 and #211 talk about NAT.

Routing is about how packet is sent to the nexthop closer to the
destination, which is what this issue is about in my view. It is what
determines if the destination and source are one hop away or can traverse
multiple gateways along the way. So if you only allow direct routing (or
through hubs), there is no way packets can traverse any other way.

What you seem to suggest is that there are ways in which VoIP can traverse
NAT at both the sender and the receiver. That in my view is a solution
suggestion, that you seem to be giving.

Can you give more details of what you mean by #214?

Thanks,
Vishwas

On Sat, May 12, 2012 at 12:58 PM, Yoav Nir  wrote:

> I'm not sure I understand the suggested resolution. The biggest barrier to
> direct connectivity is that the responder may be behind NAT. Is this
> considered a "routing issue"?  In any case, there are protocols for getting
> to a responder behind a NAT. They work well enough that VoIP solutions work
> pretty much everywhere where there isn't a firewall that's specifically
> targeting VoIP. I think we should user them, adapt therm or profile them
> for IKE/IPsec, although this does not necessarily belong in the solution
> document.
>
> As for #214, I don't see how this is answered. If an gateway A would like
> to contact a host behind gateway Z, and does so through gateway B, must
> gateway B provide the addresses for gateway Z, or can it give the address
> of gateway D, which will then provide the address of gateway Z?  IOW, must
> redirection be 1-step?
>
> Yoav
>
> On May 12, 2012, at 2:03 AM, Vishwas Manral wrote:
>
> > Hi,
> >
> > Description: Direct endpoint-to-endpoint connectivity may not be
> possible. Should gateways figure things out completely or just punt
> endpoints to a closer gateway?
> >
> > Detail Arguments: As Izaac and John Lesser pointed out this is more of a
> routing issue. Though current solutions do not allow such connectivity
> unless through a hub, I think from the security plane, we should not
> preclude such connectivity. This could be achieved either transparently (no
> IPsec component except the SPD involved), or by stitching tunnel traffic.
> >
> > Suggested Resolutions: Specify explicitly that issues around direct
> connectivity between endpoints are more of a Routing issue. However IPsec
> should not prevent such a connectivity model.
> >
> > Thanks,
> > Vishwas
> > ===
> > Meeting notes:
> >  # 213 In use case 2.1, direct endpoint-to-endpoint
> connectivity
> >   may not be possible
> >   Need to mention challenges in use cases section
> >   Paul: reminded that there will be a separate
> requirement
> >   section
> >   # 214 Should gateways figure things out completely or
> just punt
> >   endpoints to a closer gateway?
> >   Core gateway configuring is a solution, so
> premature
> >   Also in #213
> >
> > ___
> > 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

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

[Yoav Nir]

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 
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
> https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity

[Yoav Nir]

I'm not sure I understand the suggested resolution. The biggest barrier to 
direct connectivity is that the responder may be behind NAT. Is this considered 
a "routing issue"?  In any case, there are protocols for getting to a responder 
behind a NAT. They work well enough that VoIP solutions work pretty much 
everywhere where there isn't a firewall that's specifically targeting VoIP. I 
think we should user them, adapt therm or profile them for IKE/IPsec, although 
this does not necessarily belong in the solution document.

As for #214, I don't see how this is answered. If an gateway A would like to 
contact a host behind gateway Z, and does so through gateway B, must gateway B 
provide the addresses for gateway Z, or can it give the address of gateway D, 
which will then provide the address of gateway Z?  IOW, must redirection be 
1-step?

Yoav

On May 12, 2012, at 2:03 AM, Vishwas Manral wrote:

> Hi,
> 
> Description: Direct endpoint-to-endpoint connectivity may not be possible. 
> Should gateways figure things out completely or just punt endpoints to a 
> closer gateway?
> 
> Detail Arguments: As Izaac and John Lesser pointed out this is more of a 
> routing issue. Though current solutions do not allow such connectivity unless 
> through a hub, I think from the security plane, we should not preclude such 
> connectivity. This could be achieved either transparently (no IPsec component 
> except the SPD involved), or by stitching tunnel traffic.
> 
> Suggested Resolutions: Specify explicitly that issues around direct 
> connectivity between endpoints are more of a Routing issue. However IPsec 
> should not prevent such a connectivity model.
> 
> Thanks,
> Vishwas
> ===
> Meeting notes: 
>  # 213 In use case 2.1, direct endpoint-to-endpoint 
> connectivity
>   may not be possible
>   Need to mention challenges in use cases section
>   Paul: reminded that there will be a separate 
> requirement
>   section
>   # 214 Should gateways figure things out completely or just 
> punt
>   endpoints to a closer gateway?
>   Core gateway configuring is a solution, so premature
>   Also in #213
> 
> ___
> 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

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

[Vishwas Manral]

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  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
> > https://www.ietf.org/mailman/listinfo/ipsec
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec