[strongSwan-dev] Embedded application integration - best practice

[Martin Willi]

Hi,

> 1.) Use the normal config files and invoke the ipsec script (no way of
> getting indications?).

This is one option, but probably the worst. The protocol between ipsec
and the daemon is designed for command line invocation, not to write an
API. Parsing the status output is pain, and it probably will break with
every release.

I won't recommend this approach, unless you want support for IKEv1
setups via pluto.

> 2.) Write a Charon plugin (like the NM plugin, I quite like this approach).

Thats the clean solution and very flexible. You can provide the
mechanisms exactly as you need them. While we have different plugins you
can have a look at, this will require some time to get in touch with
daemon internals and APIs.

> 3.) Use DBUS and the NM plugin (I have no idea about DBUS).

The NM DBUS API is far from ideal, as it is designed for NM, and not for
strongSwan. It is very limited to the specific needs of NM initiated
connections.

We have more generic plugins, such as the SMP plugin. SMP is an XML
based plugin for control and configuration functions via a Unix socket.
It is not feature-complete and we haven't put much work in it during the
last years. It is usable, but probably would require some daemon-side
work.

Configuration-wise, we also have sql based plugins. These are very
generic and render the schemas relatively complex. But it might be a
good (if not too complicated) example how to integrate your own
configuration backend.

> 4.) Re-use the Stroke API (probably not a good idea).

No, stroke has been designed to work with ipsec.conf configurations, and
not with IKEv2 specific concepts. Further, all you get back via this
interface is ASCII, exactly as in 1.).


Assuming you go for 2.):

> 1.) Programatically configure StrongSwan (Charon).

You would have to instanciate connection objects, ike_cfg_t, peer_cfg_t,
child_cfg_t. To provide connections as responder, serve these configs
via backend_t. To initiate connections, pass them to the controller_t.

> 2.) Be able to up/down connections.

The simplest way to control the daemon is through the controller_t
helper class.

> 3.) Get indications when connections go down (e.g. through DPD).

Implement the listener_t interface (or some methods of it) and register
it to the bus_t. 

> What are the GPL implications of writing a plugin, I assume it would
> also become GPL?

Yes, if you distribute binaries, you'll have to provide your plugin
code, too. Contact Andreas if you're interested in alternative licensing
schemes.

Regards
Martin