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

From: bill manning <[email-masked]>
Date: Sun, 6 Nov 2011 20:41:36 -0500

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
>

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 7 Nov 2011 09:09:38 -0800

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:

/bill

> bar BOF that some of us had previously discussed.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Ko <[email-masked]>
Date: Tue, 08 Nov 2011 02:19:09 +0800

Please take a look at my draft titled "Problem Statement for Dynamic Secure 
Interconnect" which can be found at 
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00  It advocates 
the "dynamic-spoke-to-spoke-direct-secure-connectivity" as mentioned by 
Suresh Melam.

Mike

----- Original Message ----- 
From: Praveen Sathyanarayan
To: bill manning ; Geoffrey Huang
Cc: [email-masked]
Sent: Tuesday, November 08, 2011 1:09 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

In nutshell:

Thanks,
Praveen

thanks,
-suresh

/bill

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Nov 2011 14:44:00 -0500

>>>>> "Praveen" == Praveen Sathyanarayan <[email-masked]> writes:
    Praveen> In this solution, HUB is the trust entity that all spoke
    Praveen> establish static IPSec tunnel (either using Site to site
    Praveen> tunnel or spoke establish dynamic remote access tunnel with
    Praveen> hub). When tunnel is established, spoke will exchange

So... you have a trusted third party: DNS server on HUB.
If you talk to it over IPsec, you are as secure as DNSSEC, but you have
perhaps less resiliancy.

YOU DO NOT NEED GLOBAL DNSSEC.
This will be the last time I say this.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Nov 2011 22:07:26 +0200

>If you talk to it over IPsec, you are as secure as DNSSEC, but you have

I don't see how DNS figures into this.  We have three gateways:
 - hub-gw, which knows the protected domains of everyone
 - spoke32, which protects 192.168.32.0/24, knows about hub-gw, and sends
all 192.168.0.0/16 to hub-gw.
 - spoke79, which protects 192.168.79.0/24, knows about hub-gw, and sends
all 192.168.0.0/16 to hub-gw

Host 192.168.79.5 sends a packet to 192.168.32.8. Spoke79 tries to create
a child SA with hub-gw. Hub-gw tells spoke79 that that address can be
reached through a gateway that will present a certificate with CN=spoke32
and protect 192.168.32.0/24. A similar message is sent to spoke32 about
spoke79. Or maybe it generates a shared secret for them.

Either way, spoke32 and spoke79 can then communicate directly. And no DNS.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Nov 2011 15:19:04 -0500

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> I don't see how DNS figures into this.  We have three
    Yoav> gateways: - hub-gw, which knows the protected domains of
    Yoav> everyone - spoke32, which protects 192.168.32.0/24, knows
    Yoav> about hub-gw, and sends all 192.168.0.0/16 to hub-gw.  -
    Yoav> spoke79, which protects 192.168.79.0/24, knows about hub-gw,
    Yoav> and sends all 192.168.0.0/16 to hub-gw

Yes. And, how is this policy communicated?

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Nov 2011 22:32:05 +0200

>Yes. And, how is this policy communicated?

Over IKE?

Using a new protocol that we'll invent?

SOAP?

As an attribute in a certificate, kind of like SIDR?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Nov 2011 16:46:21 -0500

>> Yes. And, how is this policy communicated?

    Yoav> Over IKE?

    Yoav> Using a new protocol that we'll invent?

    Yoav> SOAP?

    Yoav> As an attribute in a certificate, kind of like SIDR?

So, okay, so you want to do new work to replace work that's already been
well defined, that uses DNS as the transport.

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 7 Nov 2011 13:47:26 -0800

Yes. Communicated over IKE.

-- Praveen

On 11/7/11 12:32 PM, "Yoav Nir" <[email-masked]> wrote:

Over IKE?

SOAP?

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Nov 2011 23:58:25 +0200

>well defined, that uses DNS as the transport.

Hey, that's what engineers do.

But more seriously, in my example hub-gw responds to spoke79 with the
configuration of spoke32, and initiates a message to spoke32 about
spoke79. I'm no expert on DNS, but I think there is no "push mode" of DNS,
so hub-gw acting as DNS server would not be able to tell spoke32 what it
needs to do. Sure, you can make them all DNS servers (fits with the peer
to peer concept of IKE), and start zone transfers with hub-gw acting once
as client and once as server.

But I agree with Praveen. We have one IKE peer telling another IKE peer
about a third IKE peer, where IKE SAs already exist between them. IKE
seems like a natural protocol for this configuration information. Some may
object that IKE is meant for key exchange, not for configuration, and
would prefer something over IPsec, but I don't think that DNS really fits
this.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 07 Nov 2011 14:22:00 -0900

> well defined, that uses DNS as the transport.

Could always use SIP, and relegate DNS to discovery: 
http://www.cs.cornell.edu/people/francis/sigcomm07-nutss-final.pdf

[I *kid*]

Melinda

---

From: "Ulliott, Chris" <[email-masked]>
Date: Tue, 8 Nov 2011 10:44:03 +0000

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

In nutshell:

Thanks,
Praveen

thanks,
-suresh

/bill

****************************************************************************
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-masked].  

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-masked]

****************************************************************************

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.

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 8 Nov 2011 07:18:16 -0800

Is there a mechanism in DNS to communicate this kind of policy?  As I understand the example below, the communication from hub-gw to spoke32 would be something like: "to get to 192.168.79.0/24, go to spoke79."

-geoff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 07, 2011 10:46 PM
To: Yoav Nir
Cc: [email-masked]; Geoffrey Huang; bill manning; Praveen Sathyanarayan
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

    Yoav> Over IKE?

    Yoav> SOAP?

So, okay, so you want to do new work to replace work that's already been well defined, that uses DNS as the transport.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Nov 2011 17:23:16 +0200

There isn't now, but adding stuff to the DNS is all the rage now that
DNSSEC, ummm, exists.  Just take a look at DANE.

On 11/8/11 5:18 PM, "Geoffrey Huang" <[email-masked]> wrote:

>Is there a mechanism in DNS to communicate this kind of policy?  As I
>understand the example below, the communication from hub-gw to spoke32
>would be something like: "to get to 192.168.79.0/24, go to spoke79."
>
>-geoff
>

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 8 Nov 2011 07:24:14 -0800

Yes - so if something has to be added to DNS, then how would this be better or more preferable than adding an extension to IKE?

-geoff

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2011 4:23 PM
To: Geoffrey Huang; [email-masked]
Cc: [email-masked]; bill manning; Praveen Sathyanarayan
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

There isn't now, but adding stuff to the DNS is all the rage now that DNSSEC, ummm, exists.  Just take a look at DANE.

On 11/8/11 5:18 PM, "Geoffrey Huang" <[email-masked]> wrote:

>So, okay, so you want to do new work to replace work that's already 
>been well defined, that uses DNS as the transport.

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 8 Nov 2011 09:25:57 -0800

Will spoke having part of different hub will solve?

Sure there could be overlapping addresses, which could be solved by having
routing instance (Virtual router/VR). Since HUB as all the information,
hub can decide which spokes can talk to each other (as in below solution
hub is the one initiates pushing PAD/SPD to spokes to initiates tunnel
between them). 

-- Praveen

On 11/8/11 2:44 AM, "Ulliott, Chris" <[email-masked]> 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

In nutshell:

Thanks,
Praveen

thanks,
-suresh

/bill

***************************************************************************
*

***************************************************************************
*

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.

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 8 Nov 2011 10:09:39 -0800

>> Will spoke having part of different hub will solve?

I mean, having spoke part of multiple hubs (belonging to different admin
domains) may solve Chris scenario. With multiple hubs, there may be
scenario of overlapping addresses, which can be addressed making each hub
configuration, in spoke, in different Virtual router.

-- Praveen

On 11/8/11 9:25 AM, "Praveen Sathyanarayan" <[email-masked]> wrote:

-- Praveen

Chris

-----Original Message-----

In nutshell:

Thanks,
Praveen

thanks,
-suresh

/bill

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 8 Nov 2011 10:56:53 -0800

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Nov 2011 15:02:31 -0500

>>>>> "Geoffrey" == Geoffrey Huang <[email-masked]> writes:
    Geoffrey> Is there a mechanism in DNS to communicate this kind of
    Geoffrey> policy?  As I understand the example below, the
    Geoffrey> communication from hub-gw to spoke32 would be something
    Geoffrey> like: "to get to 192.168.79.0/24, go to spoke79."

RFC4025.

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 8 Nov 2011 11:59:12 -0800

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
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 08 Nov 2011 11:06:53 -0900

On 11/08/2011 11:02 AM, Michael Richardson wrote:
>>>>>> "Geoffrey" == Geoffrey Huang<[email-masked]>  writes:

I was being a bit sarcastic with the NuTSS reference yesterday
but this looks an awful lot like a telephony routing problem.
There's been work done on both routing (see, for example,
RFC 3219, which appears to have tanked in the marketplace but
may or may not be relevant) and on rendezvous protocols (lots
of stuff in p2p-land, some work on SIP, etc.).

That is to say, there's some prior art on the routing/discovery
side that may be relevant.

Melinda

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Nov 2011 15:29:24 -0500

RFC2332: NBMA Next Hop Resolution Protocol (NHRP)

I think that it is a much better thing to use something like this, than
invent something new.

---

From: Galina Pildush <[email-masked]>
Date: Tue, 8 Nov 2011 20:18:59 -0500

NHRP is a protocol that is used to discover the shortest path through an NBMA cloud.It does not, however, "speak" IPSec ...

Galina

---

From: Melinda Shore <[email-masked]>
Date: Tue, 08 Nov 2011 16:30:00 -0900

On 11/08/2011 04:18 PM, Galina Pildush wrote:
> NHRP is a protocol that is used to discover the shortest path
 > through an NBMA cloud.It does not, however, "speak" IPSec ...

I don't believe that Michael was suggesting that there's a
complete solution here, just that there's prior work on
routing, rendezvous, etc.  I don't think that I'd choose
an NHRP-ish model for this sort of thing but I think it's
worth looking at.

There are several component problems.  I see them as:

1) discovery of "hubs",
2) routing (may or may not be folded into
    discovery), and
3) tunnel establishment

How you're going to break stuff down yourself depends on
the mental model you've got of the entire process, which is
probably varying quite a bit from person to person at this
point.

Melinda

---

From: Frederic Detienne <[email-masked]>
Date: Fri, 11 Nov 2011 08:58:50 -0800

NHRP is a generic protocol that converts overlay addresses in any address family into transport addresses in any address family. The protocol works over NBMA meaning that it can work over virtually anything (i.e. no exuberant requirements).

There is a clean layer separation and NHRP does not need to "speak" IPsec as you say (whatever that means).

	fred

---

From: Galina Pildush <[email-masked]>
Date: Fri, 11 Nov 2011 12:51:48 -0500

Sure, Fred, to do what it suppose to do - it works fine. It was/is especially very useful over ATM and other NBMA clouds. The question here is - what is it we are trying to do? 

Galina

-----Original Message-----
From: Frederic Detienne [mailto:[email-masked]] 
Sent: Friday, November 11, 2011 11:59 AM
To: Galina Pildush
Cc: Michael Richardson; [email-masked]
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

	fred

---

From: Mike Sullenberger <[email-masked]>
Date: Fri, 11 Nov 2011 16:50:47 -0800 (PST)

In this case we are effectively building an NBMA tunnel cloud. I.e. A bunch of
spoke nodes connected to one or more interconnected hubs.  Using NHRP to find
end-points in order to build the cross tunnels makes sense.  Once you have used
NHRP to find the endpoint then you can use IKE/IPsec to protect/encrypt the
tunnel.  This leaves IKE/IPsec the clear roll of protecting the tunnels (data)
without having to complicate it with a mechanism to find end-points.  You get a
clean separation of roles and layers.

Mike.

> Sure, Fred, to do what it suppose to do - it works fine. It was/is especially
> very useful over ATM and other NBMA clouds. The question here is - what is it we
> are trying to do?

> NHRP is a generic protocol that converts overlay addresses in any address
> family into transport addresses in any address family. The protocol works over
> NBMA meaning that it can work over virtually anything (i.e. no exuberant
> requirements).

> >
> >
> > NHRP is a protocol that is used to discover the shortest path through an
> > NBMA cloud. It does not, however, "speak" IPSec ...
> > 
> > Galina 
> >
> >  Michael Richardson

+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [email-masked]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+

---

From: Paul Wouters <[email-masked]>
Date: Sat, 12 Nov 2011 13:58:10 -0500 (EST)

> Yes - so if something has to be added to DNS, then how would this be better or more preferable than adding an extension to IKE?

DNS would act as a bootstrap to find the IKE daemon for a particular target(s). Everything else
should indeed remain within the IKE daemon.

That is exactly what RFC 4025 does.

Paul

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 15 Nov 2011 11:42:42 +0800

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

---

From: Mark Boltz <[email-masked]>
Date: Tue, 15 Nov 2011 04:29:51 +0000

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-masked]   e: [email-masked] 
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.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 06:47:46 +0200

Hi Mark

I see that you're not at the IETF. Will you be following the meeting through Jabber and (hopefully) audio?

Anyway, GRE and NHRP are standardized protocols that could be used as part of a large scale solution. I don't (personally) believe that they are as scalable as other solutions we might propose, but they should not be dismissed. Regardless of their optimality, they do not cover some of the requirements:
 - to find out what is accessible through VPN as opposed to not through VPN
 - to provision credentials for authentication between two IKE hosts

And once we go to a large-scale scenario like you describe with multiple administrative domains, you have to deal with the trust issue, and that's a big one. The current IKE and IPsec RFCs do not deal with cross-domain trust.

Yoav

On Nov 15, 2011, at 12:29 PM, Mark Boltz wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 09:52:24 -0500

>>>>> "Mark" == Mark Boltz <[email-masked]> writes:
    Mark> With all due respect to Cisco, the larger problem we're trying
    Mark> to address, is in part the fact that DMVPN and ACVPN are
    Mark> vendor specific implementations. And the goal of the
    Mark> implementation we're seeking is *large scale* P2P VPNs.  

Assume that they are available on a wide variety of platforms, what is
broken in the technology?

    Mark> Picture a hypothetical where a larger interest desires an
    Mark> IPsec VPN, in, say the airline industry. We're talking about
    Mark> several thousand aircraft from several manufacturers. All in

We've been through all of this 15 years ago with AIAG's ANX.

    Mark> Explain to me how the earlier discussion of DNSSEC, or any
    Mark> other supposed, " but we already have a solution" addresses
    Mark> that type of "large-scale, P2P VPN". And please do so in a
    Mark> standards-based, non-proprietary way, that accommodates
    Mark> 10,000+ gateways, independent of vendors, and won't take me 10
    Mark> years to configure.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 17:26:50 +0200

> broken in the technology?

I don't know, but I've been told
that ACVPN and DMVPN both rely on NHRP and GRE tunnels. I have also heard (and please someone correct me if I'm wrong) that they don't interoperate. So the tools are apparently not enough.

> We've been through all of this 15 years ago with AIAG's ANX.

You really want to tout that experience as a success story?

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 15 Nov 2011 09:57:06 -0800

Couple of clarification here. Juniper implementation of AC-VPN does not do
GRE over IPSec. It is IPSec alone for implementation (Route based VPN).
Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN
there are proprietary messages. It uses standard messages, but has many
proprietary payloads. We believe NHRP is *necessary* but not *sufficient*.
Also the way Hub download PAD/SPD to spokes (so that they can talk to each
other directly) is not standard.

We believe, there is a requirement for standard so that we can interop
with other vendors.

-- Praveen

On 11/15/11 7:26 AM, "Yoav Nir" <[email-masked]> wrote:

I don't know, but I've been told
that ACVPN and DMVPN both rely on NHRP and GRE tunnels. I have also heard
(and please someone correct me if I'm wrong) that they don't interoperate.
So the tools are apparently not enough.

---

From: Frederic Detienne <[email-masked]>
Date: Wed, 16 Nov 2011 07:09:55 +0800

> other directly) is not standard.

thank you for clarifying!

> We believe, there is a requirement for standard so that we can interop

I think I can agree with that.

	fred

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Nov 2011 18:43:00 -0500 (EST)

> We believe, there is a requirement for standard so that we can interop

Please, so we can kill off nonsense like this:

https://gsoc.xelerance.com/projects/openswan/wiki/Juniper_NAT-IPsec_hack_workaround

Whoever designed an IPsec system that violates its own negotiated policies was
on something very illegal.

Paul