[strongSwan-dev] Embedded application integration - best practice

[Ian Hailey]

Hi Martin,

Thanks for your comments.

I have been able to write a plugin to manage the control and listener aspects of Charon but see that adding configuration support would require significant effort. In fact the Stroke socket API would provide all that I need aside from the listener feedback, do you see this ever becoming a public API at some point in the future?

Regards,

Ian.

On 5 Mar 2010, at 08:24, Martin Willi wrote:

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