On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton <blak...@gmail.com> wrote:
> That's the point. By using security groups, you are forcing a certain kind
> of enforcement that must be honored and might not be necessary if the
> original intent was just to isolate between groups. In the example you
> gave, it cannot be implemented on the router without violating the
> constraints of the security group.
>
>
> Hi Kevin,
Mind proposing an alternative example then. The only way I can see this
claim to be made is because Group Based policy is actually limiting what a
tenants desired topology can be?
Thanks,
Aaron
> On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen <aaronoro...@gmail.com> wrote:
>
>>
>>
>>
>> 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.
>>
>> states
>>
>>
>>
>>>
>>>
>>> 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
>>
>>
>
>
> --
> 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
