Praveen, NHRP as described in RFC2332 is sufficient to provide the needed functionality. I.e. two spokes finding information about each other via a hub (or hubs) so that they can then build a direct tunnel between them.
Thanks, Mike. >Hi Fred, > >Are there any proprietary messages exchanged between hub and spoke or >spoke to spoke? > >Thanks, >Praveen > >On 11/8/11 10:56 AM, "Frederic Detienne" <f...@cisco.com> wrote: > > >We (Cisco) have followed this thread with attention. A has been stated >earlier, we already have a solution that meets those requirements. The >solution harnesses > >RFC 2332 to resolve the protected network prefixes into gateway addresses >RFC 4306 / 5996 for IPsec peer-peer tunnel establishment >RFC 5280 for identification which allows filtering based on peer identity >using the structured identities in the certificates (among other things) > >The solution works across multiple hubs with a virtually limitless amount >of spokes. > > fred > >On 08 Nov 2011, at 02:44, Ulliott, Chris wrote: > >> In my use case, there may be multiple Hubs, each with their own spokes >>and each hub will (probably) by managed by different providers. Spokes >>from different hubs will need to communicate with each other, but policy >>will be needed to determine which spokes they are permitted to >>communicate with (_not_ specified by IP address though - but something >>more logical, such as organisation or function.... for example, Org A is >>willing to communicate with all spokes run by org B) >> >> Chris >> >> >> -----Original Message----- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >>Of Praveen Sathyanarayan >> Sent: Monday, November 07, 2011 5:10 PM >> To: bill manning; Geoffrey Huang >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs >>Problem >> >> There was offline discussion about P2P offered by Juniper Networks (we >> believe Cisco has similar approach, called DMVPN) SSG product line. I am >> forwarding this email to group. >> >> In nutshell: >> >> Site to site tunnel ----- >> P2P cut thru tunnel ***** >> >> >> +---------------- SPOKE 1 ---------Host1 >> | * >> | * >> HUB -----------+ * >> | * >> | * >> +---------------- SPOKE 2----------Host2 >> >> >> In this solution, HUB is the trust entity that all spoke establish static >> IPSec tunnel (either using Site to site tunnel or spoke establish dynamic >> remote access tunnel with hub). When tunnel is established, spoke will >> exchange registration information, that will include network this spoke >> protects (trust/corporate network), security suite information etc. Hub >> will collect all these information all spoke. >> >> When Host 1 (in spoke1) wants to talk to particular host, which resides >> in Host 2 (in spoke2), spoke 1 will contact Hub. Hub will do resolution >> and identifies spoke2 is the right gateway to contact and then provides >> PAD, SPD information about spoke2 to spoke 1. There on spoke 1 >> establishes tunnel directly with Spoke 2. >> >> More detail about this solution can be referred below. >> >> Thanks, >> Praveen >> >> >> On 10/10/11 11:17 PM, "Suresh Melam" <nmelam at juniper.net> wrote: >> >> >> It is good to see the requirements purely from the usage perspective. >> Praveen and I had discussions and we want to share the current solutions >> (Juniper SSG's ACVPN or Cisco DM-VPN) as they pertain to the problem we >> are trying to solve. >> >> The problem statement I really see as >> "dynamic-spoke-to-spoke-direct-secure-connectivity" >> >> Basically, with minimum amount of configuration, we need secure mesh >> connectivity on demand. The way to acheive this is by having spokes >> register their information to the hub they are connected to. >> >> To begin with, each spoke needs to have atleast one static IPsec >> configuration towards one hub (may or may not be nearest). Once the >> tunnel is established with the hub, over the secure channel, spoke >> registers its info with the hub. >> The info may contain items like, IKE-identity, the-subnets-it-is-serving, >> authentication-information-like-the-certificate-it-will-be-using etc., >> With this registration procedure, hub can maintain a database of different >> spokes and their respective information. >> >> Now once hub notices that two spokes are communicating with each other, >> via two different tunnels towards hub, hub can inform two spokes that they >> may as well try to acheive direct connectivity. This happens via a >> resolution mechanism, where hub *pushes* down the info about spoke1 to >> spoke2 and vice versa. As spokes are receiving this information via a >> secure channel, they treat hub as trusted source of information and >> relies on this information to negotiate a tunnel directly between >> themselves. Once the new dynamic tunnel is established, the traffic >> between two spokes gets re-routed smoothly to the new dynamic tunnel. >> While this resolution process and new negotiation are being carried out, >> the traffic would continue flow through tunnels towards the hub. >> >> The resolution mechanism can be either hub-initiated or spoke-initiated. >> In the latter case, spoke will request hub for the resolution information >> for every new connection and will receive the resolution information by >> means of a *pull* mechanism. >> >> With combination of this registration and resolution mechanisms, with >> minimal configuration in both hub and spokes, a complete mesh secure >> connectivity can be achieved. >> >> thanks, >> -suresh >> >> On 11/6/11 5:41 PM, "bill manning" <azurem...@gmail.com> wrote: >> >> i don;t think that DNSSEC (writ large) is inapplicable - but thats a >> deployment quibble. >> I like the idea of ad-hoc, peer based secure channels - but that sort >> of requires a trusted introducer. Unfortunately for me, I have to >> leave on tuesday. Please keep me posted >> on the nature and future of these discussions. >> >> /bill >> >> >> On 10/26/11, Geoffrey Huang <ghu...@juniper.net> wrote: >>> I have to agree with the recent comments about the inapplicability of >>> RFC 4322. I don't think that a DNNSEC infrastructure can be assumed, >>> particularly not in the deployments I have seen. >>> >>> I agree with Steve Hanna's comments about the need for ad-hoc >>> peer-to-peer >>> VPNs, bypassing a centralized hub. I also agree with Paul Hoffman's >>> comments about using an already-existing "trusted introducer." >>> >>> Finally, I will be in Taiwan, but specifically (only) to discuss this >>> topic. >>> I'm hoping that the date of Wednesday, November 16 is still good for the >>> bar BOF that some of us had previously discussed. >>> >>> -geoff >>> >> _______________________________________________ +------------------------------------------------+ | Mike Sullenberger; DSE | | m...@cisco.com .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
