[Swan] IPsec and OE Primers for libreswan 3.7

markd lists markd.lists at gmail.com
Fri Jan 10 20:41:01 EET 2014


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'd, host-to-host,
"full mesh" private WAN (RFC1918 space) OE setup.

On Wed, Dec 18, 2013 at 4:51 PM, Paul Wouters <paul at nohats.ca> wrote:

> On Wed, 18 Dec 2013, dave at ariens.ca wrote:
>
>  I'm excited to implement opportunistic encryption with libreswan, but I'm
>> fumbling finding an appropriate resource to help me through it.
>>
>> Are there any sites/resources recommended by the list members?
>>
>
> What exactly are you implementing? We are still designing some of the
> OE "2.0" issues, so it would certainly make sense if we're looking at
> specifying and implementing the same thing.
>
> ..


> What we are trying to avoid are too different "kinds" of OE. We also
> want to avoid creating thousands of "do not encrypt" kernel policies.
> We are also moving some state out of the IKE daemon into an unbound DNS
> server module. So you should probably tell us what you are looking at,
> so we can help each other out instead of implementing our own things.
>
> For some more information, see:
>
> http://www.ietf.org/proceedings/88/slides/slides-88-saag-3.pdf
>
> Paul
>
>
Before I began down this path, basic/goal/wishlist requirements were:

1a.) that all host to host communication begins in the clear and attempts
to switch up to encrypted tunnels ala STARTTLS
or
1b.) that all host to host communication is initially trapped while an
encrypted solution is attempted with..
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
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)
4.) a focus on making ubiquitous deployment very simple to opt in to and
under the control of the end server sysadmins
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't have a convincing enough need)
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)
7.) as a "phase 2", 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)
8.) make sure deployment can scale to thousands of servers

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

Thanks!
Mark



> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20140110/182e253f/attachment.html>


More information about the Swan mailing list