<p dir="ltr">Keys are distributed via dns records.</p>
<p dir="ltr"><a href="https://tools.ietf.org/html/rfc4322">https://tools.ietf.org/html/rfc4322</a></p>
<p dir="ltr">Carl</p>
<div class="gmail_quote">On Apr 21, 2014 5:35 PM, "Kevin Benton" <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">This is interesting. How is key distribution handled when I want to use OE with someone like Google.com for example?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 12:07 PM, Martinx - ジェームズ <span dir="ltr"><<a href="mailto:thiagocmartinsc@gmail.com" target="_blank">thiagocmartinsc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Guys,<div><br></div><div>I here thinking about IPSec when with IPv6 and, one of the first ideas/wishes of IPv6 scientists, was to always deploy it with IPSec enabled, always (I've heard). But, this isn't well diffused by now. Who is actually using IPv6 Opportunistic Encryption?!</div>
<div><br></div><div>For example: With O.E., we'll be able to make a IPv6 IPSec VPN with Google, so we can "ping6 <a href="http://google.com" target="_blank">google.com</a>" safely... Or with Twitter, Facebook! Or whatever! That is the purpose of Opportunistic Encryption, am I right?!</div>
<div><br></div>
<div>Then, with OpenStack, we might have a muiti-Region or even a multi-AZ cloud, based on the topology "Per-Tenant Routers with Private Networks", for example, so, how hard it will be to deploy the Namespace routers with "IPv6+IPSec O.E." just enabled by default?<br>
</div>
<div><br></div><div>I'm thinking about this:</div><div><br></div><div><br></div><div>* "IPv6 Tenant 1 subnet A" <-> "IPv6 Router + IPSec O.E." <-> <b>"Internet IPv6"</b> <-> "IPv6 Router + IPSec O.E." <-> "IPv6 Tenant 1 subnet B"</div>
<div><br></div><div><br></div><div>So, with O.E., it will be simpler (from the tenant's point of view) to safely interconnect multiple tenant's subnets, don't you guys think?!</div><div><br></div><div>Amazon in the other hand, for example, provides things like "VPC Peering", or "VPN Instances", or "NAT instances", as a "solution" to interconnect creepy IPv4 networks... We don't need none of this kind of solutions when with IPv6... Right?!</div>
<div><br></div><div>Basically, the OpenStack VPNaaS (O.E.) will come enabled at the Namespace Router by default, without the tenant even knowing it is there, but of course, we can still show that IPv6-IPSec-VPN at the Horizon Dashboard, when established, just for fun... But tenants will never need to think about it... =)</div>
<div><br></div><div>And to share the IPSec keys, the stuff required for Opportunistic Encryption to gracefully works, each OpenStack in the wild, can become a <i>"pod"</i>, which will form a network of <i>"pods"</i>, I mean, independently owned <i>pods</i> which interoperate to form the "<i>Opportunistic Encrypt Network of OpenStack Clouds</i>".<br>
</div>
<div><br></div><div>I'll try to make a comparison here, as an analogy, do you guys have ever heard about the DIASPORA* Project? No, take a look: <a href="http://en.wikipedia.org/wiki/Diaspora_(social_network)" target="_blank">http://en.wikipedia.org/wiki/Diaspora_(social_network)</a><br>
</div><div><br></div><div>I think that, OpenStack might be for the Opportunistic Encryption, what DIASPORA* Project is for Social Networks!<br></div>
<div><br></div><div>If OpenStack can share its keys (O.E. stuff) in someway, with each other, we can easily build a huge network of OpenStacks, and then, each one will "naturally" talk with each other, using a secure connection.</div>
<div><br></div><div><div>I would love to hear some insights from you guys!</div><div><br></div><div>Please, keep in mind that I never deployed a IPSec O.E. before, this is just an idea I had... If I'm wrong, ignore this e-mail.</div>
</div><div><br></div><div><br></div><div>References:</div><div><br></div><div><a href="https://tools.ietf.org/html/rfc4322" target="_blank">https://tools.ietf.org/html/rfc4322</a><br>
</div><div><br></div><div><a href="https://groups.google.com/d/msg/ipv6hackers/3LCTBJtr-eE/Om01uHUcf9UJ" target="_blank">https://groups.google.com/d/msg/ipv6hackers/3LCTBJtr-eE/Om01uHUcf9UJ</a><br>
</div><div><br></div><div><a href="http://www.inrialpes.fr/planete/people/chneuman/OE.html" target="_blank">http://www.inrialpes.fr/planete/people/chneuman/OE.html</a><br></div><div><br></div><div><br></div><div>Best!</div>
<div>Thiago</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>