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) ? --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
