Hi Matt, I’m glad the change is not a problem for you.
The trouble with passing partial rather than full information in the update, is that I cannot always tell what’s being updated. Consider the 3 phase re-key, the user is adding another receive SA, how can I tell if that’s the addition of a new SA or the replacement of the existing SA (as it would in the one phase re-key). I’d need more flags to say ‘this is an addition update not a replace’ – and I think it starts getting more complicated. The control plane needs to maintain all the data required to programme VPP, so it can replay should VPP crash, so having download the full update each time is fine IMO. Does that sound reasonable? Regards, neale De : Matthew Smith <mgsm...@netgate.com> Date : mercredi 22 mai 2019 à 17:50 À : "Neale Ranns (nranns)" <nra...@cisco.com> Cc : "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Objet : Re: [vpp-dev] RFC: IPSec Tunnel remodel Hi Neale, We (Netgate/TNSR) use strongswan for IKE with a module that connects to the VPP binary API to manage IPsec tunnel interfaces. The API changes mostly look fine from my perspective. It won't be that much different than what we do now. Currently we create an IPsec tunnel interface before any IKE negotiation has taken place and populate dummy values for SPIs and other fields that are not known yet. Then as the IKE daemon negotiates SAs, we create them in VPP and associate them to the tunnel interface. This means that for our purposes, there is not a change from making 1 API call to 4 calls. We currently make 5 calls in the process of getting a tunnel operational (create tunnel interface, create SA * 2, set SA on tunnel * 2). One addition to your patch that would be useful is support for setting a new SA on a tunnel interface in only one direction at a time. The IKE daemon executes callbacks to install the inbound and outbound SAs separately and it's easier to be able to handle each of them as their own atomic operation than it is to store the data for a new SA for some amount of time until you find that the SA for the other direction has been added and then propagate both of them into VPP at the same time. If it were possible to send a ipsec_tunnel_protect_update message where tunnel.sa_out ==~0 causes only the inbound SA to be updated or tunnel.n_sa_in == 0 causes only the outbound SAs to be updated, this would make transitioning to the new calls more straightforward. At least for me :) Thanks, -Matt On Mon, May 20, 2019 at 11:59 AM Neale Ranns via Lists.Fd.Io<http://Lists.Fd.Io> <nranns=cisco....@lists.fd.io<mailto:cisco....@lists.fd.io>> wrote: Hi VPP-IPSec-ers, I'd like to gauge comments on this article: https://wiki.fd.io/view/VPP/IPSec and the proposal for the IPSec tunnel re-model. The associated patch is: https://gerrit.fd.io/r/#/c/18956/ thanks, Neale -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13097): https://lists.fd.io/g/vpp-dev/message/13097 Mute This Topic: https://lists.fd.io/mt/31687572/675725 Group Owner: vpp-dev+ow...@lists.fd.io<mailto:vpp-dev%2bow...@lists.fd.io> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [mgsm...@netgate.com<mailto:mgsm...@netgate.com>] -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13155): https://lists.fd.io/g/vpp-dev/message/13155 Mute This Topic: https://lists.fd.io/mt/31687572/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
