[Swan-dev] Helsinki meetup last week

Paul Wouters pwouters at redhat.com
Mon Jun 10 17:04:01 EEST 2013


Last week we had a gathering of libreswan/openswan people in Helsinki.

A handful of core developers where there with me: Tuomo, Antony, Kim,
Mika, and Hugh Redelmeier. The week was very productive in sharing
knowledge about various parts of the swan software.

We talked about various things, and although we did not set a roadmap we
reached agreement on various important parts for that roadmap.


- Uncrustify

We finished using the uncrustify tool to bring the source code in line
with the Kernel Coding Style. It was decided to have no exceptions
against this style, so that existing software tools would have the
highest change of supporting it fully. We did a new libreswan release
3.4, and the _only_ change to 3.3 is the uncrustify changes. We found a
few bugs and wrote some patches which were submitted to uncrustify
upstream. We placed the final uncrustify.cfg with a README file in the
git tree in docs/uncrustify. Flamewars and emotional discussions were
avoided successfully and everyone is in a reluctant agreement about the
new style.

- Testing harness

Paul and Antony explained and demonstrated how to use the testing
harness in the hope that it will become a standard procedure for people
run on their laptop before submitting code. For the presentation layer,
it was agreed to use a json/javascript interface so the git repository
can be exported into a web tree to get instant clear html reports.

- Crypto boundary and certification

Paul talked about the issues of certification and crypto boundaries.
Everyone agreed to support efforts to concentrate the crypto functions
and agreed that splitting up files and functions is the right way
forward, and that most of this should be completed within the next few
months.

- ECC support for ESP and IKE

Everyone agreed ECC support as listed for RFC4869 should be added to
IKEv1 and IKEv2, using ECC_SUPPORT=false|true in Makefile.inc. Ideally,
no recompile should be needed if the NSS package is updated to one that
enabled ECC support.


- Openssl and /etc/ipsec.d support

The /etc/ipsec.d support is used for the non-nss version of libreswan to
load certificates, CAcerts, CRLs and private keys. Support code for that
lives in lib/libswan/. This code is still used when NSS is used. It
contains old custom code for PEM and ASN.1 support. It was agreed that
we will bump the major version of libreswan once we disable these
alternative locations for these files when NSS support is enabled. The
code will not be removed, but placed within an #ifndef NSS (or #ifdef
OPENSSL) define, as the embedded people really dislike nss for its size.
While we currently do not support openssl, some embedded people (eg
David) will work on that support sometime in the future. For NSS,
we will write some more 'ipsec import' type helper scripts to assist
people from migrating their content in /etc/ipsec.d/ into the NSS database.

- Linux Secure Tunnel interface support

Support for this will be added, but implementation details will be
decided on later on after some people have experimented with this. It is
expected to be mostly related to _updown.netkey scripting. This option
should allow link failover and routed based VPNs.

- Logging cleanup

Everyone hates the large amount of logging functions and it was decided
to rewrite it so that at most one or two of these are left. This might
involve moving some lib/libswan or lib/libpluto parts back into
programs/pluto.

- pluto and DNS(SEC)

pluto currently does limited DNS lookups (for dyndns purposes). It is
hard to implement a "just in time resolve" strategy because you don't
always know when a loaded policy is required versus. Support for
understanding and using TTLs was agreed on, to better support dyndns
scenario's. Whether pluto should use libunbound for DNSSEC, as it does
now, or whether it should just check the (local) resolver for the AD bit
was not fully answered yet.

- retransmit timings

Our retransmit values were agreed to be too old for today's standards.
New values were not yet agreed upon and will be further discussed. These
options should be global with a per-conn override.

- Opportunistic Encryption

It was decided that the old IP based OE system has not been used in
years and should really be removed, with the argument being that it can
always be revived from git history if needed. But since proposals for a
new OE involve DNS and/or sssd/ActiveDirectory moduels external to
pluto, there seems to be no reason for the complicated existing code to
remain inside pluto (even though our cypherpunk hearts don't want to
remove it)

- dynamic interface / IP address / NM support

It was briefly discussed, and everyone agrees it needs to be redone, and
use kernel netlink, it is something that's not at the top of our list.

- taproom / tclcallout

As with OE, this has bit rotted and fails to compile and has not been
used. It was agreed to be removed, as the git history will always
contain the code to be restored if required in the future.

- ipsec auto --status / eroute

A new much more user friendly version should be added, and these should
be left for compatibility.

- IKEv2

This code urgently needs more testing, more standard features need to be
supported, and the recently found bugs need to be addressed. Ideally,
the tree should be cleaned up as well to allow compiling with just IKEv1
or IKEv2, cmopletnig disentagling includes for both versions
and translation tables.

- website and user docs

Agreed this needs lost of work and is urgent. Focus is on producing
textual documentation quickly (git or mediawiki) and convert to web. For
developers, the important structs and the state machine should be
clearly documented.

- NSS errors

NSS errors, due to missing or bad certs, and nss error numbers, need to
be fixed, extended and made a lot clearer. We often fail "silently"
something is wrong with our certificates.

We talked about many more things and in general had a very good time
getting to know each other in real life. Depending on the progress made,
we are looking at doing this again in 6-12 months, possible in Toronto.

Paul


More information about the Swan-dev mailing list