GSoC

Ideas Page

While IKE and IPsec have been around for almost 20 years, like SSL/TLS, the protocols are still evolving and getting new features to deal with an ever changing mobile world. The Libreswan Project's core developers have come up with a list of projects that they would like to see implemented and for which they are willing to commit to mentoring students. If any of these projects look interesting to you, feel free to contact the developers either on the developer mailinglist or the #swan channel on the FreeNode IRC network.

Re-implement the KVM/python based testing infrastructure

Required Skills: General DevOps and Virtualization skills, python and shell scripting

Libreswan Mentors: Andrew Cagney, Antony Antony, Paul Wouters

The goal is to investigate using another container technology that is better suited for our use. This could be raw namespaces, "unshare", kubernetes, docker (without systemd), openshift, openstack or something else. Note that since it needs to support containerized IPsec kernel stacks, LXC or vserver will not work.

The following new properties are desired for the new test harness:

• Allow most tests to run with containers running libreswan, instead of VMs running libreswan
• It should be able to run many tests in parallel on 1 machine
• It should be able to spread jobs on multiple machines
• Distinguish minor issues (diff in output) from major issues (different number of IKE or IPsec SA's)
• Be as independent from the host OS as possible
• Keep similar web based reporting output

The following properties of the current test harness should not be lost:

• Existing test case reference output should be re-used as much as possible (https://github.com/libreswan/libreswan/tree/master/testing/pluto)
• Capture all network traffic on all interfaces
• Capture all console / log output
• Run with the least amount of privileges / root access
• Run with the existing sanitizers (https://github.com/libreswan/libreswan/tree/master/testing/sanitizers [testing/sanitizers/])
• Extend the current init -> run -> final scripting to allow multi order scripts (run1 on vm1, run2 on vm3, run3 on vm1, run4 on vm2, etc)
• IPv4, IPv6, and NAT/non-NAT networks required for testing (current setup using the "nic" VM for all of this)
• Use existing X.509 certificate generation (https://github.com/libreswan/libreswan/tree/master/testing/x509 [testing/x509/])
• Allow the use of faketime to run individual containers in the past or future.
• Bonus: Support FIPS mode and SElinux/MLS for Labeled IPsec
• Bonus: Test different versions / architectures against each other

History of the current test harness

The libreswan testing infrastructure has its roots in the ancient UserMpdeLinux (UML). It ran for a number of years until UML stopped working reliably on newer kernels. In 2012 this system was migrated to the current system which us based on KVM, QEMU and libvirt tied together with python code. This system is used daily for automated testing as well as by most libreswan developers when working on specific code. Anyone can run these tests on their server or laptop as documented at Test_Suite

Daily test results are available at Daily Test Results and an example run can be found at http://testing.libreswan.org/results/testing/3.19-79-g99db3b6-master/

There are currently around 600 test cases that involve booting 2 to 4 VMs to install various IPsec tunnels. The console output is captured, sanitized and compared against known good output. It takes about 8 hours to run and most of the time is lost waiting on VMs to startup and shutdown. Test cases consist of "init", "run" and "final" shell scripts that perform the actual test. You can browse our test cases at testing/pluto

Waiting 8 hours to see if a code change breaks anything is not pleasant. An attempt was made to speed things up dramatically using docker instead as documented at [Test_Suite_-_Docker]

Unfortunately, our experiment with docker turned out to be very slow as well, mostly due to the additional overhead of systemd and the plumbing to support multiple interfaces which we need for our tests.