[Swan] IPsec and OE Primers for libreswan 3.7

[dave at ariens.ca]

Paul,

Is the San Francisco meet up a formal event? Is there any public information about it or thoughts on streaming some/all of the discussions? I would love to observe somehow?


--
Dave Ariens
www.ariens.ca
  Original Message  
From: Paul Wouters
Sent: Saturday, January 11, 2014 12:30 PM
To: markd lists
Cc: dave at ariens.ca; swan at lists.libreswan.org
Subject: Re: [Swan] IPsec and OE Primers for libreswan 3.7

On Fri, 10 Jan 2014, markd lists wrote:

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

We'll put up our wiki after our San Francisco meetup with updated OE
information.

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

The logic for "We can encrypt to that host" is moved out of the IKE
daemon. The first and most obvious target we are aiming for is doing
this in the localhost DNS resolver. Whenever an application requests
an A/AAAA record, we sneak in an IPSECKEY record query. We wait
returning the A/AAAA until we know the result of the IPSECKEY query.
If we find a key, the DNS server tells the pluto IKE daemon the remote
FQDN, IP address and public key. It can than setup the tunnel. Once
that has completed, the DNS server releases the A/AAAA answer to the
application. This also means we get a free "retry" mechanism based
on the DNS negative caching times.

> 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

In the above, there would only be a "fail open", although we have to
look at the corner cases. If DNS returns a forged answer or ServFail,
we should look at inserting a shunt and fail close. You could also
block all non-IPsec/non-IKE/non-DNS traffic using iptables to achieve
a failed-close system. In the past, discovering there was no IE and
failing clear too way too long and was an obstacle for deployment.
We are being careful now not to repeat that mistake. We need to fail
quick and fast back to plaintext. But of course securely.

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

That would be hard to do if you base this off the DNS, as the DNS server
has no idea what you will use that name for.

> 4.) a focus on making ubiquitous deployment very simple to opt in to and under the control of the end server sysadmins

There will be roughly two modes of OE. One is to try finding an IPSECKEY
record. This is the authenticated version. A fallback is one where no
one has published a key, this is "anonymous IPsec", which is not
authenticated, can be MITM'ed, but requires no setup by the admin. Just
start the IKE daemon. We will make this second mode optional so it can be
disabled on the client side and server side. Disabling this first option
is simple - just don't publish your ipsec key in DNS.

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

We are wary at adding too many flavours of OE. So having one where we
got the key from DNS, but without DNSSEC protection, makes it harder
to put a security value to a connection. Image, we wish an application
to be able to query the OS via some setsockopt or library call to
request the "security status" of contacting this remote IP address.
If we need to say more than "anonymous IPsec" and "authenticated IPsec",
things get mucky really quick. "authenticated but potentially spoofed
IPsec"? "leap of faith IPsec"? So again, I think at first we will try
to limit this to two types, meaning to use DNS records, they need to
be protected by DNSSEC.

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

It is a requirement to run unbound locally. If can be configured as
forwarder but will still do dnssec validation. So basically, it will
use the cache if possible, otherwise try to work around it (see the
dnssec-trigger package that auto-configures unbound for this)

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

Having other non-DNSSEC resources is possible in this setup, because you
just need to generate different methods for obtaining (IP, pubkey) and
you can than tell the pluto IKE daemon to setup a tunnel. So yes, that
will be possible. Although I'm more leaning towards having enterprise
deploymets with freeipa use their client-PDC relationship to update
their ipsec public key in DNS using authenticated dynamic updates.

Another idea is to run global DNS servers that allow you to query for their
DNS(SEC) cache, so you can get a lot of IPSECKEY records at once
preloaded in your DNS server. As data is DNSSEC signed, you can just
delete any malicious/bogus data from those servers. It is really just
a "prefetch" of DNSSEC data.

> 8.) make sure deployment can scale to thousands of servers

That's the plan :)

Paul