Open Stack

Thanks Rajesh for the focussed suggestions/comments. Responses inline -

On Thu, Apr 4, 2013 at 5:29 PM, Rajesh Mohan <rajesh.mlists at gmail.com> wrote:
> Hi Sumit,
>
> I am sorry that I missed the call today. I had a clash and could not
> reschedule it.
>
> I went through the draft and it looked complete from the perspective
> of addressing a generic firewall.
>
> I have few questions/suggestions below:
> -       Firewall Rules->Action:
> o       Can we make this a list of actions. For example, actions could be DENY+LOG.

Sumit: Agree, we could make this a list, rather than one action.

> o       A more generic question. Can we have vendor specific actions? Or a
> provision to create custom action that could include vendor-ID and
> action-ID. This will make it more extensible.
>

Sumit: Yes, the current extension framework used in Quantum allows
both resource and attribute extension. Vendor specific actions could
be introduced as extensions.

> -       Firewall Rules->application:
> o       This is a string. To make it useful across vendors, this has to be
> defined somewhere. Is this something on our TODO list?
>

Sumit: This was intentionally left open ended. I am not sure that
there is a standardized list of application names published. We could
potentially create a list of constants in a config file to manage this
but I would suggest not getting bogged down in this activity at this
stage.

> -       Firewall Rules->dynamic_attributes:
> o       I can guess what this means but not clear from the text. We have to
> provide more information here
>

Sumit: These are essentially placeholders and the values are bound at
the time of rule application. We can elaborate more on this.

> -       Firewall Rules:Custom attributes:
> o       Going back to my earlier point, we have to make this extensible. We
> have to have a provision to create custom attributes under some other
> page (may be created by vendor plugin) and attach it to this rule.
>

Sumit: Quantum extension framework inherently supports this, no
explicit placeholder is required for this in the base definition.

> -       Firewall Zone->network_list:
> o       There are two ways I can interpret this. Zone is defined by the
> source address of the packet (the network where the packet originated)
> or the network of the ingress interface of the Firewall. I am not sure
> which one this document assumes. In case of L3 network plugin, we can
> probably use the latter but in case of L2 network plugin, this could
> get tricky. Maybe we have to find a better way to identify zones. We
> can discuss this more when we meet at the summit.

Sumit: Agree, this definition needs work. Different vendors seem to
define and use this differently. Defining this zone in the context of
Quantum abstractions seemed the most relevant (backend implementation
can then map these to the actual devices/ports/interfaces/etc. being
used). Hence, I started with the suggestion of using a networks list.
I agree that this might not be granular enough.

>
> -       Firewall Policy:
> o       I would like more text on use case. Will there be one policy per
> firewall? Can a policy have rules that are created by admin and
> tenant? Or do we expect to create two firewalls which are entirely
> managed by admin or entirely managed by tenant? If the policy can have
> rules from admin and tenant, how can we avoid conflicting rules?
>

Sumit: The initial suggestion was to have a 1:1 relationship (this was
captured in the entity relationship diagram and also the attribute
definition) to avoid conflicting policies. However, the suggestion was
made that we should extend this as 1:many
(firewall-instance:firewall-policy) and the firewall implementation
would be able to compose the rules within the multiple policies into
one (and resolve any conflicts).

> -       Firewall:
> o       Service type is L3. Does this mean that only L3 network plugin is
> being considered now?

Sumit: No, service type need not just be L3. The proposal is that it
could be L2, bump-in-the-wire, or tap (but I don't think tap is
relevant in the context of firewalls).

> o       There is no mention of how the firewall fits into the topology. I
> guess that is covered in ServiceInsertionAndChaining draft. It would
> be nice if we could make this draft self-contained for standalone
> firewall service. If we have to chain multiple services, then we could
> look at chaining which is a complex problem and could take lot more
> effort to finish.

Sumit: Yes, the complementary draft on service chaining covers the
insertion aspects. We can certainly pull the relevant parts in if it
helps in clarification. I agree that the actual realization of
insertion and chaining is complex, however I think defining the
abstraction to capture the user's intent is simpler and we can address
it (which is what is being captured in the services' chaining draft).

>
> We should also spell out the workflow, that includes creation of
> firewall instance and attaching the same to the network.
>

Sumit: Agree. This is in the works (some of it being validated by the
prototype implementation).

> Thanks,
> -Rajesh Mohan
>
>
> On Wed, Apr 3, 2013 at 10:47 AM, Sumit Naiksatam
> <sumitnaiksatam at gmail.com> wrote:
>> We have set up a conference call scheduled for Thursday April 4th to discuss
>> this topic as a preparation for the upcoming summit.
>>
>> Agenda:
>> Current draft: https://wiki.openstack.org/wiki/Quantum/FWaaS/API
>>
>> Logistics (thanks to Vinay/Anand, PayPal):
>>
>> Where: Conference Bridge - (855) 227 1767 x 7152259
>>
>> When: Thursday, April 04, 2013 2:00 PM-3:00 PM. (UTC-08:00) Pacific Time (US
>> & Canada)
>>
>> Where: Conference Bridge - (855) 227 1767 x 7152259
>>
>> Conf. Code 7152259
>> Phones Numbers:
>>
>> (855) 227-1767(USA) - 08003765931(UK)
>> 0008006103229 (India – Toll Free)
>> 81080024322044 (Moscow), 4992701688(Moscow)
>>
>> Web Conf: https://myroom-na.adobeconnect.com/anandpalanisamy/
>>
>> More Numbers:
>> https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7152259&name=&email=&selectedProduct=joinMeeting
>>
>> Thanks,
>>
>> ~Sumit.
>>
>>
>> _______________________________________________
>> 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