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

From: Geoffrey Huang <[email-masked]>
Date: Wed, 26 Oct 2011 13:19:06 -0700

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: Yoav Nir <[email-masked]>
Date: Fri, 28 Oct 2011 16:00:06 +0200

Well, there is a free room between 1300-1500 on Wednesday, but then we're opposite WebSec, and I can't attend.

Our best bet is to do it after the Plenary. The plenary ends at 19:30, and people might want to grab something to eat, so it would probably be best to do it at 20:00.

Hope you don't have a flight for Wednesday night…

On 10/26/11 10:19 PM, "Geoffrey Huang" <[email-masked]<mailto:[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: Stephen Hanna <[email-masked]>
Date: Fri, 28 Oct 2011 18:09:27 -0400

I agree. Wednesday night would be best.

Who else is interested in getting together to discuss this? Clearly, there are plenty of interesting issues to discuss.

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Friday, October 28, 2011 10:00 AM
To: Geoffrey Huang; Stephen Hanna
Cc: [email-masked]
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

Hope you don't have a flight for Wednesday night...

-geoff

---

From: Mike Irani <[email-masked]>
Date: Fri, 28 Oct 2011 16:00:30 -0700

I am definitely interested in attending. Weds night works here.

On 10/28/2011 3:09 PM, Stephen Hanna wrote:
> Who else is interested in getting together to discuss this? Clearly, 
> there are plenty of interesting issues to discuss.
>
> Steve
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Yoav Nir
> *Sent:* Friday, October 28, 2011 10:00 AM
> *To:* Geoffrey Huang; Stephen Hanna
> *Cc:* [email-masked]
> *Subject:* Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 
> Problem
>
> Well, there is a free room between 1300-1500 on Wednesday, but then 
> we're opposite WebSec, and I can't attend.
>
> Our best bet is to do it after the Plenary. The plenary ends at 19:30, 
> and people might want to grab something to eat, so it would probably 
> be best to do it at 20:00.
>
> On 10/26/11 10:19 PM, "Geoffrey Huang" <[email-masked] 
> <blockedmailto:[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
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Jorge Coronel <[email-masked]>
Date: Sat, 29 Oct 2011 09:16:37 -0700

+1 

I agree DNSSEC cannot be assumed, its deployments have been marginal. 

I also agree with the need of an ad-hoc peer-to-peer VPN bypassing gateways.
While there are implementations from multiple vendors, including the one I
work for, there is no standardized/scalable solution for  the problems
associated with these scenarios. Key challenges are:

-          Discoverability of  suitable peers 

-          Discovery of the set of crypto contracts required if allowed 

I won't be able to attend the IETF meeting in Taiwan, however once the date
and time is settled I'll coordinate with someone representing my company to
attend the BOF meeting.

Thanks

Jorge Coronel

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Geoffrey Huang
Sent: Wednesday, October 26, 2011 1:19 PM
To: [email-masked]
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

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: Yoav Nir <[email-masked]>
Date: Sat, 29 Oct 2011 22:34:58 +0200

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.

What is a "crypto contract"?

Also, my company calls the addresses protected by a particular IPsec node
an "encryption domain". Can we use this term, or is it too vendor-specific?

Yoav

On 10/29/11 6:16 PM, "Jorge Coronel" <[email-masked]> wrote:

>I also agree with the need of an ad-hoc peer-to-peer VPN bypassing
>gateways. While there are implementations from multiple vendors,
>including the one I work for, there is no standardized/scalable solution
>for  the problems associated with these scenarios. Key challenges are:
>I won¹t be able to attend the IETF meeting in Taiwan, however once the
>date and time is settled I¹ll coordinate with someone representing my
>company to attend the BOF meeting.
> 
>Thanks
>Jorge Coronel
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Oct 2011 18:24:52 -0700

> What is a "crypto contract"?

I think a better term is "tunnel crypto policy". It's not a contract at all: the "contract" part comes when SpokeA and SpokeB complete the handshake.

> an "encryption domain". Can we use this term, or is it too vendor-specific?

Regardless if that is vendor specific, it is not accurate. Part of the tunnel crypto policy is the authentication policy, which has nothing to do with encryption. Further, part of the tunnel crypto policy is the addresses that will be in the tunnel. I assume if SpokeA says to HubX "I want to open a tunnel to 5.6.7.0/24", and the only address policy that SpokeA has that matches that is for 5.0.0.0/8 with the gateway at 5.1.2.3, that HubX would respond with that as a possibility that SpokeA might like. So there are two types of policy: tunnel (address), and crypto (authentication and eventual encryption).

At least, that was my picture of the requirements.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Oct 2011 09:30:18 -0400

>>>>> "Jorge" == Jorge Coronel <[email-masked]> writes:
    Jorge> +1

    Jorge> I agree DNSSEC cannot be assumed, its deployments have been
    Jorge> marginal.

DNSSEC is *one* *public* trusted third party.  It's not the only way to
use DNS securely, it's just the easiest one to arrange between total
strangers.  

You don't need DNSSEC deployed universally to use DNS securely.

    Jorge> I also agree with the need of an ad-hoc peer-to-peer VPN
    Jorge> bypassing gateways.  While there are implementations from
    Jorge> multiple vendors, including the one I work for, there is no
    Jorge> standardized/scalable solution for the problems associated
    Jorge> with these scenarios. Key challenges are:

    Jorge> - Discoverability of suitable peers

    Jorge> - Discovery of the set of crypto contracts required if
    Jorge> allowed

==== 

    Jorge> I won't be able to attend the IETF meeting in Taiwan, however
    Jorge> once the date and time is settled I'll coordinate with
    Jorge> someone representing my company to attend the BOF meeting.

+1

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Nov 2011 00:02:25 +0200

>use DNS securely, it's just the easiest one to arrange between total

Yup, expect that the problem we're trying to solve here is not that of
total strangers.

---

From: Geoffrey Huang <[email-masked]>
Date: Mon, 31 Oct 2011 17:56:14 -0700

Put differently, it better be Wednesday night, since I can't be in Taipei any earlier ;-).

-geoff

From: Stephen Hanna
Sent: Friday, October 28, 2011 3:09 PM
To: Yoav Nir; Geoffrey Huang
Cc: [email-masked]
Subject: RE: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

Steve

-geoff

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Oct 2011 23:09:55 -0400

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

    >> DNSSEC is *one* *public* trusted third party.  It's not the only
    >> way to use DNS securely, it's just the easiest one to arrange
    >> between total strangers.

    Yoav> Yup, expect that the problem we're trying to solve here is not
    Yoav> that of total strangers.

If the entities are in fact a group who has an internal trust anchor:
   a) if they want to use DNSSEC, it only matters they have DNSSEC
      deployed for the part of the reverse zone they use, and that
      they have a trusted anchor into that.

   b) a really simple way to get secure DNS data is to make every
      (gateway) machine a secondary for the zones in question. 
   c) a second way is to simply point the /etc/resolv.conf and/or
      the DNS-forwarders to some *set* of internal servers, ideally
      authenticated with TSIG... OR, even do it over the single spoke
      to hub IPsec tunnel.

Finally, if we are talking IPv4, then the internal IPs are likely
RFC1918, and so one can't use the public DNS anyway, so you have to do
either (b) or (c) ANYWAY.

Again, this can all be done with existing protocols and existing
software, which, on a Linux machine, you can do a yum install or
apt-get install.