On Tue, Aug 2, 2016 at 3:02 PM, Darrell Ball <dlu...@gmail.com> wrote:
> > > On Tue, Aug 2, 2016 at 10:23 AM, Mickey Spiegel <mickeys....@gmail.com> > wrote: > >> On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote: >> >>> >>> >>> On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org> wrote: >>> >>>> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys....@gmail.com> >>>> wrote: >>>> >>>> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com >>>> > >>>> > wrote: >>>> > > >>>> > > -----"dev" <dev-boun...@openvswitch.org> wrote: ----- >>>> > >> To: Mickey Spiegel <mickeys....@gmail.com> >>>> > >> From: Russell Bryant >>>> > >> Sent by: "dev" >>>> > >> Date: 07/29/2016 10:02AM >>>> > >> Cc: ovs dev <dev@openvswitch.org> >>>> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage >>>> > >> >>>> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel < >>>> mickeys....@gmail.com >>>> > > >>>> > >> wrote: >>>> > >> >>>> > >>> >>>> > >>> This patch adds a second logical switch ingress ACL stage, and >>>> > >>> correspondingly a second logical switch egress ACL stage. This >>>> > >>> allows for more than one ACL-based feature to be applied in the >>>> > >>> ingress and egress logical switch pipelines. The features >>>> > >>> driving the different ACL stages may be configured by different >>>> > >>> users, for example an application deployer managing security >>>> > >>> groups and a network or security admin configuring network ACLs >>>> > >>> or firewall rules. >>>> > >>> >>>> > >>> Each ACL stage is self contained. The "action" for the >>>> > >>> highest-"priority" matching row in an ACL stage determines a >>>> > >>> packet's treatment. A separate "action" will be determined in >>>> > >>> each ACL stage, according to the ACL rules configured for that >>>> > >>> ACL stage. The "priority" values are only relevant within the >>>> > >>> context of an ACL stage. >>>> > >>> >>>> > >>> ACL rules that do not specify an ACL stage are applied to the >>>> > >>> default "acl" stage. >>>> > >>> >>>> > >>> Signed-off-by: Mickey Spiegel <mickeys....@gmail.com> >>>> > >> >>>> > >> >>>> > >> Could you expand on why priorities in a single stage aren't enough >>>> to >>>> > >> satisfy the use case? >>>> > > >>>> > > If two features are configured independently with a mix of >>>> > > prioritized allow and drop rules, then with a single stage, a >>>> > > new set of ACL rules must be produced that achieves the same >>>> > > behavior. This is sometimes referred to as an "ACL merge" >>>> > > algorithm, for example: >>>> > > >>>> > >>>> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514 >>>> > > >>>> > > In the worst case, for example when the features act on different >>>> > > packet fields (e.g. one on IP address and another on L4 port), >>>> > > the number of rules required can approach >>>> > > (# of ACL1 rules) * (# of ACL2 rules). >>>> > > >>>> > > While it is possible to code up such an algorithm, it adds >>>> > > significant complexity and complicates whichever layer >>>> > > implements the merge algorithm, either OVN or the CMS above. >>>> > > >>>> > > By using multiple independent pipeline stages, all of this >>>> > > software complexity is avoided, achieving the proper result >>>> > > in a simple and straightforward manner. >>>> > > >>>> > > Recent network hardware ASICs tend to have around 8 or 10 ACL >>>> > > stages, though they tend to evaluate these in parallel given >>>> > > all the emphasis on low latency these days. >>>> > >>>> > Throwing in an example to illustrate the difference between one >>>> > ACL stage and two ACL stages: >>>> > >>>> > If two separate ACL stages: >>>> > Feature 1 >>>> > acl from-lport 100 (tcp == 80) allow-related >>>> > acl from-lport 100 (tcp == 8080) allow-related >>>> > acl from-lport 100 (udp) allow-related >>>> > acl from-lport 100 (ip4.src == 10.1.1.0/24 && tcp) allow-related >>>> > >>>> > Feature 2 >>>> > acl2 from-lport 300 (ip4.dst == 172.16.10.0/24) allow-related >>>> > acl2 from-lport 300 (ip4.dst == 192.168.20.0/24) allow-related >>>> > acl2 from-lport 200 (ip4.dst == 172.16.0.0/20) drop >>>> > acl2 from-lport 200 (ip4.dst == 192.168.0.0/16) drop >>>> > acl2 from-lport 100 (ip4.dst == 172.16.0.0/16) allow-related >>>> > >>>> > Combined in one stage, to get the equivalent behavior, this would >>>> require: >>>> > from-lport 300 (ip4.dst == 172.16.10.0/24 && tcp == 80) >>>> allow-related >>>> > from-lport 300 (ip4.dst == 172.16.10.0/24 && tcp == 8080) >>>> allow-related >>>> > from-lport 300 (ip4.dst == 172.16.10.0/24 && udp) allow-related >>>> > from-lport 300 (ip4.dst == 172.16.10.0/24 && ip4.src == 10.1.1.0/24 >>>> && >>>> > tcp) allow-related >>>> > from-lport 300 (ip4.dst == 192.168.20.0/24 && tcp == 80) >>>> allow-related >>>> > from-lport 300 (ip4.dst == 192.168.20.0/24 && tcp == 8080) >>>> allow-related >>>> > from-lport 300 (ip4.dst == 192.168.20.0/24 && udp) allow-related >>>> > from-lport 300 (ip4.dst == 192.168.20.0/24 && ip4.src == 10.1.1.0/24 >>>> && >>>> > tcp) allow-related >>>> > from-lport 200 (ip4.dst == 172.16.0.0/20) drop >>>> > from-lport 200 (ip4.dst == 192.168.0.0/16) drop >>>> > from-lport 100 (ip4.dst == 172.16.0.0/16 && tcp == 80) allow-related >>>> > from-lport 100 (ip4.dst == 172.16.0.0/16 && tcp == 8080) >>>> allow-related >>>> > from-lport 100 (ip4.dst == 172.16.0.0/16 && udp) allow-related >>>> > from-lport 100 (ip4.dst == 172.16.0.0/16 && ip4.src == 10.1.1.0/24 >>>> && >>>> > tcp) allow-related >>>> > >>>> >>>> Or have an address set, "addrset1", which contains {172.16.10.0/24, >>>> 192.168.20.0/24, 172.16.0.0/20, 192.168.0.0/16, 172.16.0.0/16}. >>>> >>>> acl from-lport 100 (ip4.dst == $addrset1 && tcp && tcp.dst == {80, >>>> 8080}) >>>> allow-related >>>> acl from-lport 100 (ip4.dst == $addrset1 && udp) allow-related >>>> acl from-lport 100 (ip4.dst == $addrset1 && ip4.src == 10.1.1.0/24 && >>>> tcp) allow-related >>>> >>>> >>>> > >>>> > If there are more IP addresses in feature 2, then the number >>>> > of ACL rules will climb geometrically: >>>> > (4 feature 1 rules * # feature 2 allow-related rules + # feature 2 >>>> drop >>>> > rules) >>>> > >>>> > With 2 separate ACL stages, the rules just go straight into >>>> > the corresponding ACL table, no merge required: >>>> > (# feature 1 rules + # feature 2 rules) >>>> > >>>> >>>> Thanks for elaborating. I'm not opposed. It seems harmless if not >>>> being >>>> used. >>>> >>> >>> >>> There are presently no unit tests for ACLs in the system tests >>> (system-ovn.at). >>> The first step should be to add unit tests for single stage ACLs. >>> and then add a delta of tests if other stages are desired. >>> >>> It will be good to test the coordination between multiple stages >>> coming directly from northbound APIs and check what happens when >>> multistage ACLs are setup and torn down stage by stage, particularly >>> when the datapath ends up in a more permissive state for some period of >>> time. >>> >> > This feature proposal has a problem for both setup and teardown where > the staging will result in a more permissive state for periods of time. > > Here is a simple example based on your example above: > If one only wants to allow TCP and src IP 20.20.20.20 and the stage with > TCP is > added first with the stage with src IP 20.20.20.20 lagging, one will have > the > following > > 200 TCP permit > 100 DROP ALL > > which permits all TCP - not what we want. > > We cannot enforce a transaction across multiple databases (NB, SB, > ovn-controller) > I don't understand this. Rules for both stages could be added in the same transaction. It's all in the same table of the northbound database. > > > >> >>> >>> >>>> >>>> Can you update the docs to indicate the specific accepted values for >>>> "stage"? >>> >>> >>> >>> This would significantly complicate the usage of northbound ACL APIs, >>> since multi-staging would be exposed at the top (northbound) OVN layer. >>> >> >> The default behavior when "stage" is not specified is to apply the ACL to >> the >> existing "acl" stage. If you don't care about the second ACL stage, >> continue >> to use ACLs as you do today and it will work. There is no complication. >> > > You need a set of guidelines. > You just cannot assume the northbound API usage will avoid this feature. > How does one know this feature should be avoided or when to use it. > Assuming one decides to use it, how does one know how to use it. > > > >> >> >>> This would need a clear set of guidelines how northbound >>> multistage ACLs would be used by a CMS, at the user level. >>> >> >> The CMS typically does not expose ACLs directly to the user. For example, >> with OpenStack, Security Groups use the default "acl" stage. OpenStack >> FWaaS v2 would use the "acl2" stage. These are two separate OpenStack >> features with separate OpenStack northbound APIs to the user. >> > > > First of all, every OVN feature should not be tied to Openstack.] > It was just used as an example of how it would be used ... -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
