|
»
« Return to Thread: Please Comment on New P2P VPN Problem Statement
Re: P2P VPN Problem Statement - why is this hard?
by Yoav Nir
::
Rate this Message:
There's actually two types of stars.
One is where the satellite forwards *everything* to the hub, even some user behind the satellite checking their Facebook account. That kind of satellite really needs very little configuration.
The other is where the satellite forwards only traffic going to an address that is behind *some* satellite or hub gateway. This requires that it partition the Internet into a "protected" and a "non-protected" parts.
Stars vs Mesh is IMO important, because with stars you only need to propagate SPDs while with mesh you also need to propagate PADs. The mechanisms for propagating each kind of information may be different when the time comes to discuss solutions.
Yoav
On Mar 7, 2012, at 11:25 PM, Yaron Sheffer wrote:
> Hi Yoav, Steve,
>
> I'm not sure that this star-vs-mesh discussion is so important, because
> even if you choose the simplest star topology, data propagation is still
> required. Configuration of the satellites is simple: *everything* goes
> to the hub. But the hub needs to know which satellite to send each
> packet to, and as the satellites' configuration changes, the hub
> constantly needs to be reconfigured. So it's really the same problem in
> a more limited form.
>
> Thanks,
> Yaron
>
> On 03/07/2012 12:54 AM, Yoav Nir wrote:
>> Hi Steve
>>
>> On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote:
>>
>>> So please review this short document and send comments.
>>
>> While the draft does a good job of describing use cases, and certain inadequate solutions, I think it's missing a description of why this is hard.
>>
>> Even if we accept the solution of a star topology, where a satellite needs only have one single tunnel, there are really two choices:
>> 1. that each satellite know about all the protected networks of all the gateways in the configuration, or
>> 2. that satellites send all traffic to the "core" or "hub" gateways. This includes clear traffic (as in HTTP to facebook.com). This increased the load even more.
>>
>> If you don't want #2, then the satellite still needs to know about every IP address whether it is protected by some gateway (and therefore needs to go in the tunnel), or not (and so packets with that destination should go out in the clear). Since the protected networks change, this requires that information to propagate throughout the network, and dynamic updates to SPD
>>
>> If we don't want a star topology, the gateways or endpoints still need to know what is or is not encrypted. They also need to either know about all peers, or be able to find the peer and (securely) learn how it should authenticate. Either way, without a star topology, you need dynamic updates to PAD.
>>
>> I think the draft should mention this.
>>
>> Yoav
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@...
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@...
https://www.ietf.org/mailman/listinfo/ipsec
One is where the satellite forwards *everything* to the hub, even some user behind the satellite checking their Facebook account. That kind of satellite really needs very little configuration.
The other is where the satellite forwards only traffic going to an address that is behind *some* satellite or hub gateway. This requires that it partition the Internet into a "protected" and a "non-protected" parts.
Stars vs Mesh is IMO important, because with stars you only need to propagate SPDs while with mesh you also need to propagate PADs. The mechanisms for propagating each kind of information may be different when the time comes to discuss solutions.
Yoav
On Mar 7, 2012, at 11:25 PM, Yaron Sheffer wrote:
> Hi Yoav, Steve,
>
> I'm not sure that this star-vs-mesh discussion is so important, because
> even if you choose the simplest star topology, data propagation is still
> required. Configuration of the satellites is simple: *everything* goes
> to the hub. But the hub needs to know which satellite to send each
> packet to, and as the satellites' configuration changes, the hub
> constantly needs to be reconfigured. So it's really the same problem in
> a more limited form.
>
> Thanks,
> Yaron
>
> On 03/07/2012 12:54 AM, Yoav Nir wrote:
>> Hi Steve
>>
>> On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote:
>>
>>> So please review this short document and send comments.
>>
>> While the draft does a good job of describing use cases, and certain inadequate solutions, I think it's missing a description of why this is hard.
>>
>> Even if we accept the solution of a star topology, where a satellite needs only have one single tunnel, there are really two choices:
>> 1. that each satellite know about all the protected networks of all the gateways in the configuration, or
>> 2. that satellites send all traffic to the "core" or "hub" gateways. This includes clear traffic (as in HTTP to facebook.com). This increased the load even more.
>>
>> If you don't want #2, then the satellite still needs to know about every IP address whether it is protected by some gateway (and therefore needs to go in the tunnel), or not (and so packets with that destination should go out in the clear). Since the protected networks change, this requires that information to propagate throughout the network, and dynamic updates to SPD
>>
>> If we don't want a star topology, the gateways or endpoints still need to know what is or is not encrypted. They also need to either know about all peers, or be able to find the peer and (securely) learn how it should authenticate. Either way, without a star topology, you need dynamic updates to PAD.
>>
>> I think the draft should mention this.
>>
>> Yoav
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@...
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@...
https://www.ietf.org/mailman/listinfo/ipsec
« Return to Thread: Please Comment on New P2P VPN Problem Statement
| Free embeddable forum powered by Nabble | Forum Help |
