GSoC

Previous Student projects

See Student projects for completed student projects (sponsored by GSoC 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 #libreswan channel on the LiberaChat 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 and there is a video recording of the presentation.

Implement ipsec add command to make it easier to add connections

(this item is already being worked on outside of GSoC)

Required Skills: Python, bash/shell, writing documentation and test cases

Libreswan Mentors: Paul Wouters, Tuomo Soini

Currently, when adding connections the administrator has to write up the .conf file themselves. The "ipsec add" command would be a non-interactive or interactive command, based on the input, that would help create the connection with the right settings for the administrator.

Implement varlink status reporter

Required Skills: C programming, writing documentation and test cases

Libreswan Mentors: Paul Wouters, Tuomo Soini

There is a demand to monitor for status change (and in a later state perform reconfigurations) using a varlink API. This is kind of like a successor to dbus. It would replace the whack status command that is too expensive to fire up all the time.

Implement addresspool support for Radius / AAA backend

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

Libreswan Mentors: Paul Wouters, Tuomo Soini

Currently, pluto can only use a builtin 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, instead 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).

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.

Implement Multiple Key Exchanges in IKEv2

Required Skills: BSD networking, C, shell scripting, RFC interpretation

See https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke

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

Implement SD-WAN "outsourced" key exchange

Required Skills: BSD networking, C, shell scripting, RFC interpretation

See: https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection

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 NetBSD, 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 FreeBSD to the testing system for interop testing similar to OpenBSD

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

iOS VPN app for libreswan to configure native IPsec stack

Create an iOS app to help create/tune/manage IPsec VPNs.

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 IKEv2 Group Key Management

Add Group Key Management as per https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2

Use of a VPNonly namespace

A fedora or debien/ubuntu based proof of concept to run applications in a VPNonly namespace, which only allows those applications network access if a VPN connection is up. This will use the new XFRMi interface ipsecX.

Some gnome based interaction to mark applications VPNonly. For example, only allow firefox and thunderbird to send traffic via VPN, not outside VPN.

Related: a hotspot namespace handling hotspot signons, that are isolated and do not mix with DNS from other sources. A DNS namespace that is not contaminated when hotspot signon is being done and that does DNS forwarding for VPN.

This idea requires some brainstorming and coming up with an architecture that works to support these kind of namespace handlings.

Implement the INTERNAL_DNSSEC_TA support

See https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-16

Integrate libreswan into OSS-Fuzz project

Required Skills: C, code reading

OSS-Fuzz is Google's project for fuzz testing the code of various open source projects. In order to integrate libreswan into OSS-Fuzz, one should first identify the potential pieces of code that would be suitable and desirable for fuzz testing. Then the fuzzing targets for the identified code should be implemented. Final step would be to request admission of libreswan to OSS-Fuzz and fulfill (implement) the requirements of OSS-Fuzz project.

More about fuzz testing, fuzzing engines and OSS-Fuzz can be found on OSS-Fuzz project page.

There are some related open source projects that can be used as an example of successful project integration into OSS-Fuzz, e.g.:

- strongswan: project section on OSS-Fuzz and fuzzing targets.

- Mozilla's NSS: project section on OSS-Fuzz and fuzzing targets.