<div dir="ltr"><div class="gmail_extra"><br>I have similar interests to the OP (hopefully he forgives the thread jack) and have been trying to setup a proof of concept, non NAT&#39;d, host-to-host, &quot;full mesh&quot; private WAN (RFC1918 space) OE setup.<br>
<br><div class="gmail_quote">On Wed, Dec 18, 2013 at 4:51 PM, Paul Wouters <span dir="ltr">&lt;<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Wed, 18 Dec 2013, <a href="mailto:dave@ariens.ca" target="_blank">dave@ariens.ca</a> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I&#39;m excited to implement opportunistic encryption with libreswan, but I&#39;m fumbling finding an appropriate resource to help me through it.<br>
<br>
Are there any sites/resources recommended by the list members?<br>
</blockquote>
<br></div>
What exactly are you implementing? We are still designing some of the<br>
OE &quot;2.0&quot; issues, so it would certainly make sense if we&#39;re looking at<br>
specifying and implementing the same thing.<br>
<br></blockquote><div>..<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What we are trying to avoid are too different &quot;kinds&quot; of OE. We also<br>
want to avoid creating thousands of &quot;do not encrypt&quot; kernel policies.<br>
We are also moving some state out of the IKE daemon into an unbound DNS<br>
server module. So you should probably tell us what you are looking at,<br>
so we can help each other out instead of implementing our own things.<br>
<br>
For some more information, see:<br>
<br>
<a href="http://www.ietf.org/proceedings/88/slides/slides-88-saag-3.pdf" target="_blank">http://www.ietf.org/<u></u>proceedings/88/slides/slides-<u></u>88-saag-3.pdf</a><span class=""><font color="#888888"><br>
<br>

Paul</font></span><div class=""><div class="h5"><br></div></div></blockquote><div><br>Before I began down this path, basic/goal/wishlist requirements were:<br><br>1a.) that all host to host communication begins in the clear and attempts to switch up to encrypted tunnels ala STARTTLS<br>
</div><div>or<br></div><div>1b.) that all host to host communication is initially trapped while an encrypted solution is attempted with..<br>2.) .. the ability to configure fail open or fail closed behaviour, timeframes associated with the time the packet is trapped (the introduction of excessive application delay will kill any deployment opportunity), active connection expiry timers, etc<br>
</div><div>3.) whitelist/blacklist certain hosts or port combinations (clear to DNS 
servers, exclude things already covered by other means [eg https],
 exclude this CIDR, exclude that protocol [eg ICMP], etc)<br>4.) a focus on making ubiquitous deployment very simple to opt in to and under the control of the end server sysadmins<br>5.) initially, have those server sysadmins generate and publish their own 
keys into DNS ala DANE (initially without DNSSEC validation, thus far we have opted not to deploy on our private/internal pseudo TLD because we didn&#39;t have a convincing enough need)<br></div><div>6.) hopefully not have all the extra DNS lookups destroy my already very heavily trafficked resolver infrastructure (a locally installed resolver on each host would help here)<br>
</div><div>7.) as a &quot;phase 2&quot;, instead of server admins generating their own keys, allow them to request keys from a centralised private/internal CA infrastructure (which hopefully is still compatible with the use of DNS as a key store)<br>
8.) make sure deployment can scale to thousands of servers<br></div><div><br></div><div>I&#39;m kind of stuck between 1 and 3 right now (different thread) but I thought it would be a good idea to throw this list out there in case it was a useful example of an early adopter use case. <br>
</div><div><br></div>Thanks!<br>Mark<br></div><div class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
<div class="h5">
______________________________<u></u>_________________<br>
Swan mailing list<br>
<a href="mailto:Swan@lists.libreswan.org" target="_blank">Swan@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan" target="_blank">https://lists.libreswan.org/<u></u>mailman/listinfo/swan</a><br>
</div></div></blockquote></div><br></div></div>