Opportunistic Encryption on the IP Layer

I have written a small forwarding resolver in Perl using Net::DNS that catches A and AAAA records and looks up the corresponding IPSECKEY record for the same name. Here's a typical debug run where I do a lookup for the host name ipsec2.hack.org in another window:

ipsec1# ./ns.pl
Adding local address:
2001:16d8:ffff:1:0:0:0:3
Any AAAA records for ipsec2.hack.org?
Oh! It's A or AAAA!
Lookup IPSECKEY.
We got an IPSECKEY!
Public key (RSA): AQO69zuWw9eX59xnZjzSN+N9DUcFIm0htb2XRLThLaVZC1uRVJwW2SkeLrlJuio6iZqh3WS2OfHYcn8zE0H0oVnaG5/38um/6LVN/ysOWXt8FPUwV4PVyjlJJYC15NR2+h6kNbR5Z8XPz0IxvtYO2Bes44xq22L09z/cXoog/gW8DzRmQSZ+OrUDPx3G7ej2pf/P88TPcxDhypfXJCgc8IMRaDpGKsLekzDWVOXPQ5NIiJKwfA4WMuphs4BxuLisYJPS6TCl05dGKlSuQ4zaQ4uxMM1qX1RvLRP8tpCfaNsJzAhgciqRbP2vnvecyXHC6yaCuSD0LDz1z2uLXSQBuxrF5F+yUycyqZt7QvBN13Pk5jw5e2YCsMzPydFw6eZVAcrJol9jTr6WxB/Z3T0cAz9D2nBAhCf8H/7kfGqcivY8d+2fuNl3j+8J68E2v7ntJQZu/Djb7Ks6pjECHES1KkQwwL+ICKQhpqCRS2eytdgBXJCjvPGQYqbRKcuCj7wMtxGCeDhQwq07WMVE/09u2xo43kYh0d6QRfi0EmUFWJk8c7UYUTOd+BBIiintkuUCZXWAiPxlkUETlWui5ojmuvOYqpIDTjUD8hLMYMHvljnPc7OeuVuJyCeKTnS+5fHhsZdCYLslwo1NLc2wyzqPa9JCE5+fcYS8hFISLruAURFvKw==
Setting up security policy between 2001:16d8:ffff:1:0:0:0:3 and 2001:16d8:ffff:1:0:0:0:4

Everything here is actually happening and showing real data although the SPD manipulation is a bit crude at the moment. I call setkey(8) for every pair of addresses and feed it on stdin.

A possible followup on this project might be to implement this simple forwarding resolver in C and using the PF_KEY interface directly or, perhaps better, to patch an existing resolver like Unbound.

Please note that there is no DNSSEC validation in this case. We rely on the full resolver, which might run on the same node, to do any validation of the resource records. This might change in the future.

The source code for the resolver is available at the project website.

The Unbound DNS resolver is extendable using Python. I had an idea to write a Python module to do what the forwarding resolver above does but using Unbound's DNSSEC validation.

I have done initial experiments with a simple Python script but I'm still not sure if I can do the actual IPSECKEY query from within the script or if I have to patch the C code. For now, I'll keep experimenting with my Net::DNS resolver to try to make the entire system work before looking at something else.

Here's some sample code for a skeleton of a Python module:

def init(id, cfg):
    log_info("pythonmod: init called, module id is %d port: %d script: %s" % (id, cfg.port, cfg.python_script))
    return True

def deinit(id):
    log_info("pythonmod: deinit called, module id is %d" % id)
    return True

def inform_super(id, qstate, superqstate, qdata):
    return True

def operate(id, event, qstate, qdata):
    print "operate(): event is ", event

    if event == MODULE_EVENT_NEW or event == MODULE_EVENT_PASS:
        print("Sending original query \"%s\", type %s (%d), class %s (%d) " % (
            qstate.qinfo.qname_str, qstate.qinfo.qtype_str,
            qstate.qinfo.qtype,
            qstate.qinfo.qclass_str, qstate.qinfo.qclass)) 

        # Pass on the new event to the iterator for a lookup.
        qstate.ext_state[id] = MODULE_WAIT_MODULE 
        return True

    if event == MODULE_EVENT_MODDONE:
        # Iterator finished. We might have a reply.

        print("Reply for query \"%s\", type %s (%d), class %s (%d) " % (
            qstate.qinfo.qname_str, qstate.qinfo.qtype_str,
            qstate.qinfo.qtype,
            qstate.qinfo.qclass_str, qstate.qinfo.qclass)) 

        if qstate.return_msg and qstate.qinfo.qtype_str == "A":
            print("Store away reply for A record.")

            # TODO: Store away the original message.

            # Look up IPSEC.
            print("Look up IPSECKEY")

            # XXX Now what?

        # We're done.
        qstate.ext_state[id] = MODULE_FINISHED 
        return True

    qstate.ext_state[id] = MODULE_ERROR
    return True

log_info("pythonmod: script loaded.")

At the "XXX Now what" I tried with what I thought was the obvious: Create a new qstate and fill it with an IPSEC query and then do:

# Pass on the new event to the iterator for a lookup.
newq.ext_state[id] = MODULE_WAIT_MODULE

but it didn't work. I'm sure I made some mistake. I tried a lot of different versions of this but nothing I did worked and I needed to spend time on other things.

Someone more knowledgeable about the insides of Unbound might want to pick this up or at least comment on it. If it's impossible to do from Python I would appreciate if someone told me so I can focus on patching Unbound in C instead, if I can find the time.

Here are some available key daemons I have found:

• racoon from ipsec-tools/KAME. BSD license. C. Supports public keys. Supports CERT DNS lookups. Supports automatic policy generation. IKEv1.
• racoon2 from WIDE. BSD license. C. Doesn't support plain public keys? Supports X.509. IKEv1 and v2.
• OpenBSD isakmpd. BSD license. C. Supports X.509.
• OpenBSD iked. ISC license. C. Supports X.509 and plain public keys.
• charon (Strongswan and Openswan). GPLv2. C. Supports public keys. IKEv2. Supports IPSECKEY lookups?
• pluto (Strongswan and Openswan). GPLv2. C. Supports public keys. IKEv1. Supports IPSECKEY lookups? Not available on FreeBSD.
• IKEv2. Alpha status. Linux only? Web page http://ikev2.zemris.fer.hr/ not available.
• OpenIKEv2. C++. IKEv2.

Of these racoon, racoon2, isakmpd and Strongswan's charon are the ones available in the FreeBSD's ports tree.

I chose to look closer at racoon since it has a permissive license, it's multiplatform (FreeBSD, NetBSD and Linux), it's written in a language I understand and it has some nice features like automatic policy generation. Time permitting I will look closer at at least Strongswan's charon and OpenBSD's iked as well.

For reference, here are some notes on how I configured two qemu instances running FreeBSD to use IPsec with public key authentication using racoon and my own resolver to set up the security policy.

I run IPsec enabled FreeBSD kernels. This requires a kernel recompile with "option IPSEC" and "device crypto". They run on two qemu instances connected through a bridged host interface. I start them like this:

qemu -enable-kqemu -nographic -hda /backup/slask/fbsd.img -m 512M -net nic,model=e1000 -net tap,name=tap0,script=no

qemu -enable-kqemu -nographic -hda /backup/slask/fbsd2.img -m 512M -net nic,model=e1000,macaddr=52:54:00:12:34:57 -net tap,name=tap1,script=no

The use of the tap interface was configured like this on the host running the qemu instances:

Add this to /etc/sysctl.conf:

net.link.tap.user_open=1
net.link.tap.up_on_open=1

/etc/devfs.conf:

perm    /dev/tap0       0660
perm    /dev/tap1       0660

This will allow users in group wheel (default owner of /dev/tap*) to use the devices. Add yourself to the wheel group.

The bridge was created by adding this to /etc/rc.conf:

cloned_interfaces="tap0 tap1 bridge0"
ifconfig_bridge0="addm em0 addm tap0 addm tap1 up"

I manually configured IPsec with public key authentication using using the racoon IKE daemon from ipsec-tools/KAME.

I generated the key pairs like this:

% plainrsa-gen -b 4096 -f privatekey.rsa

At the top of the generated file there is a public key beginning with "#: PUB". Copy the public key to your public key directory (path certificate in the racoon configuration below) on the other host and remove the "#".

I created this racoon configuration:

path certificate "/usr/local/etc/racoon/certs";

remote anonymous
{       
        exchange_mode main;
        # Doesn't really matter if we use main mode or aggressive
        # mode. Our identy isn't secret and we don't send any
        # hashes of a pre-shared key in the clear.
        # exchange_mode aggressive;
        lifetime time 24 hour;
        my_identifier fqdn "ipsec2.hack.org";
        # On the other host:
        # my_identifier fqdn "ipsec1.hack.org";
        certificate_type plain_rsa "privatekey.rsa";

        # The other host's public key:
        peers_certfile plain_rsa "pubkey1.rsa";
        # On the other side:
        # peers_certfile plain_rsa "pubkey2.rsa";

        # Automatically generate a Security Policy when the other
        # side initiates dialogue.
        generate_policy on;

        proposal
        {       
                encryption_algorithm aes;
                hash_algorithm sha256;

                # Use public key authentication:
                authentication_method rsasig;

                dh_group 2;
        }
}

sainfo anonymous
{        
         lifetime time 1 hour;
         encryption_algorithm aes;
         authentication_algorithm hmac_sha256;
         compression_algorithm deflate;
}

This configuration file will automatically generate fitting security policies on the responding side after suggestions from the initiator. If you want to set policies manually instead, create files like these and run them (on one host, reverse it on the other host)::

#!/sbin/setkey -f

spdflush;
spdadd 10.0.0.22 10.0.0.23 any -P out ipsec esp/transport//require ;
spdadd 10.0.0.23 10.0.0.22 any -P in ipsec esp/transport//require ;

I tried with a "require" policy on IPv6 as well but for some reason yet to be discovered it didn't work. This, however, did:

spdadd 2001:16d8:ffff:1::3 2001:16d8:ffff:1::4 any -P out ipsec esp/transport//use ;
spdadd 2001:16d8:ffff:1::4  2001:16d8:ffff:1::3 any -P in ipsec esp/transport//use ;

It might be a problem with Neighbor Discovery. I will investigate further.

Using this I can initiate an IKE dialogue between the two racoons by simply pinging the other host. After the IKE dialogue is finished the pings goes through and all traffic between the two hosts is encrypted.

Starting without security policies I can run my forwarding resolver, ns.pl, and have it set up policies as required on the initiating node. When it's running I can ping the other host by name and the resolver catches the name lookup, sets up a security policy and the racoon on my side starts negotiating. With racoon's automatic policy generation on the responding side traffic starts to flow.

I configured both the hosts in my DNS zone like this (one of the hosts):

ipsec1                  IN      AAAA    2001:16d8:ffff:1::3

ipsec1                  IN      IPSECKEY ( 10 0 1
                                           .
                                           AQOqVjnhO/eQdETVCH7r2am7yUixEcWUgyffNhdmTigiLS7VZODtxC2ii3ySKEOD6ADxykvgn6KVotSYmSq2kNAdmbElkMl3stAHE+E327vSkX3vKR3/l23Wrrv0iUlJFm+5WK1TJC6jTkjH8Fc0j77mdATGfmWYC4MdONuPUDMeEaMu9/XJm+X0ZWfGG/q1158smfkwsRvKh1KZCJLuGYv+Y85kRnMwnejtQRpDMZbjNr8dtS90MR7kGgQIJ/ctgc//MRjpTo8NTWncDp9KKvuNcBxsPPL08YTF/BkcG60SeeKD1jqjdnY+VRFkrv3BO0WyFEib/fuxeA2FJLYMYOuGG3n1KKSLckD7B5AfNOKKME94f+glY65M8njVVAIKahufUzp+DIW9AgURxuAwNoCiRpS3i+sh7lY/dT5AzbZ8Ewl2jgsdX/neAXCiOWrSMUZGyARNcvAsOleRk93pb0y43FEU8f8OcS027p+ZbBHVbHYbLFEX6eg3NbJso3LTL6Gx8SxWX8W6KvBjFf7sWO4ehEcXPJXJ+lsY/UQfAbeFlUTicQd83+rVuuHfJvbxYWx0Sia6bERlKRSYTWT4FBwH3AwMTLQRskWasyBTbLbk1KHkUBZv4Ts5J+pGzAVsbPLINLnb5/lifjZdPGca6yn+5mbkKdjPSyV0ZHYfqiO4qQ==

and the corrresponding in the reverse zone:

3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.f.f.f.f.8.d.6.1.1.0.0.2.ip6.arpa. IN PTR ipsec1.hack.org.

That is all for now. Please visit the project web and stay tuned for more.