GSoC: Difference between revisions

From Libreswan
Jump to navigation Jump to search
No edit summary
(project updates)
 
(34 intermediate revisions by 5 users not shown)
Line 2: Line 2:
'''Previous Student projects '''
'''Previous Student projects '''


See [[Student_projects]] for completed student projects (sponsored by GSoC 2017 and others)
See [[Student projects]] for completed student projects (sponsored by GSoC and others).
 
'''Proposal submissions'''
 
Submissions must comply to all GSoC rules. We strongly urge any interested students to read up on the previous student projects and the below project ideas. It is not required to big one of these ideas - we welcome new ideas too!  Submissions that tend to be accepted and successful are those that show from the start that the student is putting in the time to understand the concepts. You don't have to be an expert already, and you can contact us at gsoc at libreswan dot org for questions. Mentors like to see students that have put in some work to understand and try things. It is the only reliable metric we have for new people to indicate how serious they are to take on a project for the summer. If implementing an RFC, read the RFC and ask us any questions you have. Have a look at the code base structure in general, look at our testing/ directory. If you don't have VPN/IPsec experience, we are happy to give you a client configuration to gain experience using libreswan to a real VPN server.


'''Google Summer of Code Ideas Page'''
'''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 [https://lists.libreswan.org/mailman/listinfo/swan-dev 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.
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 [https://lists.libreswan.org/mailman/listinfo/swan-dev 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 [http://events.linuxfoundation.org/sites/events/files/slides/LinuxSecuritySummit-2016-OE-16x9.pdf  Opportunistic IPsec presentation] at the 2016 [[http://events.linuxfoundation.org/events/linux-security-summit Linux Security Summit]]. There is also a [https://www.youtube.com/watch?v=Me_rl6N1m7c&list=PLbzoR-pLrL6pq6qCHZUuhbXsTsyz1N1c0&index=17 Video Recording] of the presentation.
A quick overview and history of The Libreswan Project was presented by Paul Wouters as part of the Opportunistic IPsec presentation at the [http://events.linuxfoundation.org/events/linux-security-summit 2016 Linux Security Summit] and there is a [https://www.youtube.com/watch?v=Me_rl6N1m7c&list=PLbzoR-pLrL6pq6qCHZUuhbXsTsyz1N1c0&index=17 video recording] of the presentation.


= Re-implement the KVM/python based testing infrastructure =
= Implement ipsec add command to make it easier to add connections =


'''Required Skills:''' General DevOps and Virtualization skills, python and shell scripting
(this item is already being worked on outside of GSoC)


'''Libreswan Mentors:''' Andrew Cagney, Paul Wouters
'''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.


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.


= Implement varlink status reporter =


'''The following new properties are desired for the new test harness:'''
'''Required Skills:''' C programming, writing documentation and test cases


* Allow most tests to run with containers running libreswan, instead of VMs running libreswan
'''Libreswan Mentors:''' Paul Wouters, Tuomo Soini
* 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


'''Project size''' 350 hours


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


* Existing test case reference output should be re-used as much as possible (https://github.com/libreswan/libreswan/tree/master/testing/pluto)
''' Description'''
* 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 [https://github.com/wolfcw/libfaketime 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


There is a demand to monitor for status changes and reconfiguration commands using a [https://varlink.org/ varlink] API. The varlink API is kind of like a successor to dbus. It would replace the ipsec whack command that is too expensive to fire up all the time. The whack command is also a "pull" method whereas the varlink API will be a push method to anyone who wants (and is allowed) to listen on the right channel.


The libreswan testing infrastructure has its roots in the ancient [http://user-mode-linux.sourceforge.net/ 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]]
Additionally, another varlink channel will be used to send commands to the daemon, which are currently done by the ipsec whack command (or if configurations are used, via ipsec addconn into whack commands). The idea here is that varlink is an existing channel where anyone (with permission) can send commands to the pluto daemon (add connection, up connection, down connection, etc)


The student is expected to first get an idea of what is involved in adding and bringing up a VPN tunnel. Then the "status channel" needs to be defined for varlink messages, and then the pluto code needs to be updated to send varlink status messages over this channel.


Daily test results are available at [http://testing.libreswan.org/ Daily Test Results] and an example run can be found at http://testing.libreswan.org/results/testing/3.19-79-g99db3b6-master/
The "ipsec whack --status" command should then be rewritten to use the new varlink channel and provide the status information.


Once that is working, the command channel can be specified for varlink for per connection commands (add,up,down,delete,status). This would replace the "ipsec whack --name connection" code and within the pluto daemon, the responses would go to the varlink channel instead of the regular whack fd.


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 [https://github.com/libreswan/libreswan/tree/master/testing/pluto/ testing/pluto]
If there is enough time, whack commands that work on the global daemon state, and not on a single connection, can be implemented as well.


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]
The deliverable would be a varlink enabled libreswan pluto daemon and a varlink enabled ipsec whack command.


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 / AAA backend =
= Implement static IP assignments and  support for Radius / AAA backend =


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


'''Libreswan Mentors:''' Paul Wouters, Tuomo Soini
'''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.
'''Project size''' 170 hours
 
'''Difficulty''' Easy to Medium
 
''' Description'''


= Improve the ACQUIRE to IKE policy lookup by making use of the reqid =
Currently, the libreswan pluto IKE daemon can only use a builtin addresspool= range. There is demand for handing out static leases for specific users. A new file similar to ipsec.secrets should be supported that contains a list of IDs and IP addresses to hand out. This should override the regular addresspool= IP allocation.


''Required Skills:''' C programming, RFC interpretation
This solution does not scale very well though and is not compatible with common IP address requests via protocols such as Radius or Diameter. For the second part of this project, the student implements a call to ask a Radius/Diameter server for an IP address based on the received IKE ID. This solution replaces the addresspool= support entrely.


'''Libreswan Mentors:''' Paul Wouters, Tuomo Soini
The deliverable would be two methods for assigning static IP addresses in the libreswan pluto daemon to connecting clients.


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 =
= Improve the ACQUIRE to IKE policy lookup by making use of the reqid =


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


'''Libreswan Mentors:''' Tuomo Soini, Andrew Cagney
'''Libreswan Mentors:''' Paul Wouters, Tuomo Soini


This project continues previous GSoC projects to support and extend RFC-7427 support
'''Project size''' 170 hours


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


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


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.
IPsec policies can be installed in the kernel to be "on demand". Once a packet hits the IPsec subsystem, if it matches a %trap policy, the userland IKE daemon is informed about this so it can initiate an IKE connection to the target destination. Currently, all the installed %trap policies use a "reqid" number of 0. This means that when the IKE daemon receives the message from the kernel, it has to do its own source/dest based lookup to determine which connection got triggered. The goal of this project is to change this by using unique reqid numbers for each connection with a %trap policy. The complication arises from connections with %trap policies that are part of a group. These connections clone themselves into new connections. The clones cannot have the same reqid, so these policies need to be modified before being resend to the kernel.
While the coding is likely to be straightforward, getting to understand the connection structure and kernel structures involved will be the harder part.


Libreswan itself currently supports RSA, RSA-PSS and ECDSA. The project goal is to add support for EDDSA as per:
The deliverable is a pluto daemon that sends and receives unique reqids from kernel messages and that uses these reqids for its connection matching mechanism.


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 Announcing Supported Authentication Methods in IKEv2 =


= Add EAP Authentication support to IKEv2 =
'''Required Skills:''' BSD networking, C, shell scripting, RFC interpretation


Required Skills: C programming, NSS or openssl crypto library, RFC interpretation
'''Libreswan Mentors:''' Andrew Cagney, Paul Wouters


Libreswan Mentors: Tuomo Soini, Paul Wouters
'''Project size''' 170 hours


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.
'''Difficulty''' Easy


Desired EAP implementations - most desired ones listed first:
''' Description'''


* [https://tools.ietf.org/html/rfc7296#section-3.16 EAP in IKEv2]
Implement the IKEv2 extension for multiple supported authentication modesls, see https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-auth-announce
* [https://tools.ietf.org/html/rfc5281 EAP-TTLSv0] (for EAP-MSCHAPv2)
* [https://tools.ietf.org/html/rfc5216 RFC 5216: EAP-TLS Authentication Support for IKEv2]
* [https://tools.ietf.org/html/rfc5998 RFC 5998: An Extension for EAP-only Authentication in IKEv2]
* [https://tools.ietf.org/html/rfc5216 RFC 5216: EAP-TLS Authentication Support for IKEv2]
* [https://tools.ietf.org/html/rfc5106 RFC 5106: EAP-IKEv2 Method]


= Implement TLS Encapsulation of IKE and IPsec Packets =
Currently, both peers will present their authentication method independently. These authentication methods might not be the same. Depending on the received authentication method support received from the peer, adjust the authentication if multiple are supported. Additionally, if the authentication method uses certificates, filter the allowed authentication methods based on the algorithms used in the certificate chain. The internet standards draft is still in the early stage of discussion at the IETF, so someone implementing this might find issues with the draft protocol for which they would need to communicate with the author of the draft to resolve.


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.
= Extend MOBIKE support to allow it to be used as server failover mechanism =


'''Required Skills:''' C programming, Advanced Network Programming, RFC interpretation
'''Required Skills:''' BSD networking, C, shell scripting, RFC interpretation


'''Libreswan Mentors''': Hugh Redelmeier, Paul Wouters
'''Libreswan Mentors:''' Andrew Cagney, 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.
'''Project size''' 350 hours


* [https://tools.ietf.org/html/rfc8229 TCP Encapsulation of IKE and IPsec Packets]
'''Difficulty''' Hard
* [https://github.com/openssl/openssl/pull/5253 kernel TLS API]


= Opportunistic IPsec development using LetsEncrypt =
''' Description'''


'''Required Skills:''' DevOps, scripting (python, shell), PKIX/X.509
See [https://tools.ietf.org/html/rfc4555 RFC 4555] and https://www.ietf.org/mail-archive/web/ipsec/current/msg11844.html on details of how this should work. The reason this project is marked as hard is that there is a lot of userland <-> kernel communciation and changes that need to be sync'ed between the kernel and the userland states.


'''Libreswan Mentors''': Paul Wouters, Tuomo Soini
The deliverable would be a pluto daemon that can generate and respond to MOBIKE requests and a few test cases to show the failover procedure.


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 [http://www.freeswan.org 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
= Support for RFC 6290: Quick Crash Recovery =
* 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 =
'''Required Skills:''' BSD networking, C, shell scripting, RFC interpretation


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.
'''Libreswan Mentors:''' Andrew Cagney, Paul Wouters


= Extend MOBIKE support to allow it to be used as server failover mechanism =
'''Project size''' 170 hours


See [https://tools.ietf.org/html/rfc4555 RFC 4555] and https://www.ietf.org/mail-archive/web/ipsec/current/msg11844.html
'''Difficulty''' Easy
= Support for RFC 5723: IKEv2 Session resumption =


Add support for [https://tools.ietf.org/html/rfc5723 RFC 5723]
''' Description'''


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.
Add support for [https://tools.ietf.org/html/rfc6290 RFC 6290].


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
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.


= Support for RFC 6023: Childless IKE SA =
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.


Add support for [https://tools.ietf.org/html/rfc6023 RFC 6023]
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.


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.
The deliverable is a test case that demonstrates the implemented RFC is working properly.


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 =
= Support for RFC 7670: Generic Raw public key support =


Add support for [https://tools.ietf.org/html/rfc6290 RFC 6290]
'''Required Skills:''' BSD networking, C, shell scripting, RFC interpretation


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.
'''Libreswan Mentors:''' Andrew Cagney, Tuomo Soini


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.
'''Project size''' 350 hours


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
'''Difficulty''' Hard


= Support for RFC 7670: Generic Raw public key support
''' Description'''


Add support for [https://tools.ietf.org/html/rfc7670 RFC 7670]
Add support for [https://tools.ietf.org/html/rfc7670 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.
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 =
= Various experimental non-standard feature ideas =
Line 186: Line 171:
https://libreswan.org/wiki/Linux_IPsec_Summit_2018_wishlist
https://libreswan.org/wiki/Linux_IPsec_Summit_2018_wishlist


These are all Linux kernel related options
These are all Linux kernel related options.
 
= Extend Libreswan's support for FreeBSD =
 
'''Required Skills:''' BSD networking, C, kernel coding, python, shell scripting
 
'''Libreswan Mentors''': Andrew Cagney


= Re-port the libreswan code for FreeBSD, OpenBSD,  OSX =
'''Project size''' 170 hours


'''Required Skills:''' BSD networking, kernel coding
'''Difficulty''' Medium
 
''' Description'''
 
The goal of this project is to extend Libreswan's support for FreeBSD adding missing functionality and tests.
 
The deliverable are:
* a gap analysis to identify Libreswan features missing on FreeBSD
* modifications to Libreswan adding at least two missing features
* testsuite additions demonstrating the added features
 
 
= Re-port the libreswan code for Microsoft Windows =
 
'''Required Skills:''' Windows / PowerShell, C, python, shell scripting


'''Libreswan Mentors''': Andrew Cagney, Antony Antony
'''Libreswan Mentors''': Andrew Cagney, Antony Antony


'''Project size''' 170 hours


It would need to update/extend the PF_KEY API currently defined. See programs/pluto/kernel_*
'''Difficulty''' Medium - Hard


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


'''Required Skills:''' BSD networking, C, python, shell scripting
Re-add the Windows IPsec stack support in libreswan using the Windows "native" powershell ipsec commands, such as Set-VpnServerConfiguration and Set-VpnServerIPsecConfiguration. While the libreswan developers have used Windows, they are not experts in Windows and the student will have to work fairly
indepdently in finding out how to drive the powershell commands from a libreswan Windows binary.


'''Libreswan Mentors''': Andrew Cagney, Antony Antony
The deliverable is a compile of libreswan that can be used to setup VPN connections that runs on Windows
 
 
= iOS VPN app for libreswan to configure native IPsec stack =
 
'''Required Skills:''' Xcode / MacOS programming,  C, python, shell scripting
 
'''Libreswan Mentors''': Paul Wouters


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.
'''Project size''' 350 hours
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.


'''Difficulty''' Hard


= Re-port the libreswan code for Microsoft Windows =
''' Description'''


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.
Create an iOS app to help create/tune/manage IPsec VPNs on an iphone. This involves reading the Apple Documentation for the IKEv2 VPN API calls and
on how to add personalized VPNs via the app to the iOS system.


The goal would be to support Opportunistic IPsec and/or build a replacement IKEv2 VPN client.
The deliverable is an iOS app that can add/remote VPN connections to an iphone.


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


= Cleanup / maintenance / code deduplication =
= Cleanup / maintenance / code deduplication =
'''Required Skills:''' Windows / PowerShell, C, python, shell scripting
'''Libreswan Mentors''': Tuomo Soini, Paul Wouters
'''Project size''' 170 hours
'''Difficulty''' Easy
''' Description'''


Everyone wants features, no one wants maintenance :)
Everyone wants features, no one wants maintenance :)
Line 226: Line 249:
Similarly, a code cleanup could be started to remove KLIPS support (but not PF_KEY support)
Similarly, a code cleanup could be started to remove KLIPS support (but not PF_KEY support)


= Detect kernel algorithms supported for IPsec =
The deliverable here are a number of commits that clean up various items in our code base
 
 
= Implement IKEv2 Group Key Management =
 
[ this project is not ready yet, as the draft has not seen much development lately ]
 
Add Group Key Management as per https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2
 
 
= Use of a VPNonly namespace =
 
'''Required Skills:''' systemd, kernel name-spaces, podman/toolbox, C, python, shell scripting
 
'''Libreswan Mentors''': Tuomo Soini, Paul Wouters
 
'''Project size''' 350 hours
 
'''Difficulty''' Hard
 
''' Description'''
 
A fedora or debian/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.
 
This idea requires some brainstorming and coming up with an architecture that works to support these kind of namespace handlings. This project requires
a lot of independent thinking of the student, and a wide generic knowledge of Linux on the dekstop and a lot of knowledge on systemd and virtualization.
 
The deliverable is a Linux desktop where an application such as firefox can be started in a vpnonly namespace.
 
 
= Implement the INTERNAL_DNSSEC_TA support =
 
[ project currently not available ]
 
See https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-16
 
= Integrate libreswan into OSS-Fuzz project =
 
'''Required Skills:''' C, code reading
 
'''Libreswan Mentors''': Tuomo Soini, Paul Wouters
 
'''Project size''' 350 hours
 
'''Difficulty''' Hard
 
''' Description'''


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.
[https://google.github.io/oss-fuzz/ 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.


See also: xfrm_probe_algs(), init_pfkey() and kernel_alg_register_pfkey()
More about fuzz testing, fuzzing engines and OSS-Fuzz can be found on OSS-Fuzz project page.


Related, we might want to trigger some crypto algorithm modules to load, but can we?
There are some related open source projects that can be used as an example of successful project integration into OSS-Fuzz, e.g.:


(We hope to know a bit more after the Linux IPsec summit on what would be involved for this work time)
- strongswan: [https://github.com/google/oss-fuzz/tree/master/projects/strongswan project section on OSS-Fuzz] and [https://github.com/strongswan/strongswan/tree/master/fuzz fuzzing targets].


= Implement draft-yeung-g-ikev2 IKEv2 Group Key Management =
- Mozilla's NSS: [https://github.com/google/oss-fuzz/tree/master/projects/nss project section on OSS-Fuzz] and [https://github.com/nss-dev/nss/tree/master/fuzz fuzzing targets].


Add Group Key Management as per [https://tools.ietf.org/html/draft-yeung-g-ikev2-13 draft-yeung-g-ikev2]
The deliverable is a test case inside the libreswan testing infrastructure that runs a number of fuzzing tests.

Latest revision as of 21:42, 12 August 2022

Previous Student projects

See Student projects for completed student projects (sponsored by GSoC and others).

Proposal submissions

Submissions must comply to all GSoC rules. We strongly urge any interested students to read up on the previous student projects and the below project ideas. It is not required to big one of these ideas - we welcome new ideas too! Submissions that tend to be accepted and successful are those that show from the start that the student is putting in the time to understand the concepts. You don't have to be an expert already, and you can contact us at gsoc at libreswan dot org for questions. Mentors like to see students that have put in some work to understand and try things. It is the only reliable metric we have for new people to indicate how serious they are to take on a project for the summer. If implementing an RFC, read the RFC and ask us any questions you have. Have a look at the code base structure in general, look at our testing/ directory. If you don't have VPN/IPsec experience, we are happy to give you a client configuration to gain experience using libreswan to a real VPN server.

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

Project size 350 hours

Difficulty Medium

Description

There is a demand to monitor for status changes and reconfiguration commands using a varlink API. The varlink API is kind of like a successor to dbus. It would replace the ipsec whack command that is too expensive to fire up all the time. The whack command is also a "pull" method whereas the varlink API will be a push method to anyone who wants (and is allowed) to listen on the right channel.

Additionally, another varlink channel will be used to send commands to the daemon, which are currently done by the ipsec whack command (or if configurations are used, via ipsec addconn into whack commands). The idea here is that varlink is an existing channel where anyone (with permission) can send commands to the pluto daemon (add connection, up connection, down connection, etc)

The student is expected to first get an idea of what is involved in adding and bringing up a VPN tunnel. Then the "status channel" needs to be defined for varlink messages, and then the pluto code needs to be updated to send varlink status messages over this channel.

The "ipsec whack --status" command should then be rewritten to use the new varlink channel and provide the status information.

Once that is working, the command channel can be specified for varlink for per connection commands (add,up,down,delete,status). This would replace the "ipsec whack --name connection" code and within the pluto daemon, the responses would go to the varlink channel instead of the regular whack fd.

If there is enough time, whack commands that work on the global daemon state, and not on a single connection, can be implemented as well.

The deliverable would be a varlink enabled libreswan pluto daemon and a varlink enabled ipsec whack command.


Implement static IP assignments and support for Radius / AAA backend

Required Skills: C programming, writing documentation and test cases

Libreswan Mentors: Paul Wouters, Tuomo Soini

Project size 170 hours

Difficulty Easy to Medium

Description

Currently, the libreswan pluto IKE daemon can only use a builtin addresspool= range. There is demand for handing out static leases for specific users. A new file similar to ipsec.secrets should be supported that contains a list of IDs and IP addresses to hand out. This should override the regular addresspool= IP allocation.

This solution does not scale very well though and is not compatible with common IP address requests via protocols such as Radius or Diameter. For the second part of this project, the student implements a call to ask a Radius/Diameter server for an IP address based on the received IKE ID. This solution replaces the addresspool= support entrely.

The deliverable would be two methods for assigning static IP addresses in the libreswan pluto daemon to connecting clients.


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

Project size 170 hours

Difficulty Easy to Medium

Description

IPsec policies can be installed in the kernel to be "on demand". Once a packet hits the IPsec subsystem, if it matches a %trap policy, the userland IKE daemon is informed about this so it can initiate an IKE connection to the target destination. Currently, all the installed %trap policies use a "reqid" number of 0. This means that when the IKE daemon receives the message from the kernel, it has to do its own source/dest based lookup to determine which connection got triggered. The goal of this project is to change this by using unique reqid numbers for each connection with a %trap policy. The complication arises from connections with %trap policies that are part of a group. These connections clone themselves into new connections. The clones cannot have the same reqid, so these policies need to be modified before being resend to the kernel. While the coding is likely to be straightforward, getting to understand the connection structure and kernel structures involved will be the harder part.

The deliverable is a pluto daemon that sends and receives unique reqids from kernel messages and that uses these reqids for its connection matching mechanism.


Implement Announcing Supported Authentication Methods in IKEv2

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

Libreswan Mentors: Andrew Cagney, Paul Wouters

Project size 170 hours

Difficulty Easy

Description

Implement the IKEv2 extension for multiple supported authentication modesls, see https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-auth-announce

Currently, both peers will present their authentication method independently. These authentication methods might not be the same. Depending on the received authentication method support received from the peer, adjust the authentication if multiple are supported. Additionally, if the authentication method uses certificates, filter the allowed authentication methods based on the algorithms used in the certificate chain. The internet standards draft is still in the early stage of discussion at the IETF, so someone implementing this might find issues with the draft protocol for which they would need to communicate with the author of the draft to resolve.


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

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

Libreswan Mentors: Andrew Cagney, Paul Wouters

Project size 350 hours

Difficulty Hard

Description

See RFC 4555 and https://www.ietf.org/mail-archive/web/ipsec/current/msg11844.html on details of how this should work. The reason this project is marked as hard is that there is a lot of userland <-> kernel communciation and changes that need to be sync'ed between the kernel and the userland states.

The deliverable would be a pluto daemon that can generate and respond to MOBIKE requests and a few test cases to show the failover procedure.


Support for RFC 6290: Quick Crash Recovery

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

Libreswan Mentors: Andrew Cagney, Paul Wouters

Project size 170 hours

Difficulty Easy

Description

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.

The deliverable is a test case that demonstrates the implemented RFC is working properly.


Support for RFC 7670: Generic Raw public key support

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

Libreswan Mentors: Andrew Cagney, Tuomo Soini

Project size 350 hours

Difficulty Hard

Description

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.

Extend Libreswan's support for FreeBSD

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

Libreswan Mentors: Andrew Cagney

Project size 170 hours

Difficulty Medium

Description

The goal of this project is to extend Libreswan's support for FreeBSD adding missing functionality and tests.

The deliverable are:

  • a gap analysis to identify Libreswan features missing on FreeBSD
  • modifications to Libreswan adding at least two missing features
  • testsuite additions demonstrating the added features


Re-port the libreswan code for Microsoft Windows

Required Skills: Windows / PowerShell, C, python, shell scripting

Libreswan Mentors: Andrew Cagney, Antony Antony

Project size 170 hours

Difficulty Medium - Hard

Description

Re-add the Windows IPsec stack support in libreswan using the Windows "native" powershell ipsec commands, such as Set-VpnServerConfiguration and Set-VpnServerIPsecConfiguration. While the libreswan developers have used Windows, they are not experts in Windows and the student will have to work fairly indepdently in finding out how to drive the powershell commands from a libreswan Windows binary.

The deliverable is a compile of libreswan that can be used to setup VPN connections that runs on Windows


iOS VPN app for libreswan to configure native IPsec stack

Required Skills: Xcode / MacOS programming, C, python, shell scripting

Libreswan Mentors: Paul Wouters

Project size 350 hours

Difficulty Hard

Description

Create an iOS app to help create/tune/manage IPsec VPNs on an iphone. This involves reading the Apple Documentation for the IKEv2 VPN API calls and on how to add personalized VPNs via the app to the iOS system.

The deliverable is an iOS app that can add/remote VPN connections to an iphone.


Cleanup / maintenance / code deduplication

Required Skills: Windows / PowerShell, C, python, shell scripting

Libreswan Mentors: Tuomo Soini, Paul Wouters

Project size 170 hours

Difficulty Easy

Description

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)

The deliverable here are a number of commits that clean up various items in our code base


Implement IKEv2 Group Key Management

[ this project is not ready yet, as the draft has not seen much development lately ]

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


Use of a VPNonly namespace

Required Skills: systemd, kernel name-spaces, podman/toolbox, C, python, shell scripting

Libreswan Mentors: Tuomo Soini, Paul Wouters

Project size 350 hours

Difficulty Hard

Description

A fedora or debian/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.

This idea requires some brainstorming and coming up with an architecture that works to support these kind of namespace handlings. This project requires a lot of independent thinking of the student, and a wide generic knowledge of Linux on the dekstop and a lot of knowledge on systemd and virtualization.

The deliverable is a Linux desktop where an application such as firefox can be started in a vpnonly namespace.


Implement the INTERNAL_DNSSEC_TA support

[ project currently not available ]

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

Integrate libreswan into OSS-Fuzz project

Required Skills: C, code reading

Libreswan Mentors: Tuomo Soini, Paul Wouters

Project size 350 hours

Difficulty Hard

Description

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.

The deliverable is a test case inside the libreswan testing infrastructure that runs a number of fuzzing tests.

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