Open Stack

Hi Gal,

Sorry for the slow reply.

Actually, thinking about it now, I'm not sure.

First, I assume that the pipeline must be in reverse order for
ingress/egress. Do you agree?

For a generic VM, it might be best to have chaining between the network and
the port-level FW. This would allow a security appliance to see and log a
port scan.

But if the VM is a VPN appliance, the port scan could come from either side
of the port. So perhaps we need the possibility to specify a chain's
position relative to security?

-Pino
On Oct 28, 2015 18:16, "Gal Sagie" <gal.sagie at gmail.com> wrote:

> Hi Pino,
>
> Just one note on the order of the pipeline, shouldnt the security part be
> before the service chaining (and also after)?
> (Unless you only meant egress security and you still do the ingress before)
>
> Gal.
>
> On Wed, Oct 28, 2015 at 10:14 AM, Giuseppe (Pino) de Candia <
> gdecandia at midokura.com> wrote:
>
>> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbryant at redhat.com>
>> wrote:
>>
>>> I read through the proposed SFC API here:
>>>
>>> http://docs.openstack.org/developer/networking-sfc/api.html
>>>
>>> I'm looking at implementing what would be required to support this API
>>> in OVN.  I have a prototype, but I had to make some pretty big
>>> assumptions, so I wanted to clarify the intent of the API.
>>>
>>> First, does it assume that all of the neutron ports in a chain are on
>>> the same Neutron network?  That keeps things simple.  If its intended to
>>> allow a chain of ports on different networks, is it just required that
>>> you pick ports that all have addresses routable from one port to the
>>> next in the chain?  An arbitrary set of ports can't always work, so
>>> there has to be some bounds around what set of ports are valid to be in
>>> a chain.
>>>
>>
>> Hi Russell,
>>
>> We have similarly been experimenting with a MidoNet implementation of the
>> SFC API.
>>
>> I hope there's no restriction on the location of the Neutron ports in a
>> chain.
>>
>> In terms of addresses, I believe the API is lacking (or we use a
>> chain_parameter?) a way to indicate the service insertion model:
>> - L2 - The service can accept packets sent from any MAC (service NIC in
>> promiscuous mode). The MAC address may be used to identify where the packet
>> came from before it entered the chain.
>> - L3 -  The service expects packets to be routed to it. So the
>> destination MAC of the packet must be set to the service's NIC's MAC.
>>
>> Any thoughts on this?
>>
>>
>>>
>>> Second, where is it expected that the match is applied?  The API for
>>> creating a port chain doesn't associate the chain with a network, but
>>> just matching "globally" doesn't make any sense.  If all ports are
>>> expected to be on the same network, is the match applied for any traffic
>>> entering that network from any port?
>>>
>>
>> Here's what we were thinking for MidoNet:
>>
>> use the logical_source_port in the flow classifier: when we render the
>> SFC API in MidoNet's models we will associate the chain with the source
>> port.
>>
>> Our packet pipeline (for packets egressing the VM) is:
>>
>>    1. Port Mirroring
>>    2. Service Chaining
>>    3. Filtering (Port Security, anti-spoofing, Security Groups)
>>
>>
>> Do you think we can standardise on a single order in all implementations?
>> We'd be happy to change the order if it makes sense.
>>
>>
>>
>>>
>>> I'm in Tokyo this week, so if the group working on this would like to
>>> talk in person, that would be great too.
>>>
>>
>> I'd love to be included.
>>
>> Great topic, thanks!
>>
>> Pino
>>
>>
>>>
>>> --
>>> Russell Bryant
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20151031/a7628adf/attachment.html>