Timo, > This seems to be where 'vici' does already a majority of the work.
> 1) Send notifications on SA creation/deletion. Should simple to add as > list-sa already does the tedious work of serializing the information. Re-using that code certainly would make sense. Registering a listener to the bus is rather simple. Then you'd need to add a vici event, and allow clients to register for it. > Would be practical if x509 cert was sent automatically in the > notification too. Doable, probably we should make that optional, as this will be a lot of data, especially if you include CA certificates as well. > 2) A way to request instantiation/termination of transport mode > "right=%any" connection with specific value for 'right'. Needed to > bootstrap spoke-hub connections (and hub-hub depending on config). If you have the associated up/down events for IKE_SAs, you may cache unique connection identifiers in the client and use the existing termination command. Adding an additional remote IP selector to the existing terminate command is not complicated, either. > 3) Additional 'connection configuration origin' field. So that dmvpn > and swanctl can manage their set of configs without deleting each > others conn entries on reload. I had this in mind during the initial protocol design, but didn't implement it yet. Certainly something we need in the future. My idea is to introduce namespaces, where all the configuration related things are attached. You then can create or select a specific namespace to work in. Such an extension is not that trivial, and probably requires changes to the vici core message handling. I'll see if I find time to implement something like that. > 4) Way to influence CFG_REQUEST/CFG_REPLY/CFG_SET during negotiation. > This would be required for full Cisco compatibility as they use those > to exchange the IP-configuration. Though, as first step, I plan to be > defining those in the x509 certificate. If that is a pure Mode Config exchange in pull or push mode, I think that is mostly there in the vici_attributes virtual IP and attributes backend. Create a pool referenced by your connection, and add attributes to it. You might need additional keywords for custom attributes, but that should be trivial to implement. We currently negotiate attributes only on connections assigning a virtual IP; not sure how this affects the DMVPN scenario. Regards Martin _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
