Open Stack

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


On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen <aaronorosen at gmail.com> wrote:

>
> On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton <blak111 at 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 <aaronorosen at gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak111 at 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 at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Kevin Benton
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/679d900d/attachment.html>