Iām mostly agnostic with 2; an alternate behavior might be to refuse to delete an ACL if it is referenced anywhere. Iām more concerned with consistency with this sort of operation across VPP which I feel is more important, though no other examples spring to mind this early in the morning!
Chris.
On 6/15/17, 08:22, "Andrew š½ Yourtchenko" <ayour...@gmail.com> 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...
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
>>
>>
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
