14:00:13 <mlavalle> #startmeeting neutron_drivers
14:00:14 <openstack> Meeting started Fri Jun 21 14:00:13 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:17 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:40 <yamamoto> hi
14:01:25 <slaweq> hi
14:01:31 <amotoki> o/
14:01:38 <ralonsoh> hi
14:02:29 <mlavalle> ok
14:03:06 <mlavalle> good evening / afternoon / morning to everybody
14:03:13 <mlavalle> let's get going
14:03:19 <mlavalle> #topic RFEs
14:03:23 <haleyb> hi
14:03:37 <mlavalle> Today we have 1 RFE to discuss: https://bugs.launchpad.net/neutron/+bug/1832758
14:03:39 <openstack> Launchpad bug 1832758 in neutron "[RFE] Allow/deny custom ethertypes in security groups" [Wishlist,New]
14:04:32 <slaweq> that is interesting one :)
14:06:05 <amotoki> I haven't followed comments so far, but as a quick look it looks okay to accept ether types other than IPv4/IPv6.
14:07:04 <amotoki> ovs flow allows us to do it.
14:08:11 <slaweq> amotoki: yes, but the problem here is that in case of iptables fw driver all such custom ethertypes are allows already
14:08:20 <slaweq> and there is no way to block them currently
14:08:44 <slaweq> so we have totally different behaviour depends on what driver is used
14:08:51 <haleyb> yes, with iptables_hybrid we might be able to do it using ebtables, right now it's almost a bug in the iptables_hybrid code imho
14:08:57 <amotoki> slaweq: ah.... the fallback default rule allows all traffic?
14:09:32 <slaweq> at least IIUC this bug report and what njohnston explained us recently, it is like that
14:09:51 <mlavalle> so that tells me that we should strive for consistency, right?
14:09:54 <slaweq> so IMO first question here is:
14:10:01 <slaweq> which behaviour is correct
14:10:14 <slaweq> 1. iptables_hybrid driver which allows custom ethertypes
14:10:16 <slaweq> or
14:10:25 <slaweq> 2. ovs driver which blocks it
14:10:27 <mlavalle> another way to pose the question is:
14:11:11 <mlavalle> do we believe that there are already users with this use case going on with iptables_hybrid
14:11:13 <mlavalle> ?
14:11:38 <mlavalle> if yes, that kind of tells us that is the right behavior
14:12:20 <haleyb> yes, there are, but it might have been an oversight since we're allowing traffic that wasn't allowed by an SG rule
14:12:43 <mlavalle> I know
14:12:46 <slaweq> mlavalle: as njohnston wrote in comment, we had customers using e.g. InfiniBand which require such traffic
14:13:28 <mlavalle> I understand that. But if those users are working with those use cases without a problem, why would we rule it out?
14:14:07 <mlavalle> the way I see it, we should catch up with reality
14:14:23 <mlavalle> and make it explicit
14:16:17 <amotoki> I generally agree with mlavalle.
14:16:19 <amotoki> One point is how operators can check if such use cases are being used in their deployments.
14:17:15 <mlavalle> ahhh, that's good point
14:17:39 <mlavalle> the same as us, many of those deployment managers might not even know that this is going on
14:18:19 <haleyb> we had no idea, new deployment used ovsfw and boom!
14:18:47 <mlavalle> exactly
14:18:54 <slaweq> IMHO current situation is: correct behaviour is in ovs fw but some users are rely on broken iptables_hybrid driver, so do we want to "break" ovs fw driver and allow such traffic there too, or do we want to break some of existing deployments which uses iptables_hybrid driver?
14:19:50 <mlavalle> but we wouldn't be breaking any ovs fw driver sitaution
14:20:01 <mlavalle> we would just open up another possibility to them
14:20:10 <mlavalle> the converse is not true
14:20:26 <haleyb> i guess i don't think we can change iptables_hybrid without a solution to then allow different ethertypes
14:20:58 <mlavalle> with iptables_hybrid users, we would be braking scenarios
14:21:07 <slaweq> mlavalle: exactly
14:21:15 <yamamoto> slaweq: why do you think ovs-fw behaviour is correct?
14:21:24 <amotoki> it would be nice if we have a kind of "permissive" mode as selinux does.... but I am not sure it can and is feasible
14:21:38 <mlavalle> and yes, that is the next question, yamamoto
14:21:46 <slaweq> yamamoto: because iptables driver now allows traffic which isn't explicity set to be allowed in SG rules
14:21:51 <amotoki> yamamoto: I agree with slaweq. all traffic which aree not defined in SG rules should be dropped I think.
14:22:28 <slaweq> but maybe it's "only" matter of proper documentation where we will say explicity what SG can filter and what not
14:23:11 <mlavalle> I think it boils down to saying the community clearly what happened
14:23:17 <mlavalle> allow the new behavior
14:23:48 <mlavalle> and maybe, as suggested by amotoki's previous comment, provide tools for deployment managers to audit their deployments
14:24:24 <mlavalle> and add rules in the case of iptables_hybrid
14:24:30 <mlavalle> to make it explicit
14:25:52 <haleyb> can probably do that by changing default to DROP instead of ACCEPT, i don't know
14:26:10 <mlavalle> maybe
14:26:10 <haleyb> altough that's at iptables, which isn't in play
14:26:53 <haleyb> i was getting ahead of myself...
14:27:28 <mlavalle> maybe the way forward is approve the RFE with the comments ^^^^ and ask for a spec where we can sort out the details
14:27:51 <mlavalle> but I don't see us dodging this one
14:28:19 <amotoki> The RFE is about ovs-fw. one idea is to keep the current behavior of iptables-based impl and to add non-IP ethertype to ovs-fw. It would break nothing.
14:28:34 <mlavalle> that's true
14:28:49 <amotoki> we can accept non-IP ethertype if ovs-fw is used.
14:29:04 <amotoki> the API extension would help us
14:29:26 <mlavalle> and document exactly what happened, so community is aware
14:29:56 <yamamoto> i wonder how other impls do
14:29:57 <haleyb> that get's back to the question of should we be doing that?  it seems like a security issue since user didn't authorize it
14:30:04 <slaweq> maybe we can align ovs-fw with iptables for now, so allow this non-IP ethertypes and update docs and later as second step add possibility to enable/disable such traffic - this second step would be treated as RFE
14:31:52 <amotoki> how about making it explicitly? for example, we can insert a SG rule to allow non-IP ethertype traffic
14:32:34 <haleyb> that would let you audit it i'd assume, seeing byte/packet counts on a flow rule
14:32:48 <slaweq> amotoki: but this may be tricky to implement in case of iptables_driver, no?
14:33:30 <amotoki> slaweq: perhaps what we need to do is to keep ovs-fw compatible with iptable-hybrid w/ some audit way
14:33:32 <mlavalle> it should be made explicit in both cases
14:34:17 <mlavalle> with rules
14:35:35 <slaweq> amotoki: I agree, that would be good solution
14:38:31 <yamamoto> do we want to make some research about other SG impls?  i can look at midonet if desirable
14:39:10 <mlavalle> amotoki: what exactly is meant by "keep ovs-fw compatible?
14:39:43 <mlavalle> does it mean just opening up those ethertypes by default?
14:39:46 <amotoki> mlavalle: what I think is to allow non-IP traffic by default.
14:40:02 <amotoki> mlavalle: yes
14:40:11 <mlavalle> without explicit rules?
14:41:27 <amotoki> I think "explicit (SG) rules" is optional.  operators can check such traffic is sent from ovs flow stats (though we need to check it is feasible)
14:41:34 <slaweq> amotoki: or maybe add new config option to allow operator to explicity say: "on this node, non-IP traffic should be allowed with ovs-fw driver"
14:42:11 <amotoki> slaweq: yes, that's another good option
14:43:25 <mlavalle> another alternative is to enforce it / make it explicit at the upgrade moment:
14:43:42 <mlavalle> 1) iptables-hybrid continues as is
14:44:24 <mlavalle> 2) when user upgrades to ovs-fw, he / she needs to create rules to allow other ether types
14:44:54 <mlavalle> this way, over time, we nudge the community to make this bahvior explicit
14:45:24 <mlavalle> and we provide tools for the upgrade
14:47:26 <yamamoto> mlavalle: does it mean "an SG implementation can choose either behaviors"?
14:48:57 <mlavalle> yamamoto: it means that when you upgrade to ovs-fw you have make your choice to allow other ether types explicit with rules in your security groups
14:50:30 <mlavalle> this way, as the community adopts ovs-fw, we gradually line up the actual behavior with what is expressed in the security groups
14:50:39 <amotoki> I think yamamoto's question is about third-party SG implementation. do they need to change the behavior on non-IP ether traffic at some time? or do they choose a behavior?
14:51:55 <mlavalle> for that part of the proble, I think we need to understand what the current posture is, as suggested by yamamoto himself
14:52:21 <mlavalle> what doesn midonet do now?
14:52:40 <mlavalle> maybe some investigation is needed to answer this
14:52:52 <yamamoto> mlavalle: dunno. i need to investigate
14:53:14 <mlavalle> what doesn ovn do, haleyb?
14:53:51 <haleyb> mlavalle: since it uses the ovsfw I'm assuming it drops the traffic, but i have not tested
14:54:49 <mlavalle> I think boden can help us with the nsx plugin
14:54:51 <yamamoto> haleyb: doesn't it use ovn acls?
14:55:30 <haleyb> yamamoto: i can ask, just not something i've looked at yet
14:56:00 <mlavalle> ok, it seems that we need to take a pause on this one and revisit it next week
14:56:28 <mlavalle> I'll try to find out what's the situation with networking-odl
14:56:52 <mlavalle> does that sound sensible?
14:57:35 <slaweq> +1
14:57:38 <amotoki> +1. it would be nice if we can cover vmware-nsx as well.
14:57:45 <yamamoto> +1
14:58:09 <yamamoto> although i'm not sure i have time to look at midonet in a week.
14:58:29 <mlavalle> amotoki: yes, I'll ask boden for help with that
14:59:08 <mlavalle> ok guys, have a great weekend
14:59:14 <mlavalle> thanks for attending
14:59:22 <mlavalle> #endmeeting