 Hi, hello, everyone. So we are here to talk a little bit about where FWAS is right now, talk a little bit about things that we have accomplished over the last couple of cycles and things that are in progress right now and where we are headed. So my name is Sridhar, and I'm one of the course on the FWAS team. I'm Chandan. I work as a contributor to Firewall as a Service team. Yes. I'm a user of Rukawa, and I'm contributing Firewall to our team. OK, so let's get started with just a little recap of where things were. FWAS started in Havana, and it initially started off with deployment model, which was a little bit weird. And there are some reasons to that, too. And it was deployed. If you enabled FWAS, you got FWAS enabled on all routers on that tenant. And not really ideal, but yes, it did work. But one of the reasons behind that was that, at that same time, there were a lot of efforts with service insertion and chaining that was going on. And the idea was to decouple a service from where a service is inserted in. And this was a temporary default behavior that stood there, and we did get a lot of flak for that as to why this is all router deployment, which made no sense. But what happened was with the service insertion things really didn't quite take off for a while until now when we start having SVC, SFC projects. But at that time, given that that was not going forward, then we made a change to make it deployable on a user-specified set of routers. So that's kind of where we started on the first cut of V1. There was some talk of installing it on router ports, which seemed to make more sense. But there was some confusion in the community about, yeah, maybe we should just start with the routers and before we headed off to ports. So the ports thing, that idea was present early on, but it didn't quite happen. But that's a little bit of what V1 was. And then around the time of Tokyo, there was interest in saying that, well, we are at a stage where this is not very effective in how it is deployable. It would be nicer to maybe look at it, to take a fresh look and look at things that might be relevant and things that we could do differently. And first off, immediately the first thing that came to mind was from an L3 standpoint to make it deployable on a user-specified set of ports, which kind of makes more sense. And that was like step one. And other things that got thrown about at that time was to look at L2, maybe a unified treatment for L3 as well as L2 ports. And now there is security groups. And then I think we have kind of debated that back and forth in terms of, well, there is security groups on VM ports. And now there is FWAS on VM ports. Now what is the difference? Is one better than the other? Or should security groups kind of take on the features of what FWAS is trying to support? And we kind of went through these debates. Today it seems that the consensus seems to be that let's leave security groups as is for now, for reasons AWS compatibility was one of the things that got brought up. And as a simple model, which is a whitelist kind of model with security groups, we kind of leave that intact. And let's look at FWAS V2 on L2 ports as well. Sort of we are kind of on par with security groups. Maybe the richer API can go into FWAS and security groups is kind of kept as is as a simpler model. So that seems to be the thought process of the day. Well, maybe things might change, but this is the kind of assumption that we have been going with. And this has been discussed, and this is where the neutron community seems to have come to as well. The L2 profiles in the L2 port, I think the other things of interest over there is that because of internal attack profiles, there is definite interest with applying FWAS on L2. And to maybe eventually take that API to a point wherein you could potentially support something like L4 to L7 to do an application-based firewalling and things into the future. So that's sort of some of the genesis of it. But basic idea is that to support it on neutron ports, L3 or L2 and kind of treat them in a uniform manner. So that's where we are headed. And when it comes to L2, one of the big things is how do you coexist with security groups? So if you had the security group driver enabled as well, how is your firewall L2 going to coexist with that? So there are some things into that. We'll get into discussion on that. But then again, this is completely you could have a scenario wherein you could do a NOAP driver for your security groups and just have FWAS for your L2. Or you say, I don't really care about FWAS for L2. I want to stick with security groups. That's fine, too. So it's kind of at whatever the user wants to do. And the other thing that sort of got brought up as requirements is to look at multiple layers of security or maybe a role-based security model. So something that as a firewall user, user defines their firewall rules for their filtering. And now an admin might say, well, over and above that, I want to enforce an admin-defined firewall rules that will always exist irrespective of what the user puts on top of that. So those are some thoughts that have been batted about in the context of V2 as well. So the API is available from Newton for L3. And it is port-based. And you can have a separate policy for ingress traffic and egress traffic. You might be more crazy about what you want to do on ingress. And with egress, you might be a little bit more lax. So you certainly don't want to treat ingress and egress the same way. So we can support that direction-based firewalling. And L2 support is what is being actively worked on. And we hope to have this up in Pyke as well. And the API, no different across L3 and L2. Basic V2 resources, quite similar to what we had in V1 with a little bit of some things that we took care of. A firewall rule is your basic elemental resource. It's your filter specification. Right now, it's just the basic five-toppel protocol source, IPs, and ports. And then you have an action. It could be permit, deny. Yes, people have talked about redirect actions and things as well. But right now, what we are going with is to support permit or deny. A policy is an ordered collection of rules. And a rule can be people. If you have a rule, you might want to reuse that rule across policies. Yes, we can do that. V1 had a little bit of a funky thing wherein you could not do that. But we don't have that restriction anymore. And the firewall group is essentially what was firewall is now called a firewall group to show a little bit more of alignment with security groups, firewall group. So it's just a naming thing. And it's essentially, so a firewall group is a collection of an ingress policy that you might want to have for your ingress traffic, an egress policy which could be completely different for traffic that's leaving your port, and that set of ports where you want to apply these policies on. So that collection becomes a firewall group. So the policies and which set of ports you want these set of policies to be applied on, and what happens on ingress, what happens on egress. So that collection becomes your firewall group. And a policy can be present in multiple firewall groups, but right now we are sticking with this restriction of a port we can only have as a part of a single firewall group. Because we don't want to have multiple security rules layered on top of a port. I'm not sure about the use case, but for that, so right now we are just kind of preventing that. Where we might revisit that is more in this multi-layer security where there might be a role-based kind of security policy on a given port. So that's kind of where we are. Just a little picture showing what I just said. Group, policy, policies are a collection of rules. And then you have these kind of ports that you associate with a firewall group. I mean, you could create, again, the ingress egress, they are kind of optional. You don't have to have both an ingress and an egress policy, because you might just say, well, I don't really care about egress traffic, and you may not have a policy that's totally fine. You could create a firewall group as sort of like a template that you have created. You don't have to have ports associated. You can always do an update operation later on, and add ports to a firewall group. So that's totally fine as well. Where we are to talk a little bit about implementation as it stands now, so we have a data model which is consistent across L3 and L2. L3 is what is already there, is present today. The data model is consistent, so that's done. We have a plugin for the reference implementation, which is done, and again, consistent across L3 and L2 with some minor tweaks that are in progress for supporting L2. And then the other big thing that happened in the Newton cycle was that we had a contributor work on the L3 agent extension framework. In the past, with V1, the L3 agent binding was really, really ugly. There was no way for L3 agent to accommodate services, and we had this hard-coded, bolted inheritance model, which was really ugly. So we finally managed to get rid of that, and then we have an L3 agent extension framework along the lines of an L2 agent extension framework, which was done in Neutron to support QoS. So we have an L3 agent extension framework along those lines to support L3 services that can get integrated into an L3 agent in that umbrella of an L3 agent. So that work was done as part of Neutron Core, and it's now become part of Neutron Lib, and it is available for other L3 services that come along. I know VPN is going to get resurrected, so VPN could use that same model as well. And we were the first consumers for the agent extension. And then for L3, the driver implementation is IP tables based on the Neutron namespace router. Nothing great on that. The other things that we went through as a Neutron subproject was that there were some stadium requirements that were laid down for subprojects. Kind of broadly, these were the buckets that we had to meet some of these criteria to be called a Neutron subproject and be a part of the Neutron stadium. So one of this is, how do subprojects integrate with Neutron? The primary thing here is being adoption of Neutron Lib and removing direct Neutron imports. So that's something that we have accomplished. And then there were a whole bunch of CI requirements, which are kind of normal things in terms of your Pepe, UTs, Tempest, and then scenario tests and things like that. So we have those things chalked off for the requirements as well. And then the other key thing was to move from Python Neutron client to OSC as your client front end. So we have that done as well. So there are a few items that we still do need to cover. But I think most of the things have been accomplished for us to be signed off as to being part of the Neutron stadium. So let's kind of jump into the L2 implementation here. So one of the things is that we really, our initial target was to get L2 support in Ocata, given that L3 was done in Newton. But the IP tables, interaction, and coexistence, the security groups kind of turned out to be a bit of a nightmare. And then we were kind of spinning on that until the PTG with the PTL. And then we had some discussions. And with Neutron's current shift in heading towards OVS-based implementation for security groups, it seems that this is a much simpler model for us to follow as well. So we have kind of doubled back our efforts into shifting gears and then getting on to OVS. So Chandan will get into more of that now. Let me hand off to Yoshiro, who has done a lot of the work with the L2 agent and existence and so on. So go ahead, Yoshiro. OK. Hi. Let's dive into the L2 agent implementation. So here is some tables for the event for handle some, sorry, about firewall group. So the event for two types of event can be handled. So one is a port, create, update, and port delete. And the other is the firewall group, and create, update, and delete. So in the L2 agent, we use the L2 agent extension framework. So this part is this is a VM port. So you should execute a notebook or open stack server create. And after that, this port is created automatically. This is a VM port. So L2 agent triggers when you try to deploy the VM, create, or delete. The other case, if you try to create, update, delete firewall group, so that is on user updates. These two events, L2 agent can be triggered. So at first, when VM has created, so VM port will be created. In this timing, L2 agent extensions handle port method is called. In handle port method, it validates whether a port is VM port or not. So currently, device owners build in port. If the port is a VM port, compute foo or compute bar or something is in device owner. If port is VM port, a default firewall group will be applied before VM booting. So after slide, I will explain what is a default firewall group. So on VM delete, so L2 agent extension delete port is called. So it also validates the VM port or not. So if it is VM port, the firewall will be removed from the port. On the other hand, so if user tried to create, update, delete firewall group, so when create, if the port option for firewall group is specified, firewall rule will be applied to specified ports. When updating, and if port is specified, firewall rule will be updated. So currently, firewall group must be applied at least one VM port. So if no ports are associated with user-defined firewall group, so these ports are applied to default firewall group. When delete the firewall group and if ports were specified, firewall rule will be removed from specified ports. And the default firewall group will be applied for this port. So let me explain about the default firewall group. The default firewall group is so same as the default security group behavior. So this firewall group exists project-wide. And default firewall group include the following rules following firewall rules. For ingress, to VM, it's deny all. And the egress is equal to front VM. It's permit all. So when default firewall group is applied to this VM, this VM can send some connection for such as SSH or HTTP or some such protocol from VM. It is allowed. But the other external communication from other VMs, this is denied. So OK, that is all for the L2 engine extension. Here is the L2 driver overview. Chandan, please. And I'll be talking about the firewall driver, firewall as a service driver. So as Sridhar mentioned earlier, our initial idea was to deliver this L2 feature by Okata. But we found a lot of complications with the IP table drivers and security group implementation based on the IP table drivers. And we were trying to do a coexistence of firewall as a service and security group. And due to that, we were spending a lot of time on implementing this IP table-based firewall. And then we had some discussions with the Neutron PTLs. And there was a clear direction given to us to look into OVS-based driver, which seems to be the driver to implement in the future release. So currently, our focus mostly is on implementing OVS-based firewall driver for firewall as a service V2. And I am currently working on implementing this driver for L2 ports. So in case of OVS-based implementation, OVS driver implements this firewall using tables. The tables will contain flow rules. And the flow rules are actually the rules that match and redirect the traffic. So for our driver, we have used five tables. Basically, this is in the same lines as security group OVS driver. And for our use, we have used table 41, 42, 43, 51, and 52. These five tables are actually handling a specific part of the traffic. So 41 and 42 are actually targeting egress traffic. So 41 is for base egress traffic. And 42 is for user-defined rules for egress traffic. 43 is actually where we either do a accept or pass it on to 51 for the processing on the egress side. We'll discuss each of this in more details as we go forward. Also, one thing to note here is we have to deal with the two kinds of situations in this driver. We have to take care of inter-VM traffic within the hypervisor. Or we also have to deal with traffic within the land, which are across hypervisor. So based on that kind of traffic that we are encountering or where the traffic is arriving, we redirect the traffic either to egress rule. That is, if the traffic is arriving from a VM port, that is essentially a egress traffic. And the egress rule should be applied. Whereas if the traffic is arriving on the patch port, we assume it to be ingress traffic. And it is directly passed on to the ingress rule. For any egress traffic that we encounter, we also need to take care that if the target of the egress traffic is on the same hypervisor. If that is the case in the accept table, instead of that is table number 43, instead of accepting directly, we should also do ingress traffic processing. So let's look into a little more details of this traffic tables. We have table number 41, which is the base egress table. And it has basic rules like allowing ICMPR and DHCP traffic. It also implements max poofing prevention. And any user-defined rules are actually populated in table 42, which contains all this user-defined ports and to allow traffic into certain ports. Table 42 actually will forward the traffic to table number 43, which is actually going to either accept the traffic or forward it to ingress processing if the ingress port is also on the same hypervisor. As I mentioned, table 42 will have this either either accept rule or forward for ingress processing. Now both table 42 and table 43 creates connection tracking entries for tracking any established or new connection. On the ingress side, we have table 51 and 52, which is again equivalent of 41 and 42. 51 is the base ingress traffic rules. And 52 is user-defined ingress rules that gets populated in 52. In addition to this, we use two different registers. Register 5 will hold the port on which a traffic packet has arrived. And register 6 is used to track a virtual network. So this is a very brief overview of the driver. We can go into details if anyone is interested offline. As for the current implementation or the current status of this driver, we have already implemented a standalone driver. That means with this driver, we were able to achieve data path validation. But it was not in coexistence with security group drivers. So we are currently working to make it coexist with security group driver. Also, we have some bugs to fix on the agent side for port updates and taking care of the default parable group. I'll now move into a demo to show you this driver in action. Yeah, and also I think Chandan will do a walkthrough of some of the changes that he has done in terms of the OBS implementation to at least give a small demo of that. And the other thing is that we also have a dashboard as work in progress. And we kind of have a little snippet of that. We were not brave to do a live demo, so we just kind of recorded it. And we're going to do that. So a dashboard kind of gives you an idea of where things are headed. All these things are, there are patches out, and it's work in progress. And definitely, the goal is to get it in-bike. So that's kind of what we are shooting for. OK, so I'll get started with the demo. So basically, we look at the workflow, and we start with two servers, VM1, iPhone 1, and VM1, iPhone 2. Both the VMs are connected to default security group. And basically, we made sure that the security group allows all kinds of traffic. So from a minimum of 1 to maximum of 65,000 ports, we have allowed all TCP traffic. In addition, we have also allowed all ICMP traffic. Basically, we allowed all kinds of traffic through the security group implementation. And these are the two ports that we'll have our firewall group implemented on. So at the beginning of this, we have a default firewall group, as Yashiro mentioned. And this default firewall group will have both the ports associated with it. That means the default rules that applies to these ports. So we'll dive into the CLI of firewall group. And we start with creation of a rule. Just to give a context, we have created a rule which allows port 22 to be allowed. And now we are going to create policies out of this rule. So we have an ingress policy and egress policy. And once we have the policies, we'll create the firewall group out of this policy. One thing to notice here is, although we have created the firewall policy, we don't have any ports associated at this time. And at this point of time, the firewall group status is inactive. At this time, we will log into the VMs and try to associate into each other. So we have 10.0.0.3 as the source address and 10.0.0.12 as the destination address. And at this point, the associate actually fails because, as you should have mentioned, at the beginning, we have the default firewall group and the ingress policy is to deny any kind of traffic. Also, we are gripping on the flows that has been populated on the obvious table. And at this point, we are trying to see if there is any transport layer destination port match for 22. And you can see there is no such rule. And the driver is supposed to put that rule whenever we associate the ports to the firewall group. Now we'll be associating the ports to the firewall group. And if you see, we have the rules getting populated. And now we have specific rules for destination port 22. This rules got populated, actually, in table 42, which is actually redirecting traffic to table 43, which is either going to accept it or pass it on for ingress processing. And at this point, if we try to do SSH, the SSH should go through. That's all for our demo on the CLI side. Should I continue with that? Yeah, we could maybe run a quick. Yeah. So we also have some development being done on the GUI front end. So here is a demo of firewall group horizon dashboard. First, we create the rules. And in the same workflow, we'll create policies and add different rules to this policies. So we have the ingress policy with two rules. Now we create the ingress policy and associate the ingress rules. And we have the port association going on. And you can see that the ports got associated. So I would like to mention that both the OVS patch and this horizon patch are work in progress and should be available in Pyke. Yeah, I think that's our address to get it out in Pyke. I think maybe switch to the slides. Yeah, I think the other things that we just wanted to throw out a quick overview of what our roadmap is looking for for Pyke are definitely our highest priorities to get the L2 support in and also get the dashboard integrated. The other thing is that we have tempest tests, but we definitely need to add more. And I think we realize that. And it's important for stability. And I think these are probably some of our highest targets for Pyke to make sure that we get things done and we have a stable implementation in Pyke. So the other things that have been contributors have stepped in. There are a few things with RPC improvements that has been done on the plug-in agent RPC. We had some inefficiencies that got covered. And typically, with large scale, I think some of these issues became more noticeable. And the other thing was a contributor worked through a replacement for connection tracking to use netlink, which is an alternate to contract, which is more scalable. They had done some tests. So we have done that with V1. We are yet to do that with V2. But we want to test this some more to make sure. And there is a broader agreement on the neutron community to see if this works out to use netlink and adopt netlink for a security groups and things as well. I think there are a few more things. ODL folks have been using Firewall as a service. And they need a little bit of tweaking in terms of how the post-commit, pre-commit things work. So we are talking with the ODL folks for how they integrate into Firewall. And I think for the subsequent release is that anything that spills over from Pyke, that's probably our first thing. And then we've had some conversations with vendor integration. Maybe SFC is the model here. L3 integration is a little bit easier. But with L2, there are some challenges. But it looks like we may be able to accomplish that with some tricks and OBS. So those are some conversations for vendor integration. Common classifier is definitely of interest. We are plugged into that discussion to see that if you have a common way of doing rule spec across features, which is a good thing rather than having each feature have its own way of specifying rules. And the other thing is that what we alluded to earlier with the multi-layer, like an admin role, an admin ability for an admin to define a rule set over and above what users can do. L4 to L7 is definitely, I would say it's a little bit of a pie in the sky thing, L4 to L7. There are certain complexities with L4 to L7 in terms of what becomes reference implementation. Snort is something that we're kind of toyed with to say that we might head down that path. But by no means are we saying that in queue we will be able to accomplish that. But at least we want to get that discussion going sooner rather than later. And also it kind of is factors in terms of how many contributors we have. The more we have our feature velocity improves. One other thing is with the V1, the V1 has kind of been in this funny state in that it was deprecated a long time ago. But still there are users that have been using it, so it is still there. But our plan really is to kind of end of life in Rocky. But we are not doing any active development on V1 except for bug fixes that are kind of relevant. We want to make sure that we fix the bugs and we back port it to the stable branches as well. So that's kind of where we are with V1 and our plans for it. Just some logistics, please feel free to reach out. People who want to contribute, we do have a weekly IRC meeting. We meet pretty much every week to run through issues of the week. We have an IRC channel, please ping us. If people want to contribute, we welcome that. I think that's all that we had and would like to, any questions or direction what you guys would like to see or what you don't like, whatever, please. I think they have some mics there. With DVR, what kind of limitations do you have with FVAS? Yeah, good point. Actually, we were going to talk about that. So one of the things with DVR, with V1, a big limitation with DVR was that we could only do north-south. We could not handle east-west traffic on a DVR scenario, again, mainly because of how contract is done and a little bit of asymmetric, I wouldn't say asymmetric routing, but a little bit of asymmetric in terms of how L3 is handled with DVR. The L3 decision, if you're going from compute one to compute two, L3 happens on compute one, and then you land up on compute two. On the response, the L3 happens on compute two. So one namespace router will not see both sides of the traffic. So that breaks contract and that breaks FVAS. So that really was the original issue with DVR not working and we fixed things so that at least it was not completely broken we only handled north-south more as a perimeter of firewalling. But now with the L2 support, you can apply that firewall group on a VM port and now the contract issue no longer exists. So you will be able to get firewalling support on east-west with DVR more as a side effect of having L2 support. Definitely, that's something that we wanted to bring up, but we didn't want to kind of confuse the issue on that. Thanks for bringing it up. Yes. What are some of the implementations for OBS and OVN with firewall as a service V2? And do you see that being an easy to integrate combination of bits going forward? Sorry, I didn't get your question. Open V switch is OVN product, going to SDN with our north-south controller. How does firewall V2 play with that? Currently, we are looking only at the standalone obvious flow programming. We have not looked at the SDN controller like OVN to push firewall rules. Maybe something for us to look at and come back. So at this point, I haven't looked at programming with SDN. Yeah, and the OVN thing did come up two cycles or last cycle or so. There was one contributor who was quite interested in looking at an OVN integration, but we are at this point wherein we said, okay, let's kind of focus on getting that basic implementation done before we open up. But yeah, certainly, I think there's no religion on that at all. I think we're absolutely open to that. So I just saw that a security group, you mentioned about how that will coexist with security groups, and I think the demo also is many redundant features with security groups. So what's the roadmap and how is that going forward for firewall service? With security groups, I think, so one thing to emphasize here is that if you had both security groups and FWAS on L2, you're kind of looking at, it's an and operation in that that you must hit a permit on both for the traffic to get through. So that's something that we probably didn't make that clear enough, but that's one aspect, sort of tangential to your question. But then to answer your question, we are kind of agnostic to that. I mean, we do want, if someone were to enable security groups and firewall V2 on an L2 port, we do want that to work, and that's kind of what Chandan has been debugging through right now, for sure. But I mean, there is possibly a deployment model wherein someone might say, I don't want security groups and I will just use FWAS, and that's fine too. Or someone might say, I might want to use FWAS for L3, but I'm just happy with security groups for L2, and that's fine too. So we are kind of keeping that, we are not enforcing any binding on, this is how it has got to be, so for sure. Did that answer your question? Thanks. So we are done. Yes. Maybe it's fine. Thank you very much. Thank you guys. Thank you very much.