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