18:02:36 #startmeeting Networking FWaaS 18:02:37 Meeting started Wed Oct 23 18:02:36 2013 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:41 The meeting name has been set to 'networking_fwaas' 18:03:06 Welcome to the Firewall as a Service (FWaaS) meeting! 18:03:13 today's meeting is also in preparation for the Icehouse summit discussions/sessions 18:03:24 #info etherpad: https://etherpad.openstack.org/p/icehouse-neutron-fwaas 18:03:51 #topic tempest 18:04:01 I have created a place holder blueprint 18:04:15 #link https://blueprints.launchpad.net/tempest/+spec/fwaas-api-tempest 18:04:24 I also had an action item last week to check with Salvatore, but I did not get a chance to catch him and he is on vacation this week 18:04:40 have pinged him though 18:04:56 if anyone has any input/thoughts on this, happy to spend a few minutes on this topic here 18:05:27 seems like folks are still joining 18:05:52 for folks just joining in, we are discussing tempest tests for FWaaS 18:06:05 i have posted a placeholder blueprint 18:06:23 the idea is to at least test the basic API for the fwaas resources 18:06:34 anyone has more thoughts/input on this? 18:07:21 okay, so will try to prioritize this at least with the ideas we have 18:07:32 moving to the next topic 18:07:33 #topic zones 18:07:51 everyone's favorite topic :-) 18:07:55 :-) 18:08:03 this was another action item for me 18:08:05 Right 18:08:15 I was supposed to send a email to the mailer with a proposal 18:08:24 we had discussions with some team members on this, and based on that I sent out the proposal 18:08:34 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-zones-api 18:08:43 currently this is pretty simplistic, hoping to get some input 18:08:50 folks had a chance to think about this? 18:09:05 I think this captures it at a high level 18:09:15 SridarK: okay 18:09:22 we can work thru some of the specifics over next week 18:09:26 one thing we realized is that we cant use zones for all scenarios 18:09:31 SridarK: right 18:09:38 so we have something more tangible b4 summit 18:09:45 SumitNaiksatam: we'd like to help or on other FW objects 18:09:51 for instance, the zones don't work for bump in the wire scenarios 18:10:02 yes true that was a good discussion 18:10:06 garyduan: sure, that is coming up in the agenda 18:10:33 garyduan: you mean pitch in for zones as well? 18:10:41 i think if we cover some of the basic common cases and have it generic so works for all 18:10:52 SridarK: makes sense 18:11:20 more thoughts on the definition of zones? 18:11:21 SumitNaiksatam: We can share workload. 18:11:39 garyduan: definitely, we can decide how to split up 18:11:45 sounds good to me too 18:11:45 lets first firm up on the proposal 18:12:15 how abt we target that for the next IRC 18:12:30 to have some more details added to the BP 18:12:30 we will add source/destination arguments to the rule to be able to specify zones 18:12:36 SridarK: yeah we can do that 18:12:54 SridarK: lets also factor in the summit dynamics 18:13:20 SumitNaiksatam: agreed 18:13:25 okay seems like everyone is happy with the current state of discussion on zones 18:13:30 we will keep working on it 18:13:35 next topic 18:13:41 wait 18:13:43 :-) 18:13:48 beyounn: sure go ahead 18:13:53 the vlan support is still up in the air 18:14:00 ah ok 18:14:01 and there is another bp about this 18:14:03 https://docs.google.com/document/d/1WEGmMJ4Vn21trgwa2_mpQ7U_a1BV2rKxlRzHqc49-9Y/edit 18:14:17 beyounn: i am also talking to Kyle today evening 18:14:18 i was kind of thinking of that as implementation detail 18:14:22 but good to point out 18:14:25 SridarK: thanks 18:14:32 ok 18:14:41 just want to put all the info together 18:14:54 now, I'm done 18:14:54 #action SridarK and beyounn to continue following up on trunk port blueprint, and any additional blueprints that need to be created 18:15:03 ok sounds good 18:15:07 ok 18:15:18 beyounn: do you want to discuss it here? 18:15:26 not sure if kyle is around 18:15:31 mestery: there? 18:15:45 ok, let's do it offline then 18:15:53 We are all in a mtg now 18:15:54 ok lets do it offline 18:15:58 SridarK: got it 18:16:00 SumitNaiksatam: Barely. :) In a meeting 18:16:05 so we can pick it up offline 18:16:11 right 18:16:12 mestery: okay np, we discuss offline 18:16:20 next topic 18:16:22 #topic Address Objects 18:16:32 we were earlier planning an IP Object resource to model static and dynamic IP objects 18:16:43 the proposal is to evolve this to generic "address" objects 18:16:51 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-address-objects 18:17:02 we will first target static IP objects 18:17:14 sorry, I just checked the blueprint for the zones and I'm not sure if using ports as zones actually capture the idea of "zones" 18:17:40 Kaiwei: can you hold that thought, we just moved past that topic 18:17:47 we can circle back to zones 18:17:51 sure 18:18:17 #action SumitNaiksatam to followup on Kaiwei regarding zones if we don't get it to it by the end of the meeting 18:18:32 coming back to address objects 18:19:27 everyone fine with IP address object being a subnet or list/range of ip addresses? 18:19:45 this is the "static" ip address object 18:19:46 right 18:19:54 how about CIDR? 18:20:07 oh, that's a subnet 18:20:13 Kaiwei: okay, i was thinking CIDR when i meant subnet 18:20:15 miss that part 18:20:19 Kaiwei: yeah :-) 18:20:34 Kaiwei: but that is a good point 18:20:42 I guess that includes a list of subnets as well 18:20:54 when i was thinking subnets i was thinking neutron subnets 18:21:05 maybe there is a case for a super net or something like that 18:21:32 so the subnet is actually a subnet UUID? 18:21:43 Kaiwei: that was my initial thought 18:21:49 it helps in validation 18:22:00 UUID or name 18:22:06 I'm fine with that...but having CIDR is more flexible 18:22:12 also easier for the user to specify 18:22:23 Kaiwei: i guess we can have both 18:22:39 that will be great 18:22:42 either you can specify the actual CIDR, or the subnet UUID/name 18:22:48 perhaps more usable that way 18:23:12 Agreed, both would be helpful. 18:23:13 SumitNaiksatam: Since CIDR can cover all cases - should we support both ? 18:23:22 #action SumitNaiksatam to update address object blueprint, add CIDR 18:23:34 SridarK: CIDR would cover 18:23:56 just a thought to make it simpler 18:23:58 but providing a reference to neutron resource (subnet) in this case makes a little easier for users 18:24:10 SridarK: we can discuss as follow up 18:24:18 next topic 18:24:21 ok sounds good - i agree 18:24:42 Kaiwei: btw, anything more on address objects? 18:24:48 before i move on ;-) 18:25:10 nope, just want to make sure a list of subnets/CIDR is supported as well 18:25:20 okay great 18:25:22 #topic Counters 18:25:26 couple of blueprints have been proposed 18:25:33 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-counters-api 18:25:41 #link https://blueprints.launchpad.net/neutron/+spec/firewall-hitcounts 18:25:49 the proposal is to pull the counters from the driver, FWaaS DB will not persist any of these 18:25:50 this will be a separate API from the firewall_rules API (each rule will be identified based on rule_id and firewall_id) 18:27:24 we still need to define what to report 18:27:41 i guess the set of what IP tables reports is a must 18:27:46 accept, deny 18:28:14 I think Salvatore mentioned in last week's meeting that pull the counters directly from driver every time a query is issued can put a lot stress on backend.... 18:28:48 Kaiwei: I don't think that was what he was suggesting 18:29:16 i believe what he was suggesting is that we should not continuously update counters in the FWaaS DB 18:29:30 Kaiwei: My understanding is updating database is too costy 18:29:37 garyduan: right 18:30:13 Kaiwei: also, periodic update of counters will get give stale values, not of much use 18:30:42 Perhaps this is too implementation specific, but what if there are multiple firewalls with the rule. Is the counter the sum of the counts on each firewall? 18:31:13 ok, probably my misunderstanding 18:31:16 BrianTorres-Gil: we want to pull the counters based on rule_id and firewall_is 18:31:26 firewall_id 18:31:56 i would prefer to leave the aggregation to another extension 18:32:04 thoughts? 18:32:09 ok, so counter is per rule and per firewall. 18:32:21 BrianTorres-Gil: that is the current proposal 18:32:50 we would like to enable the "elemental" API 18:33:12 BrianTorres-Gil: perhaps we can make firewall_id optional 18:33:39 so if firewall_id is not present, then its an aggregation 18:34:00 that said I am worried about supporting this aggregation in the reference implementation 18:34:08 and this is completely driven by the vendor implementation 18:34:51 SridarK: that is true, but if we say firewall_id is optional, the reference implementation will have to support aggregation across firewalls 18:35:10 SumitNaiksatam: supporting on the reference would be a stretch 18:35:20 we can keep it simple 18:35:28 SridarK: yeah, thats my concern :-) 18:36:03 ok lets think a little more how we can handle both scenarios (and not have to support in the reference impl) 18:36:30 #action BrianTorres-Gil SumitNaiksatam SridarK to sync up on aggregate counters 18:36:41 any other thoughts? 18:36:47 one question 18:36:55 Kaiwei: go ahead 18:36:56 could whether it is optional or not be vendor specific ? 18:37:07 will a rule be shared by multiple firewall policies in icehouse? 18:37:21 Kaiwei: not in multiple policies 18:37:36 but the policy can be shared in multiple firewalls 18:37:52 Kaiwei: this is also a part of the commit operation discussion 18:37:58 i have it on the agenda if we have time 18:38:16 ok, so the aggregation is on one rule applied to multiple firewall? 18:38:33 Kaiwei: yeah, that's what BrianTorres-Gil is referring to 18:38:48 got it 18:39:11 SridarK: yeah, to your question, yeah lets think more on this 18:39:16 next topic 18:39:18 #topic Service Objects 18:39:19 ok 18:39:28 proposal is to capture protocol, port, and timeout 18:39:39 this can be used for source, and destination in a firewall_rule 18:39:54 the port can be a range 18:39:58 what timeout is about? 18:40:01 beyounn: ok 18:40:06 beyounn: over to you :-) 18:40:17 Kaiwei's question 18:40:28 The service timeout is used to control a session the life time 18:40:56 you can define a service witha timeout and bind the service to a policy 18:41:10 when a session hits on the policy, session inherit the timeout value from service def 18:42:13 beyounn: so you mentioned you wanted to put a blueprint for this? 18:42:23 got it,,,,just wondering how many venders have this kind of support.... 18:42:25 Sure 18:42:37 or, if you want to create it, I can filling detail later 18:42:57 Kaiwei: it seems some vendors are supporting this 18:43:00 Kaiwei: juniper and us 18:43:10 Kaiwei: but we don't have to make this a required field 18:43:15 it should be optional 18:43:20 sure 18:43:21 beyounn: agree? 18:43:28 Iyes 18:43:36 ok 18:43:56 #action beyounn to file service objects blueprint 18:44:11 BrianTorres-Gil: you have thoughts on this? 18:44:21 Also, I think we should we have one service per rule, instead of two per rule 18:44:41 Kaiwei: can you explain? 18:45:07 you mentioned we need to have service objects for source and destination 18:45:11 ah ok 18:45:20 but the protocol/timeout...etc will be same, only port will be different 18:45:28 Kaiwei: ok 18:45:46 so I think one service object which include src port and dst port should be sufficient 18:45:53 yes 18:46:08 In the service objects seems a strange place to put a timeout, I would connect a timeout more with a rule. But this is implemented differently in each vendor so hard to say what works best for everyone. 18:46:14 Kaiwei: so you are saying rather than use source/destination for this, we have a new attribute for service 18:46:35 yes 18:46:37 let me give a short list 18:46:46 in a service object, we can have: 18:47:12 name, proto, port (or port range), timeout 18:47:37 the ports are source and dest 18:47:53 proto and port are mandatory? 18:47:59 i would assume they are 18:48:26 I think proto/port are optional.... 18:48:44 kaiwei:yes 18:48:53 Kaiwei: if they are optional, then the service object is meaningless 18:49:08 you can just use the basic firewall rule attributes 18:49:28 I mean, you can have a service object with only dst port, or service object with only protocol but no ports 18:49:33 i would imagine that the service is characterized by the protocol and source/dest ports 18:49:45 SumitNaiksatam: an empty service object means match all 18:49:56 garyduan: why would you need that 18:50:05 garyduan: its match all anyway 18:50:31 Kaiwei: i would still argue that at least source or dest port is required since that characterizes the service 18:50:37 Is current protocol in fw rule optional? 18:50:50 It makes sense to me to have proto, srcport, dstport. And srcport is optional. 18:50:54 Then one service object per rule. 18:51:11 garyduan: protocol is optional in the API 18:51:18 garyduan: the CLI requires you to use it 18:51:23 BrianTorres-Gil: agree 18:51:29 okay we are running short on time 18:51:30 SumitNaiksatam: ok 18:51:31 if you have protocol, then port has to be there 18:51:31 SumitNaiksatam: Then how to createa rule says: allow all tcp traffic? 18:51:48 Kaiwei: that is already supported in the rules today 18:52:06 okay let beyounn create the blueprint and we can pick this discussion up again next week 18:52:18 #topic service_type framework and insertion 18:52:24 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-service-types-integration 18:52:39 seems like gardyduan has already implemented something 18:53:08 this part is more mechanical though 18:53:17 #topic revisit firewall to firewall_policy association 18:53:33 i don't think we have enough time for this discussion 18:53:54 let's circle back on this next week but i want to bring this up to plant the seed 18:54:15 #topic Zones part deux 18:54:38 Kaiwei: go ahead, trying to make sure we get back to your question 18:54:57 ok 18:55:02 so you think group of neutron ports does not represent a zone? 18:55:27 if we use ports as zones, what if we have two ports connected to same network (or subnet), each is in different zones? 18:55:50 it looks odd that two ports in same network (or subnet) are in different zones... 18:56:01 Kaiwei: yes 18:56:17 Kaiwei: however, i doubt it will be used that way 18:56:41 I think it would be unusual to have two FW ports on same network/subnet unless you're doing link aggregation. 18:57:20 some FW doesn't allow two interfaces on same subnet 18:57:52 but I think most can have multiple interfaces on same networks but different subnets 18:58:11 also, what if this is for two ports are for two different FWs? 18:58:45 it it shouldn't be used this way, why not define zones as networks (or subnets)? 18:58:48 Kaiwei: the problem is that we don't have an alternative to using neutron ports 18:58:51 if it shouldn't 18:59:41 does subnet work for the other firewall vendors? 18:59:56 no 18:59:56 lets continue this discussion over emails and in the next meeting 18:59:58 it does not 19:00:04 we have to yield to the next meeting 19:00:07 thanks all 19:00:13 #endmeeting