So the assumption I've always had is that a spoke knows two things: 1) a method to identify the next cryptographic hop 2) a method to determine if it's allowed to talk to a specific cryptographic hop once identified.
The second point could be solved through PKI and policy (although we need a standard way to apply this) and the first could be solved through numerous methods... the challenge is to find a standard way for all vendors are willing to implement :-) Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Yoav Nir Sent: Wednesday, October 26, 2011 6:04 PM To: 'Galina Pildush'; Paul Hoffman; IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement 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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************** Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify [email protected]. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491 ext 30306 (non-secure) or email [email protected] **************************************************************************** The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
