Gah, clearly hitting some kind of gmail bug as i replied to the right thread all 3 times i believe.
On Wed, Aug 6, 2014 at 4:56 PM, Aaron Rosen <aaronoro...@gmail.com> wrote: > [Moving my reply to the correct thread as someone changed the subject > line. Attempt 3 :'( ] > > > > On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton <blak...@gmail.com> wrote: > >> >Given this information I don't see any reason why the backend system >> couldn't do enforcement at the logical router and if it did so neither >> parties would know. >> >> With security groups you are specifying that nothing can contact these >> devices on those ports unless they come from the allowed IP addresses. If >> you tried to enforce this at the router you would be violating that >> specification because devices in the same subnet would be able to >> communicate on those blocked ports. >> >> >> > Sure, though this is a problem of where you are doing your enforcement. If > the backend system chooses to implement this optimization in this fashion > (which was the example you gave previously [1]). Then, if the topology > changes, i.e adding a port to the same network with conflicting security > group rules, the backend system can no longer optimize in this same fashion > at the router level and a more fine grain filtering will need to be done. > How would this be any different with group based policy? > > [1] - With the latter, a mapping driver could determine that communication > between these two hosts can be prevented by using an ACL on a router or a > switch, which doesn't violate the user's intent and buys a performance > improvement and works with ports that don't support security groups. > > > > >> On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen <aaronoro...@gmail.com> >> wrote: >> >>> >>> On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton <blak...@gmail.com> wrote: >>> >>>> By working at the port level you have already eliminated your ability >>>> to implement the filtering at different components of the network. They now >>>> need to be implemented in stateful rules at the port level and the device >>>> has to support security groups. >>>> >>> >>> >>> Lets take this example where we setup a 2 tier app with web-servers and >>> db-servers that are connected on two different networks attached to a >>> router. We add a security group rules such that web-servers can talk to >>> db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from >>> anywhere. >>> >>> neutron net-create web_net >>> neutron subnet-create --name web_subnet web_net 10.0.0.0/24 >>> >>> neutron net-create db_net >>> neutron subnet-create --name db_subnet db_net 10.2.0.0/24 >>> >>> neutron router-create myrouter >>> neutron router-interface-add myrouter web_subnet >>> neutron router-interface-add myrouter db_subnet >>> >>> neutron security-group-create web-servers; >>> neutron security-group-create db-servers; >>> >>> # add rule to allow web members to talk to the db-servers on TCP 3306 >>> for their db connection; >>> neutron security-group-rule-create --protocol TCP --port-range-min 3306 >>> --port-range-max 3306 --remote-group-id web-servers db-servers >>> >>> # add rule to allow TCP 80 into the web-server sg >>> neutron security-group-rule-create --protocol TCP --port-range-min 80 >>> --port-range-max 80 web-servers db-servers >>> >>> # create some ports with desired security profiles. >>> neutron port-create --security-group web-servers web_net >>> neutron port-create --security-group web-servers web_net >>> >>> neutron port-create --security-group db-servers db_net >>> neutron port-create --security-group db-servers db_net >>> >>> >>> Now to your point: >>> >>> By working at the port level you have already eliminated your ability to >>>> implement the filtering at different components of the network. They now >>>> need to be implemented in stateful rules at the port level and the device >>>> has to support security groups. >>>> >>>> >>> Given this information I don't see any reason why the backend system >>> couldn't do enforcement at the logical router and if it did so neither >>> parties would know. The backend system should have the full graph of >>> everything and be able to do enforcement optimizations where ever it likes. >>> >>> btw: I say the enforcement could be done on the logical router though >>> the backend system could also do this on the physical fabic as well if it >>> wanted to as it should also know that graph. No? >>> >>> >>>> >>>> On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen <aaronoro...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak...@gmail.com> >>>>> wrote: >>>>> >>>>>> >I believe the referential security group rules solve this problem >>>>>> (unless I'm not understanding): >>>>>> >>>>>> I think the disconnect is that you are comparing the way to current >>>>>> mapping driver implements things for the reference implementation with >>>>>> the >>>>>> existing APIs. Under this light, it's not going to look like there is a >>>>>> point to this code being in Neutron since, as you said, the abstraction >>>>>> could happen at a client. However, this changes once new mapping drivers >>>>>> can be added that implement things differently. >>>>>> >>>>>> Let's take the security groups example. Using the security groups API >>>>>> directly is imperative ("put a firewall rule on this port that blocks >>>>>> this >>>>>> IP") compared to a higher level declarative abstraction ("make sure these >>>>>> two endpoints cannot communicate"). With the former, the ports must >>>>>> support >>>>>> security groups and there is nowhere except for the firewall rules on >>>>>> that >>>>>> port to implement it without violating the user's expectation. With the >>>>>> latter, a mapping driver could determine that communication between these >>>>>> two hosts can be prevented by using an ACL on a router or a switch, which >>>>>> doesn't violate the user's intent and buys a performance improvement and >>>>>> works with ports that don't support security groups. >>>>>> >>>>>> Group based policy is trying to move the requests into the >>>>>> declarative abstraction so optimizations like the one above can be made. >>>>>> >>>>> >>>>> Hi Kevin, >>>>> >>>>> Interesting points. Though, let me ask this. Why do we need to move to >>>>> a declarative API abstraction in neutron in order to perform this >>>>> optimization on the backend? For example, In the current neutron model say >>>>> we want to create a port with a security group attached to it called web >>>>> that allows TCP:80 in and members who are in a security group called >>>>> database. From this mapping I fail to see how it's really any different >>>>> from the declarative model? The ports in neutron are logical abstractions >>>>> and the backend system could be implemented in order to determine that the >>>>> communication between these two hosts could be prevented by using an ACL >>>>> on >>>>> a router or switch as well. >>>>> >>>>> Best, >>>>> >>>>> Aaron >>>>> >>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Kevin Benton >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Kevin Benton >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev