Ok! So what do you think if then we were to also disallow applying the ACL that doesn't exist yet ?
It feels like it would be a matching symmetric behavior "from the other side". ? --a On 16 Jun 2017, at 15:38, Luke, Chris <chris_l...@comcast.com> wrote: >> From: Marco Varlese [mailto:marco.varl...@suse.com] >> Sent: Friday, June 16, 2017 9:23 >>> On Fri, 2017-06-16 at 15:12 +0200, Andrew 👽 Yourtchenko wrote: >>>> On 6/16/17, Marco Varlese <marco.varl...@suse.com> wrote: >>>> >>>>> On Thu, 2017-06-15 at 14:22 +0200, Andrew 👽 Yourtchenko wrote: >>>>> >>>>> After a bit more thinking - there is a way that should take care of both: >>>>> >>>>> 1) What Chris wrote: have consistent behaviour with non-existent >>>>> ACL as if the ACL matching fell off the end of the ACL: if an >>>>> empty ACL is referenced, treat it as if it had entries but none of >>>>> them had matched. Then we still hit the "default deny" if none of >>>>> the applied ACLs match, and drop the packets - so it will be logical. >>>>> >>>>> 2) What Marco wrote: when deleting an already referenced ACL, >>>>> unapply it from all the places where it is applied. >>>>> >>>>> It's a change in the behaviour in that the current behaviour is to >>>>> have the empty ACL act as if it was "deny any any", and block the >>>>> matching even if there is another ACL after it - but on the other >>>>> hand this would take both viewpoints in mind... >>>> I think this approach would still leave the system in an inconsistent >>>> state: >>>> an >>>> interface is basically assigned an ACL which does not exist in the system. >>>> Also, the risk I see is if I later on create an ACL with the >>>> previously used index then an interface would see that ACL being >>>> applied automatically (since it's referenced). However, I may not >>>> want to have that ACL assigned to that particular interface. >>>> Correct? >>>> >>>> I think that the "deletion" of an ACL could see one of the two >>>> behaviours >>>> below: >>>> 1) the deletion of an ACL should be DENIED if that ACL is assigned >>>> to any interface (probably the easier and safer approach); >>>> 2) the deletion of an ACL should see a CASCADING effect onto the >>>> interfaces which would be "cleaned up" of any references to that >>>> ACL; >>>> >>> >>> Right, the (2) was what I was trying to suggest to do... >>> >>>> >>>> I think (1) is a very good way of solving the initial problem since >>>> it works nicely if you manage VPP directly (e.g. via command-line) >>>> and if you use a controller. In the latter, the controller can react >>>> on the "error" returned by the acl_del API because that ACL is >>>> assigned somewhere. >>>> >>> >>> ...but the (1) is another good option to me. >>> >>> So it seems we are converging on (1) ? >> I would go with (1)... > > I feel I have a slight preference for this (1) also; In general I don't like > the implicit actions such as in (2). > > Chris > >>> >>> --a >>> >>> >>> >>>> >>>> >>>> Cheers, >>>> Marco >>>> >>>>> >>>>> >>>>> What do you think ? >>>>> >>>>> --a >>>>> >>>>>> On 6/9/17, Andrew 👽 Yourtchenko <ayour...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Assuming the only change is to effectively have >>>>>> "unbind_acl_from_everywhere; delete_acl" instead of >>>>>> "delete_acl", maybe it would be best to tackle that post-17.07 >>>>>> with a separate API message acl_del_and_unbind or similar ? >>>>>> >>>>>> I feel a beet wary of adding more hidden state (even though the >>>>>> reflected sessions table does provide already plenty of it :) >>>>>> >>>>>> --a >>>>>> >>>>>>> On 6/9/17, Luke, Chris <chris_l...@comcast.com> wrote: >>>>>>> >>>>>>> >>>>>>> Would it make sense to have a flag on the interface (or >>>>>>> globally), set when applying the ACL, that indicates the >>>>>>> desired behavior when the ACL is empty or non-existent? At the >>>>>>> moment to me it seems logical that this is the same behavior >>>>>>> as when matching falls off the end of the ACL. >>>>>>> >>>>>>> Chris. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: vpp-dev-boun...@lists.fd.io >>>>>>>> [mailto:vpp-dev-boun...@lists.fd.io] >>>>>>>> On >>>>>>>> Behalf Of Andrew ?? Yourtchenko >>>>>>>> Sent: Friday, June 9, 2017 7:53 >>>>>>>> To: Marco Varlese <marco.varl...@suse.com> >>>>>>>> Cc: vpp-dev@lists.fd.io >>>>>>>> Subject: Re: [vpp-dev] Bind / Unbind of ACL >>>>>>>> >>>>>>>> Hi Marco, >>>>>>>> >>>>>>>> Yes, this works as expected, assuming after deletion *all* >>>>>>>> the traffic is denied, rather than just the SSH traffic. >>>>>>>> >>>>>>>> If you apply to an interface the ACL# that does not exist, >>>>>>>> that is the same as if there was an ACL with just the "deny >>>>>>>> all" semantics, to avoid the perception that a given policy >>>>>>>> is enforced when it isn't - so I erred on the side of >>>>>>>> caution. >>>>>>>> >>>>>>>> The way to remove the ACL: you would ensure the ACL is not >>>>>>>> applied to the >>>>>>>> interface(s) first, then remove the ACL (or replace it with >>>>>>>> a different policy in- place). >>>>>>>> >>>>>>>> Alternatively, you can just replace the existing ACL >>>>>>>> in-place with "permit any" >>>>>>>> for IPv4 and IPv6 - this way you explicitly state that there >>>>>>>> is a policy to permit all the traffic. >>>>>>>> >>>>>>>> I've been bitten myself and seen several times in my career >>>>>>>> when an applied but non-existent ACL caused problems later >>>>>>>> on, in the worst possible moment. The current behaviour IMHO >>>>>>>> makes the config discrepancy clear - what do you think ? >>>>>>>> >>>>>>>> --a >>>>>>>> >>>>>>>>> On 6/9/17, Marco Varlese <marco.varl...@suse.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I am trying the ACL functionality and I found a "strange" >>>>>>>>> behaviour. >>>>>>>>> >>>>>>>>> The steps I follow to use an ACL are: >>>>>>>>> * I create an ACL to deny SSH traffic between VMs (via the >>>>>>>> 'acl_add_replace' >>>>>>>>> >>>>>>>>> >>>>>>>>> function) >>>>>>>>> * Set that ACL to the interfaces involved (via the >>>>>>>>> 'acl_interface_set_acl_list' >>>>>>>>> function) >>>>>>>>> >>>>>>>>> After performing the above steps the traffic was correctly >>>>>>>>> being blocked. >>>>>>>>> >>>>>>>>> However, when I decided to enable the SSH traffic again, I >>>>>>>>> simply deleted the ACL (via the 'acl_del' function) with >>>>>>>>> the consequence though that the traffic was still being denied. >>>>>>>>> >>>>>>>>> Is this behaviour correct? >>>>>>>>> If so what would be the right way to unset hence disable a >>>>>>>>> given ACL from an interface (or multiple)? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marco >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> vpp-dev mailing list >>>>>>>>> vpp-dev@lists.fd.io >>>>>>>>> https://lists.fd.io/mailman/listinfo/vpp-dev >>>>>>>> _______________________________________________ >>>>>>>> vpp-dev mailing list >>>>>>>> vpp-dev@lists.fd.io >>>>>>>> https://lists.fd.io/mailman/listinfo/vpp-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
