Project

General

Profile

Feature #3653

Is there any possibility to pass any non-standard parameters for tunnels (ike or child sa) for use by custom plugin?

Added by Michał Skalski 10 months ago. Updated 10 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Start date:
07.12.2020
Due date:
Estimated time:
Resolution:

Description

Is there any possibility to pass any non-standard parameters for tunnels (ike or child sa) for use by custom plugin?

I mean is it possible to pass some flags, integers or strings, which can be later examined by some custom charon plugin?

I made some plugins some time ago for my company internal usage which has to perform some action based on
ike sa established (like sending or not configured Vendor ID payload) and as I decided not to touch ike_cfg_t,
it was configured like any other configuration option from strongswan.conf:

force_extensions = lib->settings->get_bool(lib->settings, "%s.plugins.vendorid.%s", force_extensions, lib->ns, vid_data->force_setting);
if( ike_name )
    force_extensions = lib->settings->get_bool(lib->settings, "%s.plugins.vendorid.connections.%s.%s", force_extensions, lib->ns, ike_name, vid_data->force_setting);

It works, but it's far from optimal solution.

Are there any other solutions?

On the other hand all configuration backends (vici, stroke or SQL) basically work on transparent strings, so it would be matter of
adding some generic variable in ike_cfg_t, peer_cfg_t or child_cfg_t (with list of strings, or something like
extra_parameters in ipsec.conf) passing it and and storing them untouched and used only by plugin interested in.

Do you think it would be valuable functionality in strongswan?
Would you like to consider to merge such functionality to basecode, if enough quality Merge Request I would propose?

Thanks, Michał

History

#1 Updated by Michał Skalski 10 months ago

Another possibility would be some way of extending, by means of some registration functions (like i.e. for registering proposal tokens) for configuration options accepted by ike_cfg_t, peer_cfg_t or child_cfg_t to be called on receiving configuration from stroke or vici, that way extra parameters could be stored in plugin only.

Another solution would be extending interface listener_t with functions called during connections loading.

What do you think about it?

#2 Updated by Tobias Brunner 10 months ago

  • Status changed from New to Feedback

Is there any possibility to pass any non-standard parameters for tunnels (ike or child sa) for use by custom plugin?

I mean is it possible to pass some flags, integers or strings, which can be later examined by some custom charon plugin?

No, currently not.

It works, but it's far from optimal solution.

Something like that is what we generally recommend for such use cases (e.g. the p-cscf plugin is enabled like that). Seems simple and practical enough. Another option is to store a list of connection names for which something should happen (like the reinject option of the forecast plugin).

On the other hand all configuration backends (vici, stroke or SQL) basically work on transparent strings, so it would be matter of
adding some generic variable in ike_cfg_t, peer_cfg_t or child_cfg_t (with list of strings, or something like
extra_parameters in ipsec.conf) passing it and and storing them untouched and used only by plugin interested in.

Yes, that might be something we could consider adding in the future. Note that there is currently some on-going work to add metadata to packet_t/message_t, which might result in some generic metadata framework (not sure yet, could also be quite simple). Unknown settings in swanctl/vici are currently rejected, so I guess this would have to be configured via a separate section for generic key/value pairs for each config object (complicated by the blurry split between ike-/peer-config, also see below).

Also note that stroke is deprecated and will be removed sooner or later (it would complicate such things because it merges configs and does not have a clear hierarchical structure like vici).

Do you think it would be valuable functionality in strongswan?
Would you like to consider to merge such functionality to basecode, if enough quality Merge Request I would propose?

Sure, but always depends on the actual functionality, its side-effects and the quality of the code (the bar is high, also see contributions).

Another possibility would be some way of extending, by means of some registration functions (like i.e. for registering proposal tokens) for configuration options accepted by ike_cfg_t, peer_cfg_t or child_cfg_t to be called on receiving configuration from stroke or vici, that way extra parameters could be stored in plugin only.

Existing keywords are currently not registered globally (so there would be some potential for conflicts) and how config objects are created (e.g. what settings/values are mapped to what config object/property) is pretty much up to the backends/plugins (some even create them on the fly when required). The context for the plugin might also be unclear (ike/peer/auth/child config, possibly one or more names - in swanctl.conf, child names only have to be unique within connections).

Whichever approach, there is also the blurry split between ike- and peer-config settings and the resulting objects to consider. In particular as responder, because ike-config objects there might not correspond to the "correct" peer-config to which a switch happens later based on the identities/authentication (this connection-switching, which can occur multiple times, could also affect the peer-config objects). Although, that's similar when storing options in strongswan.conf (the name can change) or when the plugins would be storing the settings (they'd have to look up the correct context, which can change for a particular IKE_SA).

Another solution would be extending interface listener_t with functions called during connections loading.

Could be tricky because config objects might be generated on the fly (it's what e.g. the sql plugin does). And passing data to the listeners in a useful way could be complicated too.

Also available in: Atom PDF