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
