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