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
