[neutron][OVS firewall] Multicast non-IGMP traffic is allowed by default, not in iptables FW (LP#1889631)
Hello all:
First of all, the link: https://bugs.launchpad.net/neutron/+bug/1889631
To sum up the bug: in iptables FW, the non-IGMP multicast traffic from 224.0.0.x was blocked; this is not happening in OVS FW.
That was discussed today in the Neutron meeting today [1]. We face two possible situations here: - If we block this traffic now, some deployments using the OVS FW will experience an unexpected network blockage. - Deployments migrating from iptables to OVS FW, now won't be able to explicitly allow this traffic (or block it by default). This also breaks the current API, because some rules won't have any effect (those ones allowing this traffic).
A possible solution is to add a new knob in the FW configuration; this config option will allow to block or not this traffic by default. Remember that the FW can only create permissive rules, not blocking ones.
Any feedback is welcome!
Regards.
[1] http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-08-0...
Hi,
On 4 Aug 2020, at 19:05, Rodolfo Alonso Hernandez ralonsoh@redhat.com wrote:
Hello all:
First of all, the link: https://bugs.launchpad.net/neutron/+bug/1889631
To sum up the bug: in iptables FW, the non-IGMP multicast traffic from 224.0.0.x was blocked; this is not happening in OVS FW.
That was discussed today in the Neutron meeting today [1]. We face two possible situations here:
- If we block this traffic now, some deployments using the OVS FW will experience an unexpected network blockage.
I would be for this option but left stable branches not touched. Additionally we should of course add release note with info that this behaviour changed now and also we can add upgrade check which will write warning about that if any of the agents in the DB is using “openvswitch” firewall driver. I don’t think we can do anything more to warn users about such change.
- Deployments migrating from iptables to OVS FW, now won't be able to explicitly allow this traffic (or block it by default). This also breaks the current API, because some rules won't have any effect (those ones allowing this traffic).
This is current issue, right? If we would fix it as You proposed above, then behaviour between both drivers would be the same. Am I understanding correct?
A possible solution is to add a new knob in the FW configuration; this config option will allow to block or not this traffic by default. Remember that the FW can only create permissive rules, not blocking ones.
I don’t like to add yet another config knob for that. And also as I think Akihiro mentioned it’s not good practice to change API behaviour depending on config options. This wouldn’t be discoverable in API.
Any feedback is welcome!
Regards.
[1]http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-08-0...
— Slawek Kaplonski Principal software engineer Red Hat
Hi Slawek:
I agree with Akihiro and you: - This should be fixed to match both FW behaviour, but only in master. - Of course, a "big" release note to make this public. - Not to add a knob that changes the API behaviour.
I'll wait for more feedback. Although I'll be on PTO, I'll check and reply to the mail.
Thank you and regards.
On Fri, Aug 7, 2020 at 11:19 AM Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
On 4 Aug 2020, at 19:05, Rodolfo Alonso Hernandez ralonsoh@redhat.com
wrote:
Hello all:
First of all, the link: https://bugs.launchpad.net/neutron/+bug/1889631
To sum up the bug: in iptables FW, the non-IGMP multicast traffic from
224.0.0.x was blocked; this is not happening in OVS FW.
That was discussed today in the Neutron meeting today [1]. We face two
possible situations here:
- If we block this traffic now, some deployments using the OVS FW will
experience an unexpected network blockage.
I would be for this option but left stable branches not touched. Additionally we should of course add release note with info that this behaviour changed now and also we can add upgrade check which will write warning about that if any of the agents in the DB is using “openvswitch” firewall driver. I don’t think we can do anything more to warn users about such change.
- Deployments migrating from iptables to OVS FW, now won't be able to
explicitly allow this traffic (or block it by default). This also breaks the current API, because some rules won't have any effect (those ones allowing this traffic).
This is current issue, right? If we would fix it as You proposed above, then behaviour between both drivers would be the same. Am I understanding correct?
A possible solution is to add a new knob in the FW configuration; this
config option will allow to block or not this traffic by default. Remember that the FW can only create permissive rules, not blocking ones.
I don’t like to add yet another config knob for that. And also as I think Akihiro mentioned it’s not good practice to change API behaviour depending on config options. This wouldn’t be discoverable in API.
Any feedback is welcome!
Regards.
[1]
http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-08-0...
— Slawek Kaplonski Principal software engineer Red Hat
participants (2)
-
Rodolfo Alonso Hernandez
-
Slawek Kaplonski