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: [email protected]; [email protected] 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 <[email protected]> wrote: > On Wed, 18 Dec 2013, [email protected] 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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
