There is a common use case where we don't worry about malicious spokes,
i.e. where they are all trusted.
We do worry about misconfigured spokes, but that would most likely
result in loss of connectivity, which I expect to be fixed in due time.
Or it can be prevented by (static) configuration on the hub.
Thanks,
Yaron
On 10/26/2011 07:03 PM, Yoav Nir wrote:
This goes back to my previous question.
What is this information that is "known to hub and all spokes" ?
If the spoke knows what addresses are behind each other spoke, then we lose the
scalability - that's a lot of configuration up front.
If the spoke only knows the union of all addresses behind other spokes, it
sounds more feasible, but I still would like to know how it's configured.
If it's only the hub that knows the union, then again, how was that configured?
If each spoke knows only its own addresses and informs the hub, how do we
prevent the problem of a malicious spoke claiming Facebook's subnets?
Yoav
-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Galina Pildush
Sent: 26 October 2011 16:52
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
+ Definitely agree with Steve and Paul - the proposed draft proposes
spoke-to-spoke direct tunnel establishment based on the information known to
hub and all spokes. We've seen many service providers wanting this ability to
scale painlessly and seamlessly.
Galina Pildush
-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul
Hoffman
Sent: Wednesday, October 26, 2011 10:41 AM
To: IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote:
I'm concerned about using DNS as the introducer here. Doing this
securely requires DNS records to be updated, signed, and distributed
whenever a new "satellite" gateway or host arrives or departs.
That's cumbersome, expensive, and complex since it requires
interfacing the IPsec and DNSSEC infrastructure and lots of resigning.
The core IPsec gateway already knows all the information necessary to
establish a secure direct connection between satellites and there's
already a secure connection between the core and the satellites. Why
not use that connection to distribute the information directly from
the core to the satellites?
+1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. If
there is already a trusted introducer here, use it. The use case for RFC 4322,
opportunistic encryption (and thus no trusted introducer), is quite different
than the one being proposed here.
--Paul Hoffman
_______________________________________________
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
Scanned by Check Point Total Security Gateway.
_______________________________________________
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
