Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

From: Mike Sullenberger <[email-masked]>
Date: Thu, 10 Nov 2011 16:19:08 -0800 (PST)

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" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf
>>Of Praveen Sathyanarayan
>> Sent: Monday, November 07, 2011 5:10 PM
>> To: bill manning; Geoffrey Huang
>> Cc: [email-masked]
>> 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" <[email-masked]> 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 <[email-masked]> 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                         |
| [email-masked]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+