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

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Nov 2011 08:05:17 -0700

On Oct 31, 2011, at 8:09 PM, Michael Richardson wrote:
> If the entities are in fact a group who has an internal trust anchor:

They have an entity they trust to make introductions. That's different.

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

And if they don't? See below.

>   b) a really simple way to get secure DNS data is to make every
>      (gateway) machine a secondary for the zones in question. 

So in order to participate in this mesh, you need to be a DNS server. That seems a tad onerous.

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

That only works if the DNS servers are authoritative for zone in question. But...

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

It would have been nice if you put this assumption at the beginning of your message.

We are *not* only talking IPv4. Further, for IPv4, we are *not* only talking private address spaces.

If you want to extend your earlier protocol to handle non-opportunistic tunnel brokering for IPv4-only, private-address-space-only environments, that's great: I suspect that some people will gravitate towards it. But that's not the problem that is being discussed here.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Nov 2011 22:20:17 -0400

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:
    >> If the entities are in fact a group who has an internal trust

    Paul> They have an entity they trust to make introductions. That's
    Paul> different.

Please explain, as I don't understand the difference.

    >> deployed for the part of the reverse zone they use, and that they
    >> have a trusted anchor into that.

    Paul> And if they don't? See below.

But, you said they did trust someone.

    >> (gateway) machine a secondary for the zones in question.

    Paul> So in order to participate in this mesh, you need to be a DNS
    Paul> server. That seems a tad onerous.

huh?  
  1) DNS servers scale linearly with the amount of data.  
     Smartphones can trivially run DNS servers today, but I agree that
     it's not gonna fit into that Ardino.
  2) I said "be a secondary", that means doing a zone transfer, and
     possibly listening for notifies.  What you with the data once
     you receive it is really your own business.
        
    >> authenticated with TSIG... OR, even do it over the single spoke

    Paul> That only works if the DNS servers are authoritative for zone
    Paul> in question. But...

    >> RFC1918, and so one can't use the public DNS anyway, so you have
    >> to do either (b) or (c) ANYWAY.

    Paul> It would have been nice if you put this assumption at the
    Paul> beginning of your message.

    Paul> We are *not* only talking IPv4. Further, for IPv4, we are
    Paul> *not* only talking private address spaces.

    Paul> If you want to extend your earlier protocol to handle
    Paul> non-opportunistic tunnel brokering for IPv4-only,
    Paul> private-address-space-only environments, that's great: I
    Paul> suspect that some people will gravitate towards it. But that's
    Paul> not the problem that is being discussed here.

It handles this case right today.
I wrote the assumption because, frankly, doing anything for IPv4 RFC1918
networks is a total hack.  It's 2011, and I assume people want IPv6.

If they have *only* 69888 /24s to connect (that's the entire RFC1918
address space), then that's only around 17M of data to store 69888 times
2048-bit raw rsa keys.   I guess I assuming the problem was bigger than 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.