At this stage, I would like to go back to the basics.
At least two vendors already provide NHRP/GRE/IPsec to address what seems to
relate to the peer discovery part of the problem statement. Cisco calls it
DMVPN and Juniper calls it ACVPN.
Based on your wording so far, everything I read you want seems actually already
covered in existing solutions (speaking for DMVPN in particular).
Can you please explain what does not suit you in these solutions ? How do these
not meet your requirements ? Understanding the gaps will save everyone a lot of
time.
I really would like you to cover the issues in terms that are NOT what you want
(which is too vague) but specifically how DMVPN do not suit you.
thanks,
fred
On 08 Nov 2011, at 18: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
>>
> _______________________________________________
> 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
>
> ****************************************************************************
> 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 postmas...@gchq.gsi.gov.uk.
>
> 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
> info...@gchq.gsi.gov.uk
>
> ****************************************************************************
>
>
> 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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
