<p dir="ltr">Hi Gal,</p>
<p dir="ltr">Sorry for the slow reply. </p>
<p dir="ltr">Actually, thinking about it now, I'm not sure.</p>
<p dir="ltr">First, I assume that the pipeline must be in reverse order for ingress/egress. Do you agree?</p>
<p dir="ltr">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.</p>
<p dir="ltr">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?</p>
<p dir="ltr">-Pino</p>
<div class="gmail_quote">On Oct 28, 2015 18:16, "Gal Sagie" <<a href="mailto:gal.sagie@gmail.com">gal.sagie@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Pino,<br><br></div>Just one note on the order of the pipeline, shouldnt the security part be before the service chaining (and also after)?<br></div>(Unless you only meant egress security and you still do the ingress before)<br></div><div><br></div>Gal.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 28, 2015 at 10:14 AM, Giuseppe (Pino) de Candia <span dir="ltr"><<a href="mailto:gdecandia@midokura.com" target="_blank">gdecandia@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I read through the proposed SFC API here:<br>
<br>
<a href="http://docs.openstack.org/developer/networking-sfc/api.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/networking-sfc/api.html</a><br>
<br>
I'm looking at implementing what would be required to support this API<br>
in OVN. I have a prototype, but I had to make some pretty big<br>
assumptions, so I wanted to clarify the intent of the API.<br>
<br>
First, does it assume that all of the neutron ports in a chain are on<br>
the same Neutron network? That keeps things simple. If its intended to<br>
allow a chain of ports on different networks, is it just required that<br>
you pick ports that all have addresses routable from one port to the<br>
next in the chain? An arbitrary set of ports can't always work, so<br>
there has to be some bounds around what set of ports are valid to be in<br>
a chain.<br></blockquote><div><br></div></span><div>Hi Russell,<div><br></div><div>We have similarly been experimenting with a MidoNet implementation of the SFC API.</div></div><div><br></div><div>I hope there's no restriction on the location of the Neutron ports in a chain. </div><div><br></div><div>In terms of addresses, I believe the API is lacking (or we use a chain_parameter?) a way to indicate the service insertion model:</div><div>- 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. </div><div>- 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.</div><div><br></div><div>Any thoughts on this?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Second, where is it expected that the match is applied? The API for<br>
creating a port chain doesn't associate the chain with a network, but<br>
just matching "globally" doesn't make any sense. If all ports are<br>
expected to be on the same network, is the match applied for any traffic<br>
entering that network from any port?<br></blockquote><div><br></div></span><div>Here's what we were thinking for MidoNet:</div><div><br></div><div>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.</div><div><br></div><div>Our packet pipeline (for packets egressing the VM) is:</div><div><ol><li>Port Mirroring</li><li>Service Chaining</li><li>Filtering (Port Security, anti-spoofing, Security Groups)</li></ol><div><br></div><div>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. </div></div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm in Tokyo this week, so if the group working on this would like to<br>
talk in person, that would be great too.<br></blockquote><div><br></div></span><div>I'd love to be included.</div><div><br></div><div>Great topic, thanks!</div><span><font color="#888888"><div><br></div><div>Pino</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div>Best Regards ,<br><br>The G. </div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>