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.sa...@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 < > gdecan...@midokura.com> wrote: > >> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev