14:00:04 <mlavalle> #startmeeting neutron_drivers
14:00:05 <openstack> Meeting started Fri Jun 28 14:00:04 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:16 <slaweq> hi
14:00:55 <mlavalle> boden: to optimize your time, we are talkijg about https://bugs.launchpad.net/neutron/+bug/1832758
14:00:56 <openstack> Launchpad bug 1832758 in neutron "[RFE] Allow/deny custom ethertypes in security groups" [Wishlist,New]
14:01:22 <ralonsoh> hi
14:01:32 <mlavalle> the question that we have is whether NSX allows other ethertypes in security groups?
14:01:57 <njohnston> o/
14:02:16 <mlavalle> i.e. can you say in a security group rule that non ip traffic is enabled? or is non ip trafiic enabled by deafult in NSX?
14:03:04 <boden> mlavalle I would have to dig.. I didn't write much of that code, I mainly just maintain the gate and some bugs
14:03:26 <njohnston> boden: Common examples would be InfiniBand or FCoE
14:03:37 <boden> mlavalle can we propose the question in the bug and I will ask the dev team to look
14:04:12 <mlavalle> boden: yeah, don't dig too much. Just ask your devs to look at the RFE and give their opinion
14:04:30 <haleyb> hi
14:04:42 <boden> mlavalle will do... I could guess here, but better to let them peek since they know the deep details of the integration
14:05:19 <mlavalle> boden: that's all I wanted to ask, in case you need to take care of your parental duties. you afe also welcome to stay :-)
14:06:01 <mlavalle> #topic RFEs
14:06:16 <mlavalle> ok, we have quorum
14:07:01 <mlavalle> Let's go back to https://bugs.launchpad.net/neutron/+bug/1832758
14:07:02 <openstack> Launchpad bug 1832758 in neutron "[RFE] Allow/deny custom ethertypes in security groups" [Wishlist,New]
14:07:57 <njohnston> Thank you all for getting started talking about this last week while I was on PTO
14:08:07 <njohnston> glad to get the ball rolling
14:08:27 <mlavalle> Let me try to summarize last week's discussion:
14:09:00 <mlavalle> 1) The team seemed to agree that we have to allow other ethertypes beyond IP
14:09:29 <mlavalle> 2) We got bogged down on the transition from the current situation to the new one
14:10:06 <mlavalle> whether just to allow those ethertypes by default or requiring explicit rules to enable them
14:10:18 <mlavalle> is that a good summary?
14:11:25 <slaweq> IMO yes
14:11:44 <slaweq> and we should think about some solution which will be backportable to stable releases IMHO
14:11:47 <njohnston> mlavalle: Sounds right based on my reading of the transcript
14:11:52 <haleyb> +1
14:12:18 <njohnston> Regarding allowing the ethertypes by default, I think this should be treated like IP traffic: default deny, allow only with exception.
14:13:24 <mlavalle> njohnston: that was also my position
14:13:44 <mlavalle> but the rest of the team seemed to be inclined towards allowing them by default
14:14:09 <mlavalle> at least that was my take away after reading the log last night
14:14:15 <njohnston> If a bank or governmental institution, for example, wants to lock down their network completely then saying "You're locked down unless a hacker uses a custom ethertype, then he can exfiltrate data freely" is not a good answer
14:14:35 <slaweq> +1
14:15:13 <mlavalle> agree
14:16:18 <mlavalle> I think that is the crux of the discussion
14:16:38 <mlavalle> the user should be locked down / secure by default
14:19:10 <mlavalle> the flip side of the coin is that deployments using custom ethertypes under hybrid fw will have to enable them explicitely when migration to ovs fw
14:19:12 <mlavalle> right?
14:19:34 <amotoki> sorry for late. I second "deny" by default. we see different behaviors in iptables-hybrid and ovs-fw at least. it sounds better to have an explicit rule when close the gap. I think it allows users to be aware of what happens.
14:19:35 <njohnston> mlavalle: yes, which would be an improvement on the current situation where they are broken without recourse for a fix
14:19:44 <amotoki> mlavalle: agree
14:20:36 <mlavalle> ok, so are we ready to approve implementing:
14:20:52 <mlavalle> 1) custom ethertypes in security groups
14:21:09 <mlavalle> 2) with deny as the default bahavior?
14:22:07 <njohnston> mlavalle: Yes.  Additionally I think some documentation to help operators sample traffic looking for custom ethertypes so they can see what is actually in use befor ethey migrate would be a good way to help the pain of a transition from iptables to ovsfw
14:22:49 <mlavalle> documentation at a minimum.... ideally some tool
14:23:11 <slaweq> one question: what about iptables driver? Will we also implement blocking such custom ethertypes in it?
14:24:34 <haleyb> my internet connection is going down, so i'll put in a preemptive +1 on Nate's back-portable solution
14:24:50 <njohnston> would it make sense to consider that as a separate RFE once this one is implemented, and pull the security team into the discussion at that time
14:24:56 <njohnston> ?
14:24:59 <amotoki> one idea on iptables driver is to define explicit rules to allow such traffic and block to drip them.
14:25:47 <haleyb> amotoki: it would be an ebtables-type driver, so would be more work in the hybrid case
14:25:47 <amotoki> this RFE is about ovs-fw behaviro. we can tackle how to close the gap between ovs-fw and iptable drivers in another RFE.
14:26:23 <slaweq> I agree that it may be separate RFE, but I would just want to not forget about it :)
14:26:37 <njohnston> amotoki: +1
14:26:55 <amotoki> haleyb: yes, I learned that last week. it would need more work and it might be moree complicated.
14:27:06 <mlavalle> here's what I propose. approve the RFE....
14:27:10 <slaweq> because if we will have something like: ovs-fw blocks such traffic by default, iptables always allows this traffic (which is also now) - this sounds a bit like CVE for me even
14:27:19 <mlavalle> and start a disucssion right away with the security team
14:27:25 <njohnston> mlavalle: +1
14:27:43 <mlavalle> slaweq: it is CVE
14:28:01 <amotoki> at least OSSN (openstack security notice) is worth mentioned.
14:28:08 <mlavalle> and that is why we have to start discussing with the security team
14:28:24 <slaweq> ok
14:28:32 <mlavalle> because our deployer have a hole there and I bet most of them don't even realize it
14:28:39 <mlavalle> deployers^^^^
14:29:12 <njohnston> I'd like to talk a little about how we address this in master vs. stable
14:30:33 <njohnston> I'd like to propose - and get the drivers blessing - that we create an RFE and figure out the API changes, DB changes, etc. to create this as a proper API extension for the security groups API for master.  But that seems too much to backport to old releases, per our backports policy.
14:31:37 <njohnston> So I would like to address this with a minimalistic change that just uses an ovs agent config option to define the permitted ethertypes, as a way to address the situation in stable with a light touch.  I started on such an approach here: https://review.opendev.org/#/c/667207/
14:32:06 <mlavalle> ahh, I saw that patch. Now I understand
14:32:50 <njohnston> (this is what haleyb was referring to earlier)
14:33:56 <mlavalle> it never comes into master
14:34:04 <mlavalle> starts in stable/steain
14:34:30 <mlavalle> it makes sense to me
14:34:31 <njohnston> mlavalle: precisely
14:34:39 <njohnston> Since this is CVE territory I think something we can have out there for existing customers soon is a good thing, plus it addresses the "sideways regression" for customers going from iptables_hybrid to ovsfw and having their Infiniband application break.
14:35:25 <slaweq> njohnston: but as this is only for Stein and older, are You sure that proper fix with API changes will be ready for Train for sure?
14:36:16 <ralonsoh> agree with slaweq, this patch can be merged in master and then, if the feature is implemented, removed
14:36:38 <slaweq> maybe that would be "safer" solution
14:36:54 <njohnston> OK, I'd be very open to that
14:37:42 <mlavalle> sounds sensible to me
14:38:05 <mlavalle> amotoki, haleyb: what do you think?
14:39:44 * njohnston wonders if we lost haleyb
14:40:21 <mlavalle> probably
14:40:55 <amotoki> I followed the discussion and it makes sense to me.
14:41:21 <mlavalle> cool
14:41:29 <mlavalle> we have an agreement
14:41:49 <mlavalle> I will document this discussion in the RFE and mark it approved
14:42:02 <mlavalle> that was the only RFE we had for today
14:42:12 <njohnston> All right.  I will take my code on stable/stein and propose it for master, adding TODO statements to remove when we have a full implementation... and then I'll get a spec going for the full change
14:42:25 <mlavalle> but before leaving, I have two questions for the team
14:43:21 <mlavalle> 1) Last night I was looking at the RFE, just freshly submitted: https://bugs.launchpad.net/neutron/+bug/1834174
14:43:22 <openstack> Launchpad bug 1834174 in neutron "[RFE] Add support for IPoIB interface driver" [Wishlist,New] - Assigned to Adrian Chiris (adrian.chiris)
14:43:49 <mlavalle> but given the previous ethertypes disucssion, do we need infiniband drivers?
14:44:29 <mlavalle> deployers are connecting infiniband fabrics in their OpenStack systems, right?
14:44:56 <mlavalle> at least the RH folks know of one, as far as I can glean out
14:45:32 <njohnston> In the case I know about, the application is using the infiniband protocol natively (I believe, would want to confirm it)
14:45:44 <slaweq> I don't know IB but for me it looks like proposal for new dhcp/L3 driver that dhcp/router namespace can be connected that way
14:46:10 <mlavalle> ok, please leave some comments there if you have time
14:46:43 <njohnston> but infiniband can also be implemented in hardware so perhaps this is to create ports on an interface that is an infiniband network interface rather than an ethernet one
14:46:51 * njohnston will comment
14:47:32 <mlavalle> 2) Thursday of Next week is July 4th, Independence Day in the USA. I am taking Friday 5th off and I suspect haleyb and njohnston might do the same
14:47:59 <ralonsoh> I'll do the same!!
14:48:05 * slaweq is sad that he will have to be at work :(
14:48:54 <mlavalle> so it might be slaweq, amotoki and yamamoto only attending the meeting
14:49:08 * njohnston offers July 4th as a holiday for anyone who is sorting out their issues with Britain
14:49:09 <mlavalle> do you want to have it anyway or do you want to cancel?
14:49:36 <amotoki> canceling the meeting sounds good to. we can spend reviewing others :)
14:49:48 <amotoki> *good to me*
14:49:51 <slaweq> yes, I think that we can cancel it
14:49:56 <mlavalle> cool
14:50:05 <mlavalle> I'll send a notice  to the ML
14:50:33 <mlavalle> That's all for today team
14:50:36 <njohnston> thank you all very much
14:50:41 <mlavalle> Great discussion, btw
14:50:42 <slaweq> thank You all
14:50:46 <ralonsoh> bye!
14:50:47 <slaweq> have a great weekend :)
14:50:49 <slaweq> o/
14:50:54 <mlavalle> have a great weekend!
14:51:01 <mlavalle> #endmeeting