Hi Neale, Sure, it sounds ok. If I end up having trouble integrating with the new APIs I can revisit the issue and figure out if there's some enhancement needed at that point.
Thanks, -Matt On Mon, May 27, 2019 at 7:01 AM Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > 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 <nranns= > 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 > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [mgsm...@netgate.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13175): https://lists.fd.io/g/vpp-dev/message/13175 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] -=-=-=-=-=-=-=-=-=-=-=-
