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

From: Yoav Nir <[email-masked]>
Date: Fri, 14 Oct 2011 07:23:31 +0200

Hi all

For years, one of the barriers to the adoption of IPsec was that
configuration didn't scale. With thousands of peers, the PAD and SPD would
become unwieldy, so even where IPsec was deployed it was often built in
hub-and-spoke configurations, not because policy demanded this, but
because it was more convenient to configure. Individual vendors have
incompatible solutions for this, but they only work with that vendor's
products, and within the same administrative domain.

In this draft, we are proposing that the IPsecME working group take on a
working item to first define the problem, and then offer solutions that
will make IPsec scale better and in an inter-operable way.

We plan to hold a side meeting in Taipei, and we welcome comments both
before and at that meeting.

Yoav

http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt
http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 13 Oct 2011 23:18:51 -0700 (PDT)

Sounds like TED:

http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html

  Dan.

On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 14 Oct 2011 08:35:14 +0200

A little. Also like GET-VPN and AC-VPN and Provider-1 (apologies to all
the vendors I've missed)

Those are some of the incompatible solutions by individual vendors.

Yoav

On 10/14/11 8:18 AM, "Dan Harkins" <[email-masked]> wrote:

>Scanned by Check Point Total Security Gateway.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Oct 2011 09:48:21 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> A little. Also like GET-VPN and AC-VPN and Provider-1
    Yoav> (apologies to all the vendors I've missed)

    Yoav> Those are some of the incompatible solutions by individual
    Yoav> vendors.

And RFC4322.

FreeSWAN has a number of local controls whereby one simply lists the
CIDRs that one wishes to be "secure or fail" vs ones that are "nice to
be secure".  Many people have implemented MESHs by distributing the
reverse DNS.

What it is missing in IKEv1 is a way to turn the host<->host tunnels
into subnet<->subnet tunnels, and that would be easy to do in IKEv2 with
the TS.

    >>> configuration didn't scale. With thousands of peers, the PAD and
    >>> SPD would become unwieldy, so even where IPsec was deployed it
    >>> was often built in hub-and-spoke configurations, not because
    >>> policy demanded this, but because it was more convenient to
    >>> configure. Individual vendors have incompatible solutions for
    >>> this, but they only work with that vendor's products, and within
    >>> the same administrative domain.
    >>> 
    >>> In this draft, we are proposing that the IPsecME working group
    >>> take on a working item to first define the problem, and then
    >>> offer solutions that will make IPsec scale better and in an
    >>> inter-operable way.
    >>> 
    >>> We plan to hold a side meeting in Taipei, and we welcome
    >>> comments both before and at that meeting.
    >>> 
    >>> Yoav
    >>> 
    >>> _______________________________________________ IPsec mailing
    >>> list [email-masked] https://www.ietf.org/mailman/listinfo/ipsec
    >>> 
    >> 
    >> 
    >> 

    Yoav> _______________________________________________ IPsec mailing
    Yoav> list [email-masked]
    Yoav> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Sun, 16 Oct 2011 21:02:56 +0200

I definitely think that the authors of this draft (I'm mostly just the
editor) need a good answer about why RFC 4322 doesn't cover the use cases.
Mostly, the starting point is different.

RFC 4322 begins with nodes that have no prior trust relationship, and
builds opportunistic bridges between them.

The problem here is that groups of nodes that have trust relationships
between them, but not between every pair of them. They want communications
that now go through some hub gateway to go directly from spoke to spoke.

---

From: "Ulliott, Chris" <[email-masked]>
Date: Mon, 17 Oct 2011 12:39:32 +0100

The challenge for us is around discovery of the next cryptographic hop combined with the increase use of VoIP and other protocols that need peer to peer connectivity / low latency etc.

If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway needs to perform a lookup to find out who it needs to establish an SA with before it can encrypt the packet and send it on its way.  To my knowledge, there is not standard way of discovering this (although I'll happily be corrected!)

For example... (and I hope the ASCII art works!)

Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2

(Where R is a router and Zx is a crypto)

Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, but at this point Za needs to work out which remote endpoint to establish an SA with.  In this case it's Zb - but the traditional way to achieve this is through static configuration which doesn't scale if you want to run fully meshed networks (we have thousands of nodes).  When Zb received the packet it decrypts and forwards to Host 2.

When you add resilience, this gets even more complicate, for example:

Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2
                        | --------> Zc --> R ------^

Packets for Host two can be sent via Zb or Zc, how does Za make that decision? In this example Zc is less hops away so would make more sense unless it wasn't available.

Our interest also throws in the problem of multiple administrative domains.  We have numerous sites, but IT is provisioned by differing integrators.  Any standard should (in our opinion) enable this to still work.  At the moment, commercial solutions for meshed VPN's assume that all the cryptographic devices are run by the same team.

I hope that helps!

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Sunday, October 16, 2011 8:03 PM
To: Michael Richardson; [email-masked]
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

****************************************************************************
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: Michael Richardson <[email-masked]>
Date: Mon, 17 Oct 2011 09:52:56 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> I definitely think that the authors of this draft (I'm mostly
    Yoav> just the editor) need a good answer about why RFC 4322 doesn't
    Yoav> cover the use cases.  Mostly, the starting point is different.

    Yoav> RFC 4322 begins with nodes that have no prior trust
    Yoav> relationship, and builds opportunistic bridges between them.

No precisely true.
4322 says that we trust the central IP address delegation authority
(IANA), and builds trust from there.  

    Yoav> The problem here is that groups of nodes that have trust
    Yoav> relationships between them, but not between every pair of
    Yoav> them. They want communications that now go through some hub
    Yoav> gateway to go directly from spoke to spoke.

So you can do this on a host<->host basis by implementing 4322, and then
pulling (being a secondary using stock tools and protocols) the reverse
zone from the hub (over your trusted link to the hub, or via
TSIG/SIG(0), or just be IP address trust). 

What is (in the form of running code) missing is a way to transform the
host<->host tunnels into subnet<->subnet tunnels.  In IKEv2 we have a
way to express the request now, what is missing is a way to express the
authority statement.  If subnets are on octet boundaries (or smaller,
apply RFC2317), then it is pretty straightforward to search for
TXT/IPSECKEY for the subnet. 

For CIDR subnets, which we can express in IKEv2, one could just confirm
them all, but my bet is that there are no such networks that matter.

ps: by the time IPSECKEY (RFC4025) was assigned, rfc4322 was pretty much
    in the can, and we did not have deployed code to be able to test the
    IPSECKEY RR easily.   We decided that we would use the existence of
    IPSECKEY as a clue that we should try IKEv2 first.  Openswan did
    not get an IKEv2 implementation until early 2008 though.

    What this means is that an RFC4322bis could properly specify
    semantics for IPSECKEY RR, and if they were a bit different than the
    semantics in 4322 for the TXT RR, that would be okay.

===

    >> And RFC4322.
    >> 
    >> FreeSWAN has a number of local controls whereby one simply lists
    >> the CIDRs that one wishes to be "secure or fail" vs ones that are
    >> "nice to be secure".  Many people have implemented MESHs by
    >> distributing the reverse DNS.
    >> 
    >> What it is missing in IKEv1 is a way to turn the host<->host
    >> tunnels into subnet<->subnet tunnels, and that would be easy to
    >> do in IKEv2 with the TS.
    >> 
    >> 
    >> >> Sounds like TED:
    >> >> 
    >> >> 
    >> >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: >>> Hi all
    >> >>> 
    >> >>> For years, one of the barriers to the adoption of IPsec was
    >> that >>> configuration didn't scale. With thousands of peers, the
    >> PAD and >>> SPD would become unwieldy, so even where IPsec was
    >> deployed it >>> was often built in hub-and-spoke configurations,
    >> not because >>> policy demanded this, but because it was more
    >> convenient to >>> configure. Individual vendors have incompatible
    >> solutions for >>> this, but they only work with that vendor's
    >> products, and within >>> the same administrative domain.
    >> >>> 
    >> >>> In this draft, we are proposing that the IPsecME working
    >> group >>> take on a working item to first define the problem, and
    >> then >>> offer solutions that will make IPsec scale better and in
    >> an >>> inter-operable way.
    >> >>> 
    >> >>> We plan to hold a side meeting in Taipei, and we welcome >>>
    >> >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt >>>
    >> >>> list [email-masked]

---

From: "Ulliott, Chris" <[email-masked]>
Date: Thu, 20 Oct 2011 09:27:35 +0100

The main problem I have is that RFC 4322 makes two assumptions that don't always hold true in practical deployments.

Firstly, it assumes that a gateway or endpoint is able to configure entries in the secured DNS.  For example, if I have an endpoint that is connected to a hotel wifi, I probably can't modify the reverse DNS to deploy my public keys or publish my gateway address.  This also applies when you have mobile sites that may be using multiple bearers of opportunity such as SatCom / 3G etc.

The second assumption is that I can secure the DNSSec deployment to the same level of trust, as I have in the network behind my IPSec device... again, this may not always be true.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, October 17, 2011 2:53 PM
To: [email-masked]
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

No precisely true.

===

---

From: Yoav Nir <[email-masked]>
Date: Sun, 23 Oct 2011 23:37:07 +0200

Hi Chris

As I've asked you off-list, I'm still trying to understand the initial
condition.

It's one thing if Za believes that "host 2" is behind *some* gateway, and
it's only a matter of finding out which gateway that is.

It's a different thing if "host 2" might also be not behind any gateway at
all. In that case policy should either say that the packet should be
dropped, or it should say that the packet should be forwarded unencrypted
(BYPASS in RFC 4301 language).

There is a subset of the Internet where Za can encrypt traffic. Is Za
pre-configured with that subset?

Yoav

On 10/17/11 1:39 PM, "Ulliott, Chris" <[email-masked]>
wrote:

>The challenge for us is around discovery of the next cryptographic hop
>combined with the increase use of VoIP and other protocols that need peer
>to peer connectivity / low latency etc.
>
>If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway
>needs to perform a lookup to find out who it needs to establish an SA
>with before it can encrypt the packet and send it on its way.  To my
>knowledge, there is not standard way of discovering this (although I'll
>happily be corrected!)
>
>Host 1 send a packet to Host 2, it's routed to the gateway Za as normal,
>but at this point Za needs to work out which remote endpoint to establish
>an SA with.  In this case it's Zb - but the traditional way to achieve
>this is through static configuration which doesn't scale if you want to
>run fully meshed networks (we have thousands of nodes).  When Zb received
>the packet it decrypts and forwards to Host 2.
>
>Packets for Host two can be sent via Zb or Zc, how does Za make that
>decision? In this example Zc is less hops away so would make more sense
>unless it wasn't available.
>
>Our interest also throws in the problem of multiple administrative
>domains.  We have numerous sites, but IT is provisioned by differing
>integrators.  Any standard should (in our opinion) enable this to still
>work.  At the moment, commercial solutions for meshed VPN's assume that
>all the cryptographic devices are run by the same team.
>
>I hope that helps!
>
>Chris

---

From: "Ulliott, Chris" <[email-masked]>
Date: Mon, 24 Oct 2011 12:52:49 +0100

Yoav... the answer is either! Za needs to pass a packet to Host 2, it may be between a gateway, may be running IPSec itself, or may be unable to receive encrypted packets at all.  As with RFC 4322, you would need a policy to determine behaviour when an encrypted channel can't be achieved, but the solution needs to enable Za to discover if there are available cryptographic routes, then make decisions based on the results combined with a policy.

I hope that helps!

Chris

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]]
Sent: Sunday, October 23, 2011 10:37 PM
To: Ulliott, Chris; Michael Richardson; [email-masked]
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Hi Chris

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Oct 2011 14:16:50 +0200

It does.

But then, both I and MCR agree that RFC 4322 in its present form is not
the answer, but a second edition (as in "rfc4322bis") might be.

Do you think a discovery process based on DNS could be acceptable? I have
never registered a domain, but I know how one could publish records for an
FQDN. I have no idea how I (or an administrator) could get to add records
to the reverse registry. RFC 4322 acknowledges this, and suggests an
alternative - add the records to the FQDN of the host. But in general
networking, we don't have FQDNs for hosts.

Anyway, we seem to be doing the engineer thing of jumping right to the
solution. We're currently at the problem statement phase.

MCR: are you going to be in Taipei?

Yoav

On 10/24/11 1:52 PM, "Ulliott, Chris" <[email-masked]>
wrote:

>Yoav... the answer is either! Za needs to pass a packet to Host 2, it may
>be between a gateway, may be running IPSec itself, or may be unable to
>receive encrypted packets at all.  As with RFC 4322, you would need a
>policy to determine behaviour when an encrypted channel can't be
>achieved, but the solution needs to enable Za to discover if there are
>available cryptographic routes, then make decisions based on the results
>combined with a policy.
>
>I hope that helps!
>
>Chris
>
>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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Oct 2011 10:00:34 -0400

I was not intending to be, (I have no ticket as yet), but plans might change.
It seems like Chris has all of the requirements of OE, and there is all
of the challenges.  IPv6 and homenet might well provide FDQNs for hosts,
and a trusted path to update the reverse.

If DNS does not work for you, then you need another trusted introducer,
and there have been many proposals out there for doing this kind of
thing.  None of taken off and hit the elbow of exponential growth.

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> It does.

    Yoav> But then, both I and MCR agree that RFC 4322 in its present form is not
    Yoav> the answer, but a second edition (as in "rfc4322bis") might be.

    Yoav> Do you think a discovery process based on DNS could be acceptable? I have
    Yoav> never registered a domain, but I know how one could publish records for an
    Yoav> FQDN. I have no idea how I (or an administrator) could get to add records
    Yoav> to the reverse registry. RFC 4322 acknowledges this, and suggests an
    Yoav> alternative - add the records to the FQDN of the host. But in general
    Yoav> networking, we don't have FQDNs for hosts.

    Yoav> Anyway, we seem to be doing the engineer thing of jumping right to the
    Yoav> solution. We're currently at the problem statement phase.

    Yoav> MCR: are you going to be in Taipei?

    Yoav> Yoav

    >> -----Original Message-----
    Yoav> From: Yoav Nir [mailto:[email-masked]]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Oct 2011 10:39:34 +0200

Chris' case is a little different, because he is willing to do some work to establish trust between the two administrative domains, so it's not really opportunistic (although doing it with OE might be a solution)

So there could be some "hub gateway" that could do the introducing, perhaps over IPsec or IKE. 

On the one hand, if DNS works and everybody already has a DNS resolver, it may be better to use that than to invent a new mechanism. OTOH if I didn't like inventing new mechanisms, I wouldn't be participating in the IETF.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 24 October 2011 16:01
To: [email-masked]
Cc: Ulliott, Chris
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

I was not intending to be, (I have no ticket as yet), but plans might change.
It seems like Chris has all of the requirements of OE, and there is all of the challenges.  IPv6 and homenet might well provide FDQNs for hosts, and a trusted path to update the reverse.

If DNS does not work for you, then you need another trusted introducer, and there have been many proposals out there for doing this kind of thing.  None of taken off and hit the elbow of exponential growth.

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 26 Oct 2011 10:00:05 -0400

I'm concerned about using DNS as the introducer here. Doing this
securely requires DNS records to be updated, signed, and distributed
whenever a new "satellite" gateway or host arrives or departs.
That's cumbersome, expensive, and complex since it requires
interfacing the IPsec and DNSSEC infrastructure and lots of
resigning.

The core IPsec gateway already knows all the information necessary
to establish a secure direct connection between satellites and
there's already a secure connection between the core and the
satellites. Why not use that connection to distribute the information
directly from the core to the satellites?

Whatever technology is decided upon, my employer (Juniper Networks)
sees a need for dynamically established "peer-to-peer" VPNs and
supports efforts to create standards in this area and to get
widespread adoption of those standards.

Thanks,

Steve Hanna

> Sent: Tuesday, October 25, 2011 4:40 AM
> To: 'Michael Richardson'; [email-masked]
> Cc: Ulliott, Chris
> Chris' case is a little different, because he is willing to do some
> work to establish trust between the two administrative domains, so it's
> not really opportunistic (although doing it with OE might be a
> solution)
> 
> On the one hand, if DNS works and everybody already has a DNS resolver,
> it may be better to use that than to invent a new mechanism. OTOH if I
> didn't like inventing new mechanisms, I wouldn't be participating in
> the IETF.
> 
> 
> of the challenges.  IPv6 and homenet might well provide FDQNs for
> hosts, and a trusted path to update the reverse.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Oct 2011 07:40:35 -0700

> directly from the core to the satellites?

+1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. If there is already a trusted introducer here, use it. The use case for RFC 4322, opportunistic encryption (and thus no trusted introducer), is quite different than the one being proposed here.

--Paul Hoffman

---

From: Galina Pildush <[email-masked]>
Date: Wed, 26 Oct 2011 10:51:32 -0400

+ Definitely agree with Steve and Paul - the proposed draft proposes spoke-to-spoke direct tunnel establishment based on the information known to hub and all spokes. We've seen many service providers wanting this ability to scale painlessly and seamlessly. 

Galina Pildush

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, October 26, 2011 10:41 AM
To: IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Oct 2011 19:03:47 +0200

This goes back to my previous question.

What is this information that is "known to hub and all spokes" ?

If the spoke knows what addresses are behind each other spoke, then we lose the scalability - that's a lot of configuration up front.

If the spoke only knows the union of all addresses behind other spokes, it sounds more feasible, but I still would like to know how it's configured.

If it's only the hub that knows the union, then again, how was that configured?

If each spoke knows only its own addresses and informs the hub, how do we prevent the problem of a malicious spoke claiming Facebook's subnets?

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Galina Pildush
Sent: 26 October 2011 16:52
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Galina Pildush

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, October 26, 2011 10:41 AM
To: IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote:

> interfacing the IPsec and DNSSEC infrastructure and lots of resigning.
> 
> The core IPsec gateway already knows all the information necessary to 
> establish a secure direct connection between satellites and there's 
> already a secure connection between the core and the satellites. Why 
> not use that connection to distribute the information directly from 
> the core to the satellites?

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Oct 2011 21:39:42 +0200

There is a common use case where we don't worry about malicious spokes, 
i.e. where they are all trusted.

We do worry about misconfigured spokes, but that would most likely 
result in loss of connectivity, which I expect to be fixed in due time. 
Or it can be prevented by (static) configuration on the hub.

Thanks,
     Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Oct 2011 13:02:48 -0700

On Oct 26, 2011, at 12:39 PM, Yaron Sheffer wrote:

> There is a common use case where we don't worry about malicious spokes, i.e. where they are all trusted.

Exactly right. The fact that the hub trusts a spoke is all that a different spoke needs to know for many (most?) common cases.

Having said that, it would be great of the authors of the document could come up with some terminology to differentiate "spoke trust hub to introduce to other spokes directly" and "spoke trusts hub to introduce to other spokes, possibly through indirection through other hubs".

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Oct 2011 22:36:04 +0200

>Or it can be prevented by (static) configuration on the hub.

Malicious/misconfigured/compromised, it doesn't matter. One way or another
we have a spoke that is configured to protect the 69.171.0.0/16 subnet,
that includes all facebook.com servers.

If the hub learns the protected network of the spokes from the spokes,
then this information will propagate to the entire network. The
configuration is easy, because each protected network needs to be
configured in one place only, but we have the security problem. Maybe the
use of sidr resource certificates could mitigate this, but I don't think
they're in wide use yet.

On the other hand, we could have all the protected networks of the spokes
statically configured on the hub, as you suggest. Then it doesn't matter
if the spoke thinks it owns facebook, because none of the others will
agree. This has several implications:
 - Configuration is harder and error prone - spoke and hub must match
 - It introduces an asymmetry. IPsec is all about peers with separate but
matching configuration. In this scenario there is an all-knowing hub that
introduces the spokes to one another.

I'm not necessarily saying that the second scenario is bad, but it's not
as scalable as the first. I'd rather solve both, but solving just the
first may be a good first step.

---

From: "Ulliott, Chris" <[email-masked]>
Date: Fri, 28 Oct 2011 17:01:34 +0100

So the assumption I've always had is that a spoke knows two things:

1) a method to identify the next cryptographic hop
2) a method to determine if it's allowed to talk to a specific cryptographic hop once identified.

The second point could be solved through PKI and policy (although we need a standard way to apply this) and the first could be solved through numerous methods... the challenge is to find a standard way for all vendors are willing to implement :-)

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, October 26, 2011 6:04 PM
To: 'Galina Pildush'; Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Galina Pildush
Sent: 26 October 2011 16:52
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Galina Pildush

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, October 26, 2011 10:41 AM
To: IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Oct 2011 10:07:07 -0700

> The second point could be solved through PKI and policy (although we need a standard way to apply this) and the first could be solved through numerous methods... the challenge is to find a standard…

The first point needs to be a bit more specific: "a method to identify the next cryptographic hop towards a particular address range".

--Paul Hoffman