[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
