With all due respect to Cisco, the larger problem we're trying to address, is in part the fact that DMVPN and ACVPN are vendor specific implementations. And the goal of the implementation we're seeking is *large scale* P2P VPNs.
In other words, VPNs that cannot, or better put, MUST not assume that all equipment is from a single vendor. And we're not talking about the order of 100, 500 or even necessarily 1,000 gateways or end points. Picture a hypothetical where a larger interest desires an IPsec VPN, in, say the airline industry. We're talking about several thousand aircraft from several manufacturers. All in motion, trying to communicate to the nearest local ground station. Said ground station is perhaps an ATC, which are run by the FAA (Cleveland Center, Potomac Approach, etc) of which there are also thousands globally. The aircraft are also communicating with airports, which are also typically regionally controlled (Washington Metro Area Airports Authority, Port Authority of NY/NJ, etc.). And each of those aircraft are also property of tens of global carriers. Each has its own IT infrastructure. Each can be said to have some marginal level of trust between them, but likely not on the same level. Each has VPN gateways that are representative, among the collective several 1,000 to even 10,000 from at least, oh say 14 different vendors. Explain to me how the earlier discussion of DNSSEC, or any other supposed, " but we already have a solution" addresses that type of "large-scale, P2P VPN". And please do so in a standards-based, non-proprietary way, that accommodates 10,000+ gateways, independent of vendors, and won't take me 10 years to configure. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: [email protected] e: [email protected] p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 202.318.2333 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Nov 14, 2011, at 10:43 PM, "Frederic Detienne" <[email protected]> wrote: > > 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: [email protected] [mailto:[email protected]] On Behalf Of >> Praveen Sathyanarayan >> Sent: Monday, November 07, 2011 5:10 PM >> To: bill manning; Geoffrey Huang >> Cc: [email protected] >> 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 protected]> 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 protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
