14:00:51 <yushiro> #startmeeting fwaas
14:00:52 <openstack> Meeting started Thu Nov 16 14:00:51 2017 UTC and is due to finish in 60 minutes.  The chair is yushiro. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:55 <openstack> The meeting name has been set to 'fwaas'
14:00:56 <SridarK> Hi FWaaS folks
14:01:03 <chandanc> Hello All
14:01:05 <yushiro> #chair SridarK yushiro xgerman_
14:01:06 <openstack> Current chairs: SridarK xgerman_ yushiro
14:01:13 <yushiro> I think today is xgerman_ :)
14:01:33 <xgerman_> One sec
14:01:46 <SridarK> yes
14:02:09 <xgerman_> ok
14:02:30 <SridarK> xgerman_: do u want me to start off with summit feedback
14:02:34 <xgerman_> yes
14:02:43 <SridarK> #topic Summit feedback
14:03:26 <SridarK> So this summit the attendance it seems was abt 2400 or so  - again this is what i heard not official figures
14:03:52 <SridarK> there were not as many contributors at least from neutron
14:04:15 <yushiro> yeah
14:04:16 <reedip> damn bad luck
14:04:17 <SridarK> many folks i know did not make it because Sydney is quite far for most folks
14:04:43 <xgerman_> yes, indeed
14:04:54 <doude> Hi
14:05:00 <yushiro> doude, hi
14:05:22 <SridarK> amongst FWaaS, yushiro, doude and myself were there and we had met up twice to discuss some of our priorities so it was useful
14:05:38 <SridarK> lot of focus on containers and OpenStack
14:06:26 <yushiro> yes
14:07:05 <xgerman_> they have most of the talks as videos online
14:07:36 <SridarK> in our FWaaS discussions - we went over the L2 support patches and the priorities and had a good discussions with doude on refactoring to use service drivers
14:08:03 <SridarK> which was something we have wanted to do from the I release
14:09:35 <SridarK> so our priorities to focus on merging the L2 support, more testing and pull in the Service drivers as major actions and pull in some of the things we have been discussing such as Audit support and look at the Common Classifier (depending on what we see as community adoption)
14:09:54 <SridarK> i think those were the main things to bring back to the team
14:10:02 <SridarK> xgerman_: +1 on videos
14:10:17 <reedip> so what are the targetted plans
14:10:30 <reedip> I mean do we have a roadmap for the patches ?
14:11:01 <SridarK> reedip: step 1 to merge in L2 support, the agent is done, i want to complete my testing and then i am good to +A
14:11:12 <yushiro> SridarK, +1
14:11:17 <reedip> ok
14:11:42 <SridarK> step 2: Pull in the driver and coexistence with SG
14:11:50 <reedip> SridarK : lets write this down as the roadmap for the Q cycle in the fwaas etherpad , that ways we would know where we are lagging
14:11:53 <SridarK> this will need more testing
14:12:03 <SridarK> reedip: ok i will add that
14:12:11 <xgerman_> +1
14:12:19 <reedip> We generally have everything in the meeting but I forget it by next meeting, I hope others dont though :)
14:12:40 <xgerman_> I am really hoping we get L2 in by Q-2
14:13:02 <SridarK> had a chat with chandanc on step 2 - lets discuss that today - he has some things to bring up for discussion today
14:13:26 <chandanc> sure SridarK
14:13:37 <SridarK> step 3 Focus on doude's changes for service driver - i think we can pull this in for Q
14:14:11 <reedip> IMHO, it would should be our only focus for Q-3
14:14:11 <SridarK> and we focus on more testing both manual and translating that to tempest
14:14:22 <reedip> with functional/fullstack testing improvement
14:14:32 <SridarK> reedip: +1
14:14:53 <xgerman_> +1
14:15:01 <yushiro> +1
14:15:08 <SridarK> As other features, lets pull in Audit RFE and other things that we come up with
14:15:21 <xgerman_> I like to see remote FWG…
14:15:36 <SridarK> xgerman_: +1 lets add that to the list
14:15:38 <reedip> xgerman_ whats that ?
14:16:07 <xgerman_> it’s the same as remote security groups — so you can have rules referencing ports in other groups
14:16:19 <annp> +1 xgerman_
14:16:42 <SridarK> Common classifier - we can look at as well
14:16:45 <chandanc> xgerman_: thats nice
14:17:19 <SridarK> SG logging should get in this cycle
14:17:44 <SridarK> so yushiro will plan for FWaaS logging as well but possibly next cycle
14:17:46 <annp> SridarK, yeah. :)
14:17:46 <yushiro> SridarK, Yes, definitely... I hope.  I wish. I believe  :)
14:17:53 <SridarK> :-)
14:18:08 <xgerman_> The Holoiday season starts in the US so…
14:18:16 <hoangcx_> lol yushiro
14:18:50 <xgerman_> #topic L2 support
14:18:52 <SridarK> So this was the tentative plan, again nothing is cast in stone - but again this is nothing new - i think we are all on the same page
14:19:03 <SridarK> sorry xgerman_ go ahead
14:19:34 <xgerman_> it’s mostly we need to discuss annp’s patch
14:19:36 <SridarK> i had some issues with my deployment  so could not finish my tests
14:19:58 <SridarK> once i complete - i am good with the agent PS
14:20:06 <SridarK> xgerman_: yes
14:20:38 <SridarK> also lets give the floor to chandanc to bring up some discussion
14:20:55 <chandanc> sure,
14:21:06 <annp> xgerman_: yes, chandanc, please go ahead
14:21:17 <chandanc> I have done some test with the co-existense patch,
14:21:29 <chandanc> but the idea is a bit different here
14:21:42 <chandanc> let me share the link to the ppt for the same
14:21:43 <chandanc> https://docs.google.com/presentation/d/1tRf-JQQiF0v_BdJahDjraxSEgz3c41YGdzHj3ui1C0Q/edit?usp=sharing
14:22:30 <SridarK> annp: pls jump in as u had planned a mtg last week too - i am not fully aware of the outcome
14:22:30 <chandanc> the second slide should make things clear about the proposal
14:23:15 <yushiro> chandanc, OK
14:23:51 <chandanc> in the co existense case i am proposing for a 2 table based abbroach to hold just the drop rules in fwaas policies
14:23:57 <xgerman_> slide 4: “Conntrack handling is delegated to Security Groups tables” — we still need to pull the conntrack entry for ports we deny
14:24:14 <chandanc> everything else is delegated to SG
14:24:46 <reedip> why just the drop tables ?
14:24:56 <reedip> oh the reject and accept are given to SG
14:24:59 <annp> chandanc, nice idea!
14:25:01 <chandanc> xgerman_: we will have rule based match and drop
14:25:11 <chandanc> ya
14:25:20 <xgerman_> but if the connections is alreday in conntrack won’t they bypass ys?
14:25:39 <reedip> one question... why FW Egress is going to SG Egress. Wont it be the opposite ?
14:25:46 <chandanc> xgerman_: i think the contrack will be over ridden as our tables are the first in the stack
14:25:56 <reedip> We have FW -> SG -> Node , right ?
14:26:16 <chandanc> reedip: yes
14:26:27 <xgerman_> mmh, not sure…it often bypasses things for speed
14:26:56 <reedip> chandanc : ok , I am confused with the yes... I dont know what I said was right :)
14:27:08 <chandanc> We have FW -> SG -> Node , right ?
14:27:13 <chandanc> yes to that
14:27:47 <reedip> ok ... so chandanc : again my question ... would FWEgress table forward the packet to SG Egress table ?
14:28:03 <annp> chandanc, have you tested with your proposal?
14:28:14 <reedip> shouldnt it be the opposite ? I mean the ingress is also the same ...
14:28:17 <chandanc> the flow of packet is vm1 - Egress of FWAAS - Base of SG Egress - Egress Rules of SG and then reverse
14:28:33 <chandanc> i have just generated the outputs
14:28:47 <chandanc> annp: have a look here http://paste.openstack.org/show/626423/
14:29:04 <annp> chandanc, let's  me see
14:29:07 <chandanc> this is for co-exist case
14:29:11 <chandanc> sure
14:29:25 <SridarK> annp: what are ur thoughts regarding conn track do u see any issues
14:29:47 <chandanc> in stand alone mode complete set of rules are generated http://paste.openstack.org/show/626424/
14:30:11 <xgerman_> SridarK +1 — conntrack worries me as well
14:30:30 <chandanc> i think people can have a look and think about it, we can discuss during the wek
14:30:33 <annp> SridarK, yeah, i think the problem related to conntrack
14:30:50 <SridarK> yes this was defn one of the things we wanted to flush out and discuss with everyone
14:31:20 <chandanc> ok, this is what i have on the conntrack part
14:31:42 <SridarK> I am not that familiar but annp hoangcx_ - u guys are the experts
14:32:50 <chandanc> the connection is initiated - and as it traverses through the conntrack modules the entry is made to new connection depending on te fact that it is allowed by firewall
14:33:25 <xgerman_> yes, my worry is if we get a rule to deny an established connection
14:33:28 <chandanc> once the conntrack entry is made, any related or reply packet to the original connection is allowed
14:33:31 <annp> SridarK, chandanc, actually, i haven't understood why conntrack has been changed from +new-est to +est-rep+rpl for first packet.
14:33:48 <chandanc> then the connection goes to eastablished
14:34:34 <chandanc> now if we have a deny rule in the first table, the new connection cannot be created
14:35:02 <chandanc> if a eastablish connection is present and a deny rule is added to fwaas, it will be added to the first table
14:35:26 <SridarK> xgerman_: the workflow u bring up is that we have an est connection, then the user updates the policy with a rule that should deny this est flow ?
14:35:35 <xgerman_> yep
14:35:41 <chandanc> and the rules in the first table will take precedence over the conntrack allow rules in the SG tables later
14:36:02 <chandanc> SridarK: yes
14:36:57 <chandanc> annp: i think as we have 2 tables managing conntrack there is a possibllity of FWaaS tables making the conntrack entry , so when the packet reaches the SG table it is not new any more
14:38:28 <annp> chandanc, ah, yes, you're right
14:38:29 <hoangcx_> +1 xgerman_'s concern. It was occurred with iptables conntrack (we fixed it). For OVS, we need to check for that.
14:39:19 <chandanc> hoangcx: i agree conntrack needs to be verified by testing, it can bring up unthough of cases
14:41:06 <annp> chandanc, do you mean in your approach, conntrack will be managed by fwaas, right?
14:41:17 <chandanc> no by SG alone
14:41:29 <chandanc> in co-exist case
14:42:07 <chandanc> FWaaS tables will only take care of deny rules to explicitly drop packets
14:42:15 <annp> chandanc, I mean in co-exist case, fwg will be create conntrack entry, right?
14:43:03 <chandanc> annp no, SG will create the conntrack, once it is know that the connection is allowed by both FWaaS and SG rules
14:43:41 <chandanc> any connection not allowed by FWaaS will be already dropped in the initial tables and will never reach SG
14:44:00 <xgerman_> ok, that makes sense
14:44:23 <chandanc> if the connection is also allowed by SG only then conntrack will be added
14:44:33 <chandanc> xgerman_: thanks :)
14:45:09 <annp> chandanc, that makes sense, it's same my initial idea
14:45:27 <chandanc> annp: i agree :)
14:45:43 <chandanc> i just tried to make it simpler with 2 tables only
14:46:21 <xgerman_> yeah, I like the simpler approach even if it means different code paths for stand-alone/co-existence
14:47:01 <annp> chandanc, but i'm afraid about performance in case co-existence, a packets must be travelled into all accept flows of fwg, right?
14:47:08 <chandanc> xgerman_: actually i have the code merged for standalone and co-exist, and it is triggered based on a flag
14:47:48 <chandanc> annp, not sure i got the case
14:48:40 <hoangcx_> I think we don't need to care performance at initial step
14:49:04 <hoangcx_> (OVS performance looks so good AFAIK)
14:49:12 <yushiro> hoangcx_, +1
14:49:15 <chandanc> hoangcx: agree, i would prefer to be correct then to be performent for the first pass
14:49:22 <annp> chandanc, ah, ok.
14:50:20 <hoangcx_> We can enhance it later then when functionality land
14:50:24 <SridarK> but lets evaluate annp's concern so we know what the downsides are
14:50:37 <chandanc> sure SridarK
14:50:50 <annp> SridarK, +1
14:50:55 <hoangcx_> SridarK: +1
14:51:02 <yushiro> SridarK, +1
14:51:10 <chandanc> lets bring up the cases where we see issues, so that we know the problems
14:51:33 <chandanc> +1
14:52:24 <chandanc> I would like to push in the code to gerrit for better review
14:52:42 <SridarK> +1
14:52:43 <annp> chandanc, yeah, Please do that.
14:52:56 <chandanc> i can work on the co-existance patch from annp, or a separate one
14:52:57 <SridarK> Also if folks can think thru this more
14:52:59 <yushiro> chandanc, will take a look.
14:53:05 <chandanc> Up to annp
14:53:27 <chandanc> :) i hope annp has a backup of his code
14:53:54 <annp> chandanc, yes, please update my patch. I have backup once. :)
14:54:03 <SridarK> chandanc: , annp: if u can sync up more to ensure that things are good and if all use cases work that will work
14:54:04 <chandanc> cool annp
14:54:12 <SridarK> gerrit or offline
14:54:36 <SridarK> chandanc: thx for putting together a ppt to clarify things
14:54:47 <chandanc> Sure SridarK
14:55:25 <xgerman_> T-5
14:55:52 <reedip> need to leave, another meeting.. will check rest of the discussion later ... thanks :)
14:55:52 <chandanc> I will update the PS by tomorrow after some cleanup
14:56:12 <yushiro> chandanc, Thanks.
14:56:15 <SridarK> sounds good
14:56:51 <annp> chandanc: thanks
14:57:09 <SridarK> Also i was wondering why someone would want to enable both L2 FWaaS and SG (other than a transition period)
14:57:14 <chandanc> yushiro: annp please review the patch once i publish and let me know
14:57:28 <yushiro> chandanc, YEEES!!
14:57:36 <annp> chandanc, sure
14:57:40 <SridarK> i would think we it will be either - or
14:58:00 <xgerman_> yeah, eventually it should all be FW
14:58:00 <SridarK> and eventually we get to a point we have only one security model on L2
14:58:03 <chandanc> SridarK: i would like to think so
14:58:53 <SridarK> we should also have a plan if we have a deployment with SG on iptables and L2 FWaaS
14:58:57 <yushiro> Finally, we are enough to use only FWG.  However, I think it is more useful by using SG with 'remote_group_id' like AWS SG.
14:59:07 <SridarK> i think we called out that we will not support that
14:59:20 <chandanc> SridarK: yes that one is not covered
14:59:37 <SridarK> but we should understand the implications and if we need to disallow that in our code
14:59:46 <SridarK> 1 min
15:00:29 <yushiro> Good discussion today :)
15:00:31 <xgerman_> #endmeeting