Hi Vratko, From: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpo...@cisco.com> Sent: Tuesday, June 28, 2022 3:50 PM To: vpp-dev@lists.fd.io Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Oginski, GabrielX <gabrielx.ogin...@intel.com> Subject: RE: [vpp-dev] Community meeting today
> The closest thing for strongswan to issue – at least in Linux – is the ip > xfrm command That is why you need to create a new plugin for SSWAN (in SSWAN repo). > To do so we only have to refer a few header files in our code Are those GPLv2+ header files? [FAN: Yes some files are GPLv2+ ] > Also it will be unsafe to do so When VPP needs to do something safely (e.g. when creating memif) it uses Unix Domain Socket (UDS). > All ideas welcome. I guess creating a quick and dirty "protocol" would not be difficult, for example using gRPC. The hard part is choosing transport that makes sense from both security and performance point of view, and defining message format that can be evolved (as in VPP API process; but maybe also from interoperability point of view, think protocol version negotiation). I bet SSWAN developers would have even better ideas on how to integrate their GPLv2+ core with third party (Apache-2.0) dataplanes. > translating from that standard communication channel to VPP calls The other extreme is to consider VPP binary API over UDS "standard enough". In that case, no translation is needed on VPP side, just a SSWAN plugin. [This is exactly what we are aiming for – no VPP translation but a SSWAN plugin that handles SSWAN->VPP translation] I mean, VPP Ipsec API messages are Production and versioned, so no VPP version related surprises should happen. Not sure SSWAN developers would want to maintain such a specific plugin. Also not sure SSWAN CI is flexible enough for system tests with VPP in the loop, but the VPP side can be mocked when not testing with real traffic. [For now we want to focus on SSWAN 5.9.6 and will maintain for future SSWAN releases] As you described, that plugin can sit in a separate (GPLv2+) repository, but building and testing it will be even trickier than in SSWAN repo. And finally, that "separate repository" can be just extras subdirectory of VPP repo, which is basically your proposal (except I propose API oved UDS to avoid license issues). System testing (with both SSWAN, VPP, and the new plugin code in the loop, and real traffic) will not be easy, but doable in fd.io CSIT (assuming the new plugin has packages uploaded to fd.io packagecloud, or some other standard artifact repository CSIT can download from). [We will have to seek help from you for that later thanks a mil in advance!] Vratko. From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Fan Zhang Sent: Wednesday, 2022-June-15 15:18 To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpo...@cisco.com<mailto:vrpo...@cisco.com>>; Oginski, GabrielX <gabrielx.ogin...@intel.com<mailto:gabrielx.ogin...@intel.com>> Subject: Re: [vpp-dev] Community meeting today Hi Vratko, It is a great idea as it is non-intrusive and make both applications not dependent to each other. However I cannot find a way (yet!) to make it work as linux-nl The closest thing for strongswan to issue – at least in Linux – is the ip xfrm command, which I believe having no hooks to capture. Also it will be unsafe to do so – imagine a malware process was hiding somewhere to capture all SAs. What we are proposing is * SSWAN supports externally linking a plugin, which is how it work on different OS. * To do so we only have to refer a few header files in our code, and generate a .so file in VPP scope. * In our code we will translate a SSWAN that translate SA management/routing cmds to VPP CAPI calls. * When the .so file is compiled – we may provide a script, or user manually copy the .so file to the location SSWAN stores plugins. * Rebooting SSWAN next time the plugin should be enabled and active. However I cannot think of a way to change make test for this work: * We need a strongswan application up and running and capable of adding plugin. * I wouldn’ say we cannot, but will be hard to use scapy’s ikev2 (as we are adding support to strongswan and we targets data path validation only). To test the implementation we can use similar way as existing vpp/extras/strongswan/run.sh, but this time we focus on data path checking. All ideas welcome. Regards, Fan From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io Sent: Tuesday, June 14, 2022 5:57 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Community meeting today > a way to make VPP IPsec work better w/ StrongSwan As Damjan said, it would be a control plane adapter. I guess it is also a management plane adapter (translating higher level commands into VPP API commands). From existing management plane adapters, it reminds me of linux_nl. I read it listens to netlink messages. I like the approach of listening to more standardized messages coming over more standardized communication channel (as opposed to creating a plugin for Linux kernel to call VPP binary API directly). I read StrongSwan can work on Windows (not just Linux), so it has to have some abstraction of dataplane management. What you can do is to create a "remote/userspace dataplane" plugin (contribute to StrongSwan repo, using their GPLv2+) that translates from StrongSwan internals into a standard communication channel (no idea which one, maybe some user-defined netlink protocol), and then on the other side you will have a plugin similar to linux_nl (VPP repo, Apache2 license) translating from that standard communication channel to VPP calls (direct C calls, or binary API). This way you can test the VPP plugin in make test (assuming the standard communication channel is not too exotic for Python to handle) and also StrongSwan plugin in their CI. Vratko. From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Fan Zhang Sent: Tuesday, 2022-June-14 10:39 To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] Community meeting today Hi, I was wondering if we can squeeze in a quick topic to discuss in today’s community call? We are working on a way to make VPP IPsec work better w/ StrongSwan and want to discuss the upstream plan of it. Regards, Fan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21589): https://lists.fd.io/g/vpp-dev/message/21589 Mute This Topic: https://lists.fd.io/mt/91745080/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
