Open Stack

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 <aaronorosen at 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 <blak111 at 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 <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
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/3391d422/attachment.html>