 You want to start with an intro? OK. Welcome, everybody, to the firewall talk. My name is Kamanaik Berger from HP Helion, soon to be known as HPE. I am Vishwana Jayaraman from Rokate. And I'm Sridhar from Cisco. Been working on F4s for a while now. Anyway, so let's get things started. I mean, I think a couple of things that we wanted to really do is that I think first off, to say, why are we here today? I mean, F4s, as some of you who are following it know, was started in Havana. And from that point, there have been some changes. But at some point, I think possibly as we came out of the summit in Vancouver, there were some concerns that were expressed in terms of the API, the applicability of it. And then it was probably in August when Kyle, the then PTL of Neutron called a few of us and said, hey, I mean, we are serious about F4s. And we really wanted to jumpstart this and get this going. And let's kind of take a fresh look at requirements. Let's see what we need to change and get that moving. And that's kind of where we landed up over here. And as a team, I mean, we are kind of a collection of people with different affiliations. I mean, in some sense, the contributors are mostly vendors in some form. We do have, German is from HP. We have some kind of operators. And I think today what we really want to do is that we want to get give you guys a feel of where we are, where we are going. And we really want to encourage some conversation with users to make sure that whatever we are doing with this restart, we are building something that with user input and we land up in a good place finally over next couple releases. So that's kind of the motivation. And for today, really, what we are covering is, yes, I mean, this is not a talk where we come and tell you that we have done these things and there is no demo that we have to give. I mean, we're kind of starting things off. Doesn't mean that we're throwing away the existing code, but we're trying to adapt that to see what we need to change in terms of the API. And that's kind of, and then layout sort of a roadmap as to where we are going. So that's kind of the outline for what we want to present today. And where FOS is today, essentially what FOS is doing is that it supports North-South perimeter firewalling. And we have issues with DVR interactions on East-West flows. And so this is one issue that we have. And the other thing is that FOS, when it started off, it didn't really have a place where you associate a firewall. The firewall was associated with a tenant and essentially was applied to all routers in the tenant. And from that over kilo, we moved that along to a model wherein it is associated with a specific router list. And in talking more and thinking more about this, it seems that it's more applicable maybe at a router interface level than putting it on a router. That seems a bit too nebulous. So that's definitely one of the issues that we have been seeing. And even as we added support for the router, we always had that mentality that maybe we do need to keep the port as an option, which seems to make more sense than putting it on a router. And the other big drawback is that FOS is kind of very router specific. Even if we did bring it out and say, let's put it on the ports, it's essentially very router specific. And we are getting a lot of interest and people talking to us and saying that, hey, how do we solve the VM to VM traffic firewall use cases? And so that's something that we really, there is a lot of interest in that. And then that immediately kind of leads to, OK, so now what is the intersect with security groups and what is security groups, what is FOS? Some of the discussions has been that with security groups. I mean, it's an established API, and there is some reticence to kind of go out and change that API for compatibility reasons with AWS migration and things like that. So in some sense, we are kind of hitting a little bit of muddy waters in terms of how we coalesce these things to exist together. But this is one of the things that we want to go after right now. And the other thing is with service chains, containers, I mean, there is a lot of interest, especially for vendor firewalls to plug in. I mean, today, there isn't, while as vendors, we do support our firewalls, but there isn't a fantastic way to plug in kind of an appliance. And that's something that with the evolution of service chains, and that's something that we also want to get to. So the big thing right now, as I kind of alluded to, is the evolution of the API. And I mean, right now, we're kind of throwing some ideas around to see what the API should look like. Things that kind of, what we really see is that we definitely, we see this need to go to a port-based model as opposed to a router-based model. And when we say port-based, we also want to make it more generic so that we are not kind of very router-centric. We wanted to address the VM use cases as well. So this is one of the major things that we are working on. And the other aspect kind of related here is that in terms of roles and how you deploy firewalls, and in a tenant environment, you may have someone like a tenant admin that might want to enforce a particular firewall policy that is enforced tenant-wide. And there might be users, kind of like the security group model, where app guys may want to put in their own firewalls. And how do you kind of coexist these things? So this is another aspect that we are trying to see what we can capture onto the API. And the other generic things is like, how do we do some kind of grouping mechanisms? I mean, we have had a blueprint out way back where we talked about address groups. Now, if you want to think in terms of from grouping mechanisms that you can use in rules, as well as grouping mechanisms that you might say where you apply a firewall. A firewall is applied on a set of ports. A firewall is applied on all VM ports on a tenant. So we are kind of looking at some of these kind of grouping mechanisms in terms of how you apply the firewall. And then kind of the other thing is how do we interplay with the security groups? And this is going to be like a big discussion in terms of how we actually affect that. German is going to kind of lay out some of the plans and how we move forward with some of those aspects. The other area where things were broken was on East West Firewalling with DVR. We have had discussions with the DVR folks. And I mean, there are some ideas around that, but this is not a very straightforward, simple problem to solve because DVR kind of introduces an asymmetric model with respect to routing. And F was inherently because of connection tracking, we kind of have to see where you apply the firewall. You have to see both sides of the traffic. And DVR kind of breaks that assumption. So there are ways to solve this. And now what is the optimal way to solve it? And maybe as we move towards a VM port model, maybe this is less of a problem. So that's some of the things that we are thinking about as well. So yes, we are trying to kind of go through the API and come up with this. What would be ideal is to say that, oh yes, we've kind of gone through this whole API model. And here is this complete lay of the land and what the API looks like. And then we start working on it. But really what we are saying is that that's probably in terms of velocity that's probably going to hurt us. So the approach that we are taking is that we are working to getting crystallization on the API as a long-term objective. And as some things fall out and we have clarity, we want to kind of attack those things in the M-cycle itself. So I mean the router interfaces, I think we seem to be kind of fairly unanimous on that aspect. The VM ports, yes, I think we absolutely want to do it. There are some challenges with VM ports, especially with how you interplay with security groups. We do want to see if we can pull that in with respect to Mitaka. And service groups is another notion wherein you have a grouping mechanism for protocol and ports so that on a rule, on a specific endpoint, you could specify a whole bunch of protocol or port kind of grouping. So this is something that's happened in the past. I mean, the reviews have been out for a while. So maybe we might kind of pull this in. And then zones is another thing that's a long ask for as a basic firewall feature. Let me hand it off to Wish to talk more about that. So what I'm going to talk about is in zones is actually just give you guys an overview. It's not about what we're going to be implementing. This is probably what it will look like, but I just want to introduce the concept of zone-based firewalls that we think will implement in the upcoming cycle. So in general, most of you must be aware that ordinary firewalls, when applied to a parent, or it's a rule set applied on a per interface basis, which means any traffic coming to the interface, you actually do some packet filtering at that point of time. So if you want to take it to the next level wherein you can actually group interfaces so that those interfaces become part of a, where the same security policies applied to those group of interfaces, which will be the zone. And they'll all share the same security zone. So here, the packet filtering will be applied at the zone or the group of interfaces level. That is what the zone firewall would be. And any traffic flowing between the same interfaces as part of the zone, there won't be any filtering happening there. So that gives you in a nutshell what a zone-based firewall would do. Additionally, next slide. There are other things, key things as well, some criteria, but we may not get to everything. This is again, just introducing the concept and saying what could be part of the upcoming release. Other key features, other key things you might want to be aware of in a zone-based firewall is that, well, any traffic coming into the router and going out of the router may not be filtered, right? That's the other thing. And other constraints would be that if you have a interface that's part of a zone, it cannot be part of another zone. So it can only be part of one single zone. And you, any, if you actually have any interfaces that are not part of any zone and if you don't have any rules that apply to the interface, any traffic can flow unfiltered. And any traffic between interfaces within the same zone will be unfiltered. So this is the kind of thing we want to use and sort of think about how we apply in the upcoming release. So this is one thing we are identifying, but there are other things also we are looking for in tactically and also that's where German is actually, German is actually going to go through what we can do tactically and what we also have a long-term roadmap. I'll hand it over to German. Thanks. Okay, so for in the next cycle, let me talk about a couple of generic cleanup things that are needed. So to basically deal with current pain points. So the L3 agent, how firewall is going into is pretty messy. So we need to fix that and add it to the observer hierarchy to have a much more cleaner insertion. So just to move forward. The other thing is the test coverage. So tests have been changed in Neutron and we basically need to move our tests in three now. And as we want to increase our test coverage, basically to get earlier with the box and everything. And right now our automatic tests are not very good. So we need to set up an automatic gate. So every time we check something in it gets basically tested. So the whole testing thing needs a lot of improvement. Now I want to talk about what we did during the Liberty Cycles. So we got together in Seattle for a mid-cycle and we encouraged the community beforehand. So when we were in Vancouver, I said let's collect all the use cases or your requirements, what you expect from firewalls and also what you expect from security groups. So we can basically understand what does community want out of this API and what makes sense to move it forward. So we collected all of them and we sorted them into a Trello board. And basically we looked what is covered by the Security Group API, what is covered by the existing firewall API and then we identified the gaps. What needs to be added to the firewall API if we would leave it today, how would need to be evolved to basically to have all the things the user wants and then as a gap switch where both in the Security Group API and the firewall API and then we decided a few things which we felt were out of scope for either the firewall API or the Security Group API because they were just not something we felt should be done there and then there were things which are okay, it won't fix you. Guys, all this happens to stuff we felt we shouldn't even cover at all. Out of scope means more we might want to do it in the future and won't fix, probably it's more than the thing of never. And then we basically flagged them all and sorted them all which is a good guiding for us and then we now go and develop a new API and develop improvements then we have all those requirements and can see around them against our API can actually do those things with this API we are proposing. That's the next slide. So this is a rough component design probably will look different when it's realized but one thing we learned early on when we started working on it is the Security Group API is laughed. People really want to retain that they can't really deprecate it and so what we are trying to do is we are trying to do this kind of dual thing. We want to have the Security Group API API we want to have our new API the Firewall as a service API rebooted with lots of lots of new features but we want them all go to the same back end so there's one source of truth because the current thing which annoys me as a developer is I might open a port on Security Group API but it still doesn't work because someone in the Firewall API somebody blocked that and so what I really want is this one back end where people then one source of truth so I can see in both APIs what's being blocked and what's available. Of course, so basically if you're a fan of Security Group and nothing will change you can use it like you do today will all be the same but if you then start touching a rule you might have created a Security Group API with the more enhanced API then of course you will basically then switch to read only and you can't touch it again because the other one has much more features that are not replicated there and so over time we hope that people will migrate over to the new API but that's one of our hopes. On the other things at the bottom but another thing we learned is the Firewall space is just a very small picture small piece of much bigger security parcel and we need to be very adaptable very blockable to basically allow for those complex scenarios people might want to do. So you want to have a firewall insertion plug-in because you might want to use IP tables to put it in as our thing. And a firewall insertion plug-in you might want to use a service chain to do that or might be another way to do it with OVN or OVS or whatever you have there. A packet capture is something which got a lot of ass by people locking out packages and then maybe shipping that to analysis software which looks for anomalies in your network traffic and then makes decisions. So you want to enable that or maybe tap into a tab as a service but make it blockable so we can block in whatever makes sense there and the hard piece of firewall is packet filtering. We also want to make that blockable because you might want to use the IP tables you probably go for reference implementation but you might want to do an SDN thing to drop things like we have seen that thing OVS they now have security groups implemented there so we want to make it blockable and flexible enough that all those things can be covered with our design. So the other thing what we did in Liberty we basically deprecated the firewall as a service API. It has been experimental for a while and never gained enough traction that people didn't really use it the way it was supposed to and so we decided to kind of deprecate it so we can move on. It doesn't mean that it's going away immediately so we don't have a new API so we don't want people to be without firewalls in Liberty and so I think it's not going away immediately but we want to make sure that everybody understands you shouldn't bet your farm on that you shouldn't make now the biggest firewall plugin ever for it or make the biggest automation ever for it because it's going away and what's important for us and I learned at the hardware I did load balancing V1 to V2 and we didn't do any backward compatibility and we learned at the hardware that it's not how it's supposed to work and I'm saying the API might not be backward compatible but we need to include the vendors so it's not always that vendors want to make the step from the current drivers to the new API and so we need to make sure that we kind of are backward compatible enough that the driver which right now works in the old firewall API continues to work in whatever we develop either by getting those vendors engaged that they kind of make the adapter drivers or that we kind of add to the compatibility layers so they can basically run the old drivers might not have the full functionality but it still works so customers or operators or users are invested in those appliances they are not suddenly discovering if you upgrade to Mitaka or N or whatever you can throw this device away you don't want that so we came up with a road map and we want to enhance the test coverage it's very important and the reason we want to do that is we want to do test-driven development for API redesign so as we develop the new API we want to develop the test to basically immediately test that and when we look at our API redesign we absolutely want to go port-based and basically I interpret that as a neutron port because everything is going to a neutron port service chaining is connected to neutron ports we have Korea which exposes containers as a neutron port so this is I think the right integration point for the firewall to integrate into neutron the other thing we want to do we want to augment security groups so people who want to try us out and right now today use security groups they can go over and have similar or the same functionality maybe even more so it's worthwhile for them we want to make an IP table space reference implementation because without a reference implementation you can't really do anything in OpenStack and we also want to work on service groups which is a grouping mechanism grouping is very important to make it easier for users we don't want them to write millions of source destination we want them to have higher level constructs than that then so that's our goal for Mitaka and depending on how many people we work on then we might get it done, less done maybe more done, never know but going further on in N we want to improve our reference implementation so going port-based introduces one important question is so right now we have routers and people have far less routers than they have ports in their installations so going port we will basically need to get better scalability we need to basically figure out ways to more efficiently push updates to our firewall because we have now much, much more insertion points we have to update, we have to manipulate and so scalability is a topic then for N to make it actually work for bigger clouds not just DevStack and then HA that can be really used figure out how we can do HA the other important thing which talked about is zones we'd love to have them much, much earlier but one fear we have we really want to get the API out in M in Mitaka so we put zones into N but if we have enough room in Mitaka that things go even faster than we thought that we have more contributors and there's lots of excitement so we talked to a lot of people and it seems engineers are coming from everywhere to help us so maybe zones are making it into Mitaka but we are hoping have them for sure in N then for O we want to integrate with a lot of things which are currently developing the community there's the service function chaining so we think it will be mature enough in O that we can fully integrate with that and kind of leverage them for our service insertions and also be a part of their use cases because when you look at their presentations there's always the word firewall in there and so we want to beat that firewall so we want to do that in O but an exciting thing happening in the community is the common glass fires want to leverage them want to be compatible with them we think they will be mature enough that we can integrate with them and the other thing we want to have finished there's the common back end for security groups and firewalls that doesn't mean that we haven't developed it yet but our goal is that in O that we have shown enough development, we have shown enough functionality we have proven ourselves enough that basically in the O release that we will be there right in the box with firewall as a service and have the common back end as basically the backwards compatibility for security groups because what's happening is security groups are they are right in the box whereas people have to install us as an extra and we hope by O we have proven enough that we can convince people to put us in the box and then kind of become the default way of doing this security firewall-ish security in an open stack and of course by then we will have lots of tech debt we have to pay off okay let me talk about how you can help so we have a channel called OpenStack Firewall as a service where we all congregate and join that channel, say hello and then we will say hello back and so we can start contributing the other thing we have is we have weekly IRC meetings right now they are Wednesdays on 1830 UTC for the North American Europe bunch and then we have one on first days it's a zero UTC where we encourage Asia Pacific but we probably gonna change that a bit because we kind of picked up a bunch of people out of Bangalore and that's not convenient for them so that might change but right now that's where we are and we always try to publish the agenda so people know what they expect not a great way for you to contribute is if you see that something is missing or a very mistake then you can file a bug on RFE for your idea and you can add it to your agenda and you can talk to it and so then we can collect that and then sort of project manage that in launch pad and if you get serious about helping us then you need to sign the contributors license agreement or whatever else will replace it and then you can start helping us in Garrett can code review we are always looking for code reviewers and that's actually the best way to get started in OpenStack is reviewing code to see how things are programmed, how things are written and so yeah, a lot of code reviewing can write code, it's a good thing, we like that can write documentation documentation is very important for us so some projects are more like an afterthought but we wanna really have good documentation because we really count on that this thing has a right adoption if you don't document it right people won't know how to use it and then they won't use it so documentation is really the corner piece of our strategy get people use it and so we need documentation and of course you can help if people ask questions in the ISE channel know the answer, be sure to jump in and the other thing we wanna do is we wanna do a mid cycles very likely sometime in January, February, next year in Seattle, so if you like Seattle you should plan on coming and yeah, invite everybody, questions. IP tables, reference model and I have a question different update in the reference imprimary station supported? Say it again. Is there supported or different update IP tables? Oh, another implementation like something like IP sets is that something like a back end other than IP tables? Is that your question? I'm not. IPv6 and IPv4, IPT was... You can do IPv6 and IPv4? Yeah, we do support V6, even today. Yeah, we do support V6. IPT is known as an OVS, it's a part of our strategy. So it is on the line, technology has some space problem in the approach table. Have you considered providing the API a part of our service to mark, to give them your opportunity to mark the project and then act on that? I mean, I think, yeah, so marking is probably a little bit out of our, you know, our actions are more of permit deny, but there is a QoS project which I'm not sure what, if they've gone beyond limiting, but probably marking is in their roadmap. Yeah, so I think one thing is with DPI or any classification scheme, we hope that in neutron, we get to a point where you have a common way of classification and that might be something that might feed into a QoS mark action or a firewall action. Hopefully we'll kind of lead to that eventually, but today we are not there yet. We are not there. Yeah, we want to do common classifiers later and also in O, so that's when we want to think more about marking. Is there some call to action for helping with this new API, especially when you're moving to ports and zones? This is a call to action. That's the call to action, yeah. So basically, you know, everybody has to start giving their use cases and beating up on that API, I think. Yeah, so I think one thing that we also should do is that I think we'll make sure that we kind of link all our ether pads and all these things into our OpenStack FOS wiki. So that way it'll be easy for you to, I mean, today everything is not linked, but just give us a couple of days and then hopefully just a Google OpenStack FOS wiki will get you to the wiki page and we make sure that we kind of have everything linked and you guys can jump in there. And we'll definitely start with a set of OpenStack pauses and wide specs for all those things. We encourage everybody to look through the specs, make sure that we can review them and everything. So yeah. Can you elaborate a bit more on the service groups? Because I'm thinking from a device technology, it looks like address books and application sets. Yeah, it's very much like an address group. The service group terminology is more to talk about, you know, to have a collection of, you know, protocol and ports and you can, so instead of, I mean, the motivation for coming up with it, of course, this came up like about three cycles ago. The motivation was rather than having multiple rules, I mean, with the rules looking like, you know, source IPA to test IPP, you know. Port 80. Port and then again, source IPA test, you know, if you wanna filter on a bunch of, you know, a protocol or port entities on two similar, two identical endpoints, this gives you a grouping mechanism so that, you know, you create one, you write one rule and that creates an indirection. So that's the whole idea with service groups. As I have this documentation, you can call it like HTTP server and then you'll have it on something and then you know, that's all the things for you. I think it's also gonna help, right? You want to, same rule to be applied on bunch of ports or bunch of application, like. The same rule, I mean, so now, the way at least the FOS is structured is that the policy is reusable. You can take a policy and apply it on different, at, you know, different points. The rule is bound to a policy though. Question. Where's the firewall function deployed in a network, a network known as OVM or OVS or DVR? Where? So I think that's one of the things that we want to solve here in that today it's deployed only on the router but we wanna kind of make that change so that our binding is more with a neutron port or a collection of ports. So then it could be on a router interface, it could be on a VM port as well. Now OVS or, I mean, there I think we kind of hinge on where, when it comes to VM ports today, you know, security groups are, you know, put in a Linux bridge sitting in front of your VM and our implementation will probably go that route but as Garmin mentioned, if you look at OVN, OVN is trying to put security groups into OVS and which means that, you know, if that happens in neutron, so we will take that from this one. Yeah, we wanna be as blockable as possible so that you could have an OVN driver which then kind of takes our model, takes the stuff the user created for API and kind of puts it into OVN. So that's why we wanna be as flexible and as blockable because things always change and there's lots of technologies wanna support but we wanna be the API for them. Yeah, and I think the other thing is we'd love to hear from users and that would be the, you know, that was kind of one of the motivations for doing this so that we can at least connect with some people that can help us drive some use cases and, you know. Yeah, absolutely. It's still too, I think it's still too early to know how we wanna achieve the scalability goal. There are some things service groups that get more scalable, we wanna study that and understand how it all worked but we wanna first see how the implementation looks like, how we get to the ports and how the agents look like, we put out there and then when we have that figured out then we are gonna scalability in more detail. Got it, that's it. All right, thank you. Thank you for attending.