GSoC

From Libreswan
Revision as of 00:55, 3 February 2019 by Paul Wouters (talk | contribs)
Jump to navigation Jump to search

Previous Student projects

See Student_projects for completed student projects (sponsored by GSoC 2017 and others)

Google Summer of Code 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 world. The Libreswan Project's core developers have come up with a list of projects that they believe would be interesting for students to work on. The mentors have a personal interest in these projects as well. 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. You can also email gsoc@libreswan.org with any questions you have or if you would like to introduce yourself.

A quick overview and history of The Libreswan Project was presented by Paul Wouters as part of the Opportunistic IPsec presentation at the 2016 [Linux Security Summit]. There is also a Video Recording of the presentation.

Re-implement the KVM/python based testing infrastructure

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

Libreswan Mentors: Andrew Cagney, 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 of the host OS as possible
  • Keep similar web based reporting output


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


The libreswan testing infrastructure has its roots in the ancient UserModeLinux (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 the 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.

Implement addresspool support for Radius / AAAA backend

Required Skills:' C programming, RFC interpretation, writing documentation and test cases

Libreswan Mentors: Paul Wouters, Tuomo Soini

Currently, pluto can only use a buildin addresspool= range. There is demand for handing out static leases for specific users. This would be possible when using a standard radius/AAA backend. In IKE_AUTH, insted of narrowing to our own addresspool IP, a request would be send to a backend that would provide the IP address.

Improve the ACQUIRE to IKE policy lookup by making use of the reqid

Required Skills:' C programming, RFC interpretation

Libreswan Mentors: Paul Wouters, Tuomo Soini

Currently, pluto keeps a policy and when an ACQUIRE comes in, has to re-match this with the packet's source/dest parameters. This lookup could be improved if pluto used the reqid properly to do lookups. Additionally, this would allow for a configuration that is packet triggered to a right=%any destination. And allow left=%any support for our own IP address (instead of %defaultroute)

IKEv2: optimize proposal syntax

Required Skills: C programming, RFC interpretation

Libreswan Mentors: Paul Wouters, Andrew Cagney

In IKEv1, proposals consist of ENCR+INTEG+DH In IKEv2, proposals consist ENCR1,ENCR2,INTEG1,INTEG2,DH1,DH2 [...]

Currently the ike= and esp= proposals are build up based on the old IKEv1 type of proposals. For IKEv2 proposals, this leads to unneccessary large proposal sets. This also presents some diificulties specifying a lot of proposals, such as done by RHEL/CentOS using the system wide crypto policies.

This idea aims to add a new IKEv2 keyword that allows native IKEv2 proposals to be specified in replacement of ike= and esp= keywords. Note that it needs to support multiple proposals, since there is a need for AEAD and non-AEAD algorithsm which need to be in separate proposal structures within a total proposal.


Extend RFC-7427 Signature Authentication support to IKEv2 with EDDSA support

Required Skills: C programming, RFC interpretation, PKIX/X.509/ASN knowledge.

Libreswan Mentors: Tuomo Soini, Andrew Cagney

This project continues previous GSoC projects to support and extend RFC-7427 support

IKEv2 performs authentication by using separate mechanism to specify the authentication method as specified in the IANA IKEv2 Authentication Method:

http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

The IPsec Working Group at IETF realized using a separate number whenever a new algorithm is added is not very friendly for implements. It basically duplicates the OIDs and SubjectPublicKeyInfo data structures. RFC-7427 generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation.

Libreswan itself currently supports RSA, RSA-PSS and ECDSA. The project goal is to add support for EDDSA as per:

https://tools.ietf.org/html/rfc8420

Libreswan uses the NSS library for both PKCS#11 and for algorithm implementations. It is possible and likely that NSS needs to be extended as well to support EDDSA.

Add EAP Authentication support to IKEv2

Required Skills: C programming, NSS or openssl crypto library, RFC interpretation

Libreswan Mentors: Tuomo Soini, Paul Wouters

Most EAP implementations are based on wpa_supplicant and openssl. Unfortunately, libreswan uses the NSS library. The student will investigate the options available and present o proposal justifying whether to use NSS or openssl.

Desired EAP implementations - most desired ones listed first:

Implement TLS Encapsulation of IKE and IPsec Packets

This project builds on last year's GSoC's project that added TCP support to IKE (and soon the Linux kernel will be able to support TCP for ESP) as per RFC 8229. The next step is to add support for IKEinTLS and IKEinESP support. This will enhance the protocol to be used in networks that only reliably allow HTTP and HTTPS traffic. The student would have to take a look at the kernel TLS support, and look at what the best way is for this support to be implemented - Via kernel TLS with a minimal userspace component for the handshake, or by pulling in all ESPinTLS packets from the kernel into the userland.

While we can assist a bit with the kernel work, we are not kernel developers. However, if someone is interested in this project, we will look and see if we can find a willing kernel developer to co-mentor.

Required Skills: C programming, Advanced Network Programming, RFC interpretation

Libreswan Mentors: Hugh Redelmeier, Paul Wouters

The libreswan IKE daemon basically consists of a libevent based loop that waits for events. Currently, these events can be incoming UDP or TCP traffic, commands over a Unix domain socket, timed events and crypto or DNS helper events. Listening to TLS streams in such a way as to not open up the daemon for DDoS attacks is required for this implementation. This requires some architecture work for which we have the original daemon author (Hugh) available as a mentor.

Opportunistic IPsec development using LetsEncrypt

Required Skills: DevOps, scripting (python, shell), PKIX/X.509

Libreswan Mentors: Paul Wouters, Tuomo Soini

Opportunistc IPsec is an attempt to encrypt the internet at large. The idea is to build VPN tunnels directly to all internet hosts irrespective of the communication used. This concept has its origins with The FreeS/WAN Project started by John Gilmore in late '90s. An initial proof of concept was created that leverages LetsEncrypt certificates for use with IKE and IPsec. The goal of this project is to turn this proof of concept into production quality code that makes it trivial to enrol and deploy on any server and any client.

  • Automate the enrollment and updating of LetsEncrypt certificates for use with libreswan
  • Implement a DNS / DNSSEC based method for advertising Opportunistic IPsec support using LetsEncrypt for servers
  • Design a non-DNS based method for publishing support of LetsEncrypt based Opportunistic IPsec for servers
  • Enhance libreswan to allow a secure fallback to the existing NULL Authentication nethod

Support for AF_KEY symmetric crypto via kernel calls

Currently, the symmetric crypto (as well as user authentication via X.509) happens via NSS. We are looking at converting the symmetric crypto operations of IKE (not X.509 authentication) to be done by the kernel via its AF_KEY sockets. A new config setup option would determine which of the two crypto providers to use.

Extend MOBIKE support to allow it to be used as server failover mechanism

See RFC 4555 and https://www.ietf.org/mail-archive/web/ipsec/current/msg11844.html

Support for RFC 5723: IKEv2 Session resumption

Add support for RFC 5723

In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.

This RFC might not be enough for the entire GSoC period. If done early, the student is expected to start work on another small RFC

Support for RFC 6023: Childless IKE SA

Add support for RFC 6023

This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA.

This RFC might not be enough for the entire GSoC period. If done early, the student is expected to start work on another small RFC

Support for RFC 6290: Quick Crash Recovery

Add support for RFC 6290

This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart.

This RFC might not be enough for the entire GSoC period. If done early, the student is expected to start work on another small RFC

= Support for RFC 7670: Generic Raw public key support

Add support for RFC 7670

The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys. In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography.

Various experimental non-standard feature ideas

See our list of requested features for the Linux IPsec summit:

https://libreswan.org/wiki/Linux_IPsec_Summit_2018_wishlist

These are all Linux kernel related options

Re-port the libreswan code for FreeBSD, OpenBSD, OSX

Required Skills: BSD networking, kernel coding

Libreswan Mentors: Andrew Cagney, Antony Antony


It would need to update/extend the PF_KEY API currently defined. See programs/pluto/kernel_*

Add VM's of OpenBSD and FreeBSD to the testing system for interop testing

Required Skills: BSD networking, C, python, shell scripting

Libreswan Mentors: Andrew Cagney, Antony Antony

Allow the creating of an "east" or "west" to be OpenBSD or FreeBSD instead of Linux, and run tests, similar to how Linux VMs are now created. This means performing an non-interactive VM install using kvm/libvirt, and run strongswan (or libreswan see previous item) on freebsd or run the native iked on openbsd. Especially for openbsd's iked, new interop tests should be written to confirm various interoperability items.


Re-port the libreswan code for Microsoft Windows

This would possibly use the new Linux subsystem in Windows? Or it would use the windows IPsec kernel code and use modern windows features to configure these from the libreswan IKE daemon pluto. Possibly use PowerShell commands like Set-VpnServerConfiguration and Set-VpnServerIPsecConfiguration.

The goal would be to support Opportunistic IPsec and/or build a replacement IKEv2 VPN client.

An ancient, possibly completely useless Win2000 hook is located in programs/pluto/kernel_win2k.c

Cleanup / maintenance / code deduplication

Everyone wants features, no one wants maintenance :)

The codebase has too many comments that point to an issue needing maintenance in some way. A code rewrite, a corner case handling, an oddity. A pointer to code duplication. Refactoring long functions.

This could combine with better splitting IKEv1 and IKEv2 code, so that ikev1 can be not compiled in for the future (via a new USE_IKEv1=true|false compile time option)

Similarly, a code cleanup could be started to remove KLIPS support (but not PF_KEY support)

Detect kernel algorithms supported for IPsec

We are currently using an obsoleted API to determine what algorithms the kernel supports. We then manually hack the reply, because we know the kernel lies to us about certain support.

See also: xfrm_probe_algs(), init_pfkey() and kernel_alg_register_pfkey()

Related, we might want to trigger some crypto algorithm modules to load, but can we?

(We hope to know a bit more after the Linux IPsec summit on what would be involved for this work time)

Implement draft-yeung-g-ikev2 IKEv2 Group Key Management

Add Group Key Management as per draft-yeung-g-ikev2

Retrieved from "https://libreswan.org/wiki/index.php?title=GSoC&oldid=21483"