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

From: Mark Boltz <[email-masked]>
Date: Tue, 1 Nov 2011 14:53:32 +0000

I agree with Paul H. that the term "encryption domain" is not really fully correct for this problem set and its scenarios. I also apologize for lurking for quite some time before chiming in. I'd also rather avoid marketing-related jargon of any given vendor.

Before I make further comment, let me state that I do agree there is an aspect of the large scale mesh VPN problem that is not covered by RFC 4322, and I don't think DNSSEC resolves matters. In other words, I do think there is a problem set for certain scenarios for which a solution is still needed. One that is vendor agnostic.

On Oct 29, 2011, at 3:34 PM, Yoav Nir wrote:

> OK. So DNSSEC is off the table.  At least for now.
> 
> At least with Chris's scenario, we can assume that there's an
> "administrative domain" that includes a "hub" and some "spokes". This
> "hub" has information about the addresses protected by each of the
> "spokes", so it makes sense that it will do the "introductions". (BTW: all
> the terms in quotes will need a proper definition in the draft).
> Alternatively, the "introductions" can be done by yet another node that's
> dedicated to these introductions.
> 
> So the administrator of this administrative domain may not need to
> configure a lot of tunnels, but he or she still needs to configure all of
> the encryption domain of all the spokes on the introduces, but at least
> that's only one place.

The concept of the trusted introducer and the hub with some knowledge of the architecture of the spokes is one part of the set. I think that there are use cases where a large scale mesh VPN would be desired between hosts that actually encompass more than this, however.

Were we to assume a basic hub-spoke, we come back to the way the problem has attempted to be addressed. But the issue was that we were trying to remove or negate the overhead added to the hub to coordinate introductions and/or facilitate the actual IPsec work, creating more tunnels, configuration mess, etc. Right? 

I'd like to see a way, without having to muck with a client configuration, for example, where the client may want to query multiple hubs. The mesh may be several layers of hub and spoke, and there may be different trust levels between them. This could be because there are networks that are handled by one or more of the gateways for redundancy (e.g., gateway bob isn't available, because of a natural disaster; go talk to gateway alice over there instead and she can get you connected to the spoke you seek. And said multi-hub/multi-spoke is not only useful for redundancy, but also for partner, customer, employee, etc. at different trust levels.

I've got to wrap up for the moment, but I will endeavor to flesh it out a bit more tonight.

Bottom line, I agree the vendors need a standard way to address the challenges as outlined in the draft and as discussed so far. Hopefully there will at least be consensus in Taipei to continue the exploration and refine the -00 draft. 

Mark Boltz, CISSP, CISA
Stonesoft Inc.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Nov 2011 18:36:16 +0200

On 11/1/11 4:53 PM, "Mark Boltz" <[email-masked]> wrote:

>I agree with Paul H. that the term "encryption domain" is not really
>fully correct for this problem set and its scenarios. I also apologize
>for lurking for quite some time before chiming in. I'd also rather avoid
>marketing-related jargon of any given vendor.

Having been working for the same vendor for 10 years, I've gotten used to
our marketing jargon. Anyway, I'd like to have some short term for "the
set of addresses that are behind a certain gateway", or "the set of
addresses that you can reach through a tunnel to gateway x". I'm used to
calling that "x's encryption domain", but I'm open to suggestions for a
new catchy term. 

>
>Before I make further comment, let me state that I do agree there is an
>aspect of the large scale mesh VPN problem that is not covered by RFC
>4322, and I don't think DNSSEC resolves matters. In other words, I do
>think there is a problem set for certain scenarios for which a solution
>is still needed. One that is vendor agnostic.

That is the original motivation. Some vendors have some way of doing this
as long as all gateways are from that vendor, but some government users
(represented by Chris Ulliot) are not willing to lock their entire
government infrastructure to a single vendor.

>The concept of the trusted introducer and the hub with some knowledge of
>the architecture of the spokes is one part of the set. I think that there
>are use cases where a large scale mesh VPN would be desired between hosts
>that actually encompass more than this, however.
>
>Were we to assume a basic hub-spoke, we come back to the way the problem
>has attempted to be addressed. But the issue was that we were trying to
>remove or negate the overhead added to the hub to coordinate
>introductions and/or facilitate the actual IPsec work, creating more
>tunnels, configuration mess, etc. Right?
>
>I'd like to see a way, without having to muck with a client
>configuration, for example, where the client may want to query multiple
>hubs. The mesh may be several layers of hub and spoke, and there may be
>different trust levels between them. This could be because there are
>networks that are handled by one or more of the gateways for redundancy
>(e.g., gateway bob isn't available, because of a natural disaster; go
>talk to gateway alice over there instead and she can get you connected to
>the spoke you seek. And said multi-hub/multi-spoke is not only useful for
>redundancy, but also for partner, customer, employee, etc. at different
>trust levels.
>
>Bottom line, I agree the vendors need a standard way to address the
>challenges as outlined in the draft and as discussed so far. Hopefully
>there will at least be consensus in Taipei to continue the exploration
>and refine the -00 draft.

Good. So will you be in Taipei and attend the side meeting?

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Nov 2011 13:49:52 -0400 (EDT)

> calling that "x's encryption domain", but I'm open to suggestions for a

freeswan/openswan uses leftsubnet/rightsubnet for that, where "left is the
left side of your diagram". In other words, your own arbitrary choice :)

You could use "local subnet" and "remote subnet"?

> government infrastructure to a single vendor.

Excellent! raw RSA should interop widely, and getting raw public keys
from DNSSEC is but one method to obtain these. They can be fetched from
other sources (secured LDAP, TLS, etc). It would be good to stick to
one representation though so everyone can implement their own key
retrieval method. Similar to how people are now talking about dnssec-chains,
one could piggyback there and define an updated representation for raw
keys from RFC-4025

Paul

---

From: Keith Welter <[email-masked]>
Date: Tue, 1 Nov 2011 10:51:32 -0700

> calling that "x's encryption domain", but I'm open to suggestions for a
Some ideas:
1) "IPsec protected destinations" 
2) "IPsec protection domain"

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Nov 2011 22:46:55 +0200

>You could use "local subnet" and "remote subnet"?

It's not necessarily a single subnet. It could be an entire corporate LAN
with multiple subnets.

>one could piggyback there and define an updated representation for raw

Raw RSA keys work. If there is an introducer that tells both sides about
each other, a shared secret also works. Shared secrets are very secure if
you generate them randomly.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Nov 2011 16:56:26 -0400 (EDT)

> It's not necessarily a single subnet. It could be an entire corporate LAN

Adding an "s" was left as an exercise for the reader?

> you generate them randomly.

PSK's have problems when trying to distisnguish multiple road warriors with
different PSKs using Main Mode in IKEv1. You also cannot advertise them in
DNS or elsewhere for large scale no-configuration deployments :P

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Nov 2011 22:51:57 +0200

On 11/1/11 7:51 PM, "Keith Welter" <[email-masked]> wrote:

>> our marketing jargon. Anyway, I'd like to have some short term for the

I like having the verb "protect" there because it echos the processing
choice from RFC 4301. If nobody objects, I'll use "protected domain" in
the next iteration of the draft.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 2 Nov 2011 09:04:08 -0700 (PDT)

Hello,

On Tue, November 1, 2011 1:56 pm, Paul Wouters wrote:
>> each other, a shared secret also works. Shared secrets are very secure
>> if you generate them randomly.
>
> PSK's have problems when trying to distisnguish multiple road warriors
> with different PSKs using Main Mode in IKEv1.

  That problem is being addressed:

      http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-auth-05

  regards,

  Dan.