 So, thank you everybody for attending. Good turnout considering that it's Thursday, the last day of the summit, and it's the second to last session. So, I'm glad you all were able to have enough stamina to make it through three, would have been three good days, and attend our session. So I'm Jacob Sundowski from Intel, and I'm Pino de Candia from Mitokura. And we want to talk about some fun and exciting work that we've been doing to bring network security inside private clouds that are orchestrated by OpenStack. So that's what we're here to talk about. Right? So you guys have all been part of what has been this evolution of the Enterprise Data Center from something that was focused on supporting traditional hardware, where the applications were something that was just running on top of them, and the people who are running the infrastructure are thinking about maintaining the infrastructure. And where virtualization has taken that and made it more about utilization of your resources. And now we're in this era, and this is what OpenStack is really driving, is a software defined infrastructure era, where we care about the applications, that's where the business value is derived from. And these things that they use, storage, network compute, and in our opinion security, are key to making those applications available and keeping them up and running and happy and healthy. So one of the things about these new types of environments as you operators and people who are working on the development side know, is that if you look at the structure of such a cloud, typically from a security perspective, you think, okay, we have a perimeter, there's a firewall there, it's inspecting traffic and making decisions on whether to block or allow that traffic through, this is traffic going out to somewhere else in the network, going to somewhere in the data center, it's a gateway. So what happens to the rest of the traffic that never sees this gateway? So this is a visibility issue, and when you're thinking about how do I secure my whole data center, how am I securing my network, you need to think about securing this portion of the traffic that never sees appliances that are designed to inspect the traffic. So we need to get at this 80% or so of the traffic that is swirling around inside the cloud, going from VM to VM, maybe those VMs are on the same hypervisor, maybe they're on adjacent physical hosts, doesn't matter, if they don't see the perimeter firewall you have no visibility into them. And there's other problems that we know about that we have to deal with that are related to the elasticity and the dynamic nature of these software defined infrastructure environments. Workload migration, and like the elasticity point, you might be bursting number of instances that are running your application, and so we have to think about how do we deal with that from a security perspective. And we know, and I wouldn't be here talking to you, if physical hardware appliances that are available for purchase today from vendors like Intel Security and others could solve this problem for you. So when we were thinking about, and this project started as an initiative in Intel Security, but has now moved over into the core of Intel, what are the kinds of problems and the challenges that we're trying to solve when we're thinking about security in these areas? One is this east-west traffic, traffic that's swirling around inside the data center that's not seeing any of your routers or firewalls or other security devices that you might have from the physical world. One of the problems that we need to deal with is this workload migration and protecting new workloads like the elasticity requirement. And of course, acknowledging that not all of the workloads or applications or whatever you want to call them have the same security requirement. So there's a variety of them, and that means that we need to have some way to map policy to security policy to these workloads if we want to protect them, because they need to be protected especially. Like let's say you have workloads that are dealing with PCI compliant data or HIPAA regulated data or things like that. And different regulations I think around the world, but those are the ones from the United States that I'm familiar with. So we have to support multiple security functions, and we need to support multiple security requirements. That's policy mapping. Okay. And the other thing that we need to think about when we start formulating solutions to these problems, which as we get a little further down the path in the presentation we'll talk about how we want to use virtual security appliances, virtual network functions that are security related, like IPS, Next Gen Firewall, things like that, is if we're going to scale out to meet all of the demands of inspecting inside the data center, inspecting in a distributed way, being able to apply these policies, now we run into what I believe is an orchestration problem. So I'm proposing a solution that says, okay, I want to scale out my security workloads. These are security V and Fs you can think of them as. And then I have to manage them. I have to provision them. I have to configure them. I have to hook them up in service function chains. I have to insert the services. That's what Pino is going to talk about, how MetaCur is doing that. But I have to manage the security at scale. And that's an interesting problem, and that's a problem that we felt the solution to over at Intel was this thing that we called the Intel Security Controller. And I guess it's more than a controller now. It's become what we're trying to make it as a platform. And what that is, is an abstraction between the virtual infrastructure management pieces, which are OpenStack and an SDN controller, like MetaCora, like MetaNet, and the security function themselves. That could be something like the McAfee Virtual IPS or McAfee Virtual Next Gen Firewall, or any third-party function that is integrated with the Intel Security Controller platform. We are open to integration with other security VNF vendors, by the way, if you're looking. So one of the things that we want to do is make sure that the security, the virtual security functions, don't have to worry about what type of environment they're plugged into. They need to focus on doing their job and doing it well and not consuming too many resources. So we come from that security background. And so we wanted to make sure that they just receive packets and know how to map policy to those traffic flows and enforce the policy, drop or allow or alert, based on the security needs. And we want to enable them to plug into as many types of OpenStack environments and with SDN controllers as possible. And so you'll see in a few slides how we're planning on attacking that. And of course, since we're Intel, we want it all to run best on Intel. And the appliances that we started with, which are the in-house ones from McAfee, from Intel Security, are optimized to run in x86 computing environments. So run on Intel architecture. They leverage a lot of the built-in goodness that's there, things like DPDK and HyperScan and AES and I, some of the feature sets that you may be familiar with. And the point is that they run x86 native code so that they run best in these environments. And we want to help other third-party virtual security functions and other virtual functions in general to do the same thing. And to make them orchestratable by us, by the Intel Security Controller, so that they can be easily plugged into these types of OpenStack environments and utilized in service chains and made available so that you can make security services available to your workloads as necessary. So like I said, we're building this platform, and this is kind of how we see it playing out, right? We want to support as many hypervisor options, as many SDN controller options as possible. And we've started in the VMware world, so we have a nice integration with some of these McAfee products with VMware in their NSX environment, which is closed, but it works pretty nicely. Cisco, we have an integration with them. We've metacore, obviously. That's why we're here talking. And other SDN controllers. We built a very modular architecture for the security controller piece, for the Security Orchestrator, and that allows us to easily write or work with our partners to easily write plugins to plug into our environment so they can interpret how we want to insert security, the nouns and the verbs that we have internally for making the right API calls to insert security in a service function chain, and for them to go ahead and implement that. So it's very easy, and Pino can talk about how easy it is to do the integration. And then, like I said, on the top side, on the northbound side, we want to, our goal is to bring as many virtual security functions as possible onto this platform and allow them to get access to all of the types of environments that we cover. And all running on Intel architecture, of course. So, one of the other things that I'll talk about before we hand it over to Pino to talk about the nuts and bolts of how all the sausage is made in the background, is the security controller allows you to do this really nice abstraction that I talked about. And one of the key points there is that a lot of people are running, when I talk to customers, they're running multiple stacks. Those stacks have their own keystone, they may have their own Nova and neutron controllers and pieces. And the security that you need in your data center should not be isolated to a single stack where you need to manage the security, the network security there in that individual stack separately. It should be uniformly available to all of these stacks. And that's a layer of abstraction and a feature that the security controller provides. They can connect to multiple open stack stacks and their SDN controllers and make the same security uniformly available to all of them simultaneously with the same step that you can set it up for one, which is the type of automation and leverage that you really are looking for in a cloud environment. Okay. So, the way that we do this is we register what we call a distributed appliance with all of these data centers. And more or less that has an image associated with the appliance with the security function that we hold in a security function catalog. And that image is registered with Glantz and then in each of these stacks and then can be deployed via Nova API calls from the security controller directly when you say I want to deploy this appliance to all of these different stacks, ISC makes the necessary calls. And it also connects to the manager, the service manager, right? So this manager is unique to each function, each security function. If you think about IPS, intrusion prevention system, or IDS, these are systems that generate a lot of alerts. They have sensors, these network sensors that sit in the network and sniff traffic or in line in L2 service insertion type deployment mode. And they're sitting there, they're looking at traffic, they're making decisions about whether to allow or deny traffic to pass through them. And they're also alerting someone in a security operation center saying, hey, this is malicious software that's being emitted from one IP address or VM in this environment to another. This VM is trying to attack this other VM and I want you to know about it. So those types of alerts, that connection between the virtual IPS instances in this particular example that I'm talking about, they need to be authenticated back to their manager, they need to know where to send the alerts. And similarly, the security person, the security administrator, needs to have a place, a central place where he can create policy and then disperse that policy down to the associated instances that are providing the actual security service. And so we're enabling that connection in mass. Think about trying to, if you've ever worked with these physical functions in the real world, you have to authenticate them to the manager one by one. Imagine doing that a thousand times, you'd go crazy. So we can do it, well, what is that? Snap of a finger, click of a button, it's all the same, right? So very, very easily, that's the point. And so we also connect to the manager to enable this communication. And in the particular case of the Intel Security Appliances that we have with our initial integration, it's the same manager that manages the physical appliances. So there really should be no difference between managing physical appliance or managing a federation of virtual instances that we call the distributed virtual appliance, okay? So one of the things that, how this works, we can think about it from a logical perspective, we're drilling down and down and down into this platform and how we're doing things, right? Is that we have a construct for grouping VMs or workloads within the Intel Security Controller appliance. And so they're logical groups. It doesn't matter what network these things are connected to. You can, they can be a dynamic group that's based on a whole tenant, open stack tenant, or whatever, whatever you want to do. A tenant network or just a list of VMs that can be static. And so the security controller, right? Like I said, connects to the Suppliance Manager. And then through OpenStack, deploys virtual instances. Now, if you've ever looked at any of VMware's stuff for NSX, they talk about micro segmentation. So as far as I know, there isn't really an allegory to micro segmentation in a strict sense for service insertion in OpenStack, like there is in the VMware ecosystem. And that's what we've brought here. Is that anywhere that you can draw one of these logical boundaries, create one of these groups here. You can say, I want to put IPS service and I want to have this specific IPS policy inspecting traffic that is transiting that logical edge. And in the background, ISC works with MetaNet to make that happen. So now I'm going to pass it over to Pinot to talk about how that actually works, how the service insertion, the service function chaining works. Thanks, Jacob. All right, so I'm here to tell you about MetaNet's service function chaining capabilities. I want some takeaways for you are that MetaNet is open source. The service function chaining capabilities that I'm going to talk about are already in MetaNet released. And if you want to try them out, you can download MetaNet from metaNet.org. So let's see. So first of all here, let's see, is a pointer working here? Good, so before we describe things, remember this concept of the group. So workload groups are going to be associated with policies. And before you associate groups with policies, you define the policies. So remember those two steps. Define the policies, then associate workload groups with policies. Ah, right, arrow. OK, I understand. There it is. Oh, you went through a few animations there. There you go. Spoiled it. OK, so up here on your right is Intel Security Controller. And what you're seeing here is that it has via the management plane access to the service VM here. And it can configure policies this way. So the very first thing that happens is before any workloads are set up and any policies are bound, the Intel Security Controller will map policies to VLANs. It can do other things, but we work with VLANs in MetaNet at the moment in the first version of the service function chaining API. Now, before we go further, let me point out the service function has two ports in this model. It has a port for managing it and changing the policies or for setting the policies and binding the policies to VLANs, but also for the service VM to talk back via the management network to the security managers that can actually collect the events and do correlations and so on. The next thing that happens is when the policy is bound to a workload group, the effect should be that the virtual machines in that workload group are protected. And how can they be protected? It's by redirecting their traffic through the service VMs, meaning the security functions. In order to do that, Intel Security Controller makes an API call to MetaNet. Now, in the future, it should be the service function chaining API in Neutron, and then MetaNet would just implement that via a Neutron plugin. But that doesn't exist today upstream. We're working on it, and as soon as it exists, then we will be implementing it, and ISC will talk to OpenStack Neutron. Neutron then goes in programs, excuse me. MetaNet goes in programs, this service chaining logic. And what I want to point out here is that we've inserted the service function chaining logic between the VM and the port firewall. And that's true in both cases, in the service VM and the workload port. So if there is a flow that starts, packets are flowing from the VM out. Sorry, wrong button. What happened? So the VM emits a packet, and the service chaining logic will intercept it and tag it. Now, it does two things. It tags it with a VLAN, which it was told to do by the ISC, a VLAN for the policy of the workload group to which this VM belongs. And the PCP field in the VLAN header is used to signal that the packet is going away from the VM, not coming towards the VM. That's important. So VLAN tag signals the policy. And actually, you'll see on the way back that if the service VM allows the packet, so the MAC address of the packet is used to connect back to where the packet was redirected from. In other words, in this model, we're using a layer 2 model. We're using MAC addresses to identify the service chain that is redirecting traffic. There are other models, too, but right now, this is what we're using. So the service chaining logic strips the VLAN and reinserts the packet back where it came from. And again, it's the MAC address that allows us to know that the traffic was coming from this VM, and so we bring it back to this VM. On the return path, the packet comes back. It comes through the port level firewall. It's intercepted by the service chaining logic. It is, again, redirected. This time, so same VLAN tag, because we're talking about the same policy that's protecting this VM and its workload group, and the PCP field this time is set to a different value, which indicates to us this is going towards the VM. And if it's allowed, then the packet on the return path is again intercepted. The VLAN tag is tripped, and it's reinserted at the point where it was redirected away. So it arrives at the VM. At some point later in time, the service VM might decide that this is an attack flow. So for example, someone trying to run a script here on a web server. So the service VM blocks the packet. And now all packets in that direction will be intercepted. And the same is true of all packets in the other direction for that one flow. All right, so then if the service VM fails, there are two modes. There's a mode where the service is down. It's not there to protect the VMs anymore. If you can't guarantee, if you want to be strict about security, and you can't guarantee that the packets are being filtered and that they're safe, then all traffic should stop. So they're all blocked right there. But if you want a higher availability mode and you're willing to sacrifice some safety for high availability, then if the service VM fails, we can redirect the traffic away from the service. And this is kind of cool because this is reactive. It's showing that meat on that is actually able to detect that the VM is down and redirect the traffic. And we can only do this in certain cases. And this is an area that we're exploring to do more and more and better detection of when is the service really available or not. OK. So then we're talking about chaining here, not just insertion. I've showed you one service, but we can do chains of arbitrary length. And we've tested with two and three, chains of length two and three. So if there are, let's say, there are two service functions protecting the port. And this means basically that the workload of the VM, the workload group of the VM, has been bound to two policies that are both, is that correct? Two policies. And therefore, two distributed appliances are protecting the VM. And therefore, the traffic has to go through both appliances. So when the packet is redirected, it's redirected to the first service function with a certain VLAN tag, the PCP field saying that it's coming out of the VLAN. And then when the service VM allows it, the service chaining logic over here, and I'll show you with a pointer here, this service chaining logic is detecting that there is another element in the service chain, and therefore redirecting it again. And finally, the return path strips the VLAN and resumes the packet's path in the logical network. And so then the port level firewall will be evaluated, and then the layer two network, and layer three router, and so on. And here it's the same. So if there's a failure, and the policy has fell open, which means we trade safety for availability, then we dynamically modify the chain for that instance, and the packet, the path, skips the failed service function. How am I doing on time? You're good still. Yeah, OK. So I wanted to show you this very briefly. So this is what the API looks like right now. It's very simple. And we're going to basically scrap this API later and use the full service function chaining API. But this is what we have today, and you can use this. So this layer two insertion object has a protected port. This is the port of the VM where traffic is being redirected from. The service port is the port of the service that's going to receive the data traffic that's different from the management port. We don't need to know about the management port in MitoNet. We learn about it through Neutron, but it's not special to us. The isolation format, so the folks at Intel Security have various ways that they can set up. But we currently only do VLAN for mapping the policy. And then, sorry, that's the isolation tag. The format tells us a little bit about this is where the PCP bit, the PCP bit, is set based on this format. And the failure policy, we talked about fill open, fill close, and the position so you can have many of them. You can see here there's no classifier, so we're working on a classifier. And the L2 service object is to indicate that this service port, before we create these service insertion objects, we create a layer 2 service object to inform MitoNet that this is a special VM, that on this port it should not receive any traffic. It's not redirected traffic. So I think that's it. And I'm going to pass it back to Jacob. All right, thanks, Pino. So what I want to talk about in the remaining time, and then of course give everybody time to ask questions, is if you use cases and then talk a little bit about deployment and how we do this via ISE. So not only can you use Intel Security Controller to create logical groups of workloads, then bind policy into workloads, and then have the service inserted to protect those workloads as you desire. But we also allow you to deploy virtual network security functions like IPS, or next-gen firewall, or WAF, or whatever you want, onto different physical hosts in your environment. So we obtain a list of all the physical hosts, and you can deploy into an availability zone. You can deploy onto a specific host. You can deploy one instance. You can deploy 10 instances. You can, what else can you do? You can do a lot of things. You can share them across tenants. So you can share these security VNFs across tenants if you're a managed service provider. That's huge value to you, because you only have to run one instance that's consuming resources on your host to protect all of your tenants. So all your tenants traffic can be inspected by different tenant policies, all using the same virtual IPS instance, for example, instead of having to boot up and maintain multiple instances and consume all your compute resources for security, which you don't want to do. So the deployment, really big piece there. This is kind of how we see things playing out architecturally with the best practices model of deploying one virtual security instance per host, and then letting MitoNet redirect the traffic locally on the hypervisor using their agent in the way that Pino just described. So Intel Security Controller, it's its own VM that's doing all of this marionetting, I would say, behind the scenes. It has a UI, but it also has a fully open API. So if you want to run your own front end, then go right ahead. And you can set up these security groups to help your tenants provision security for themselves as necessary, which I think is really nice. One of the things that Pino brought up is that MitoNet is open source. So I'm just anticipating a question later, someone asking me, OK, is Intel Security Controller open source? And right now, it's not, but it will be. We know that that's the direction that we want to go in, and we're making the plans and provisions necessary to do that to help enhance adoption and get more people onto the platform. But the platform is open, so we're willing to work with anybody right now who wants to join, and then with the knowledge that it will be open source to the community shortly. I think in the release after our end of November release. So I just wanted to preempt that. But let's talk about multi-tenancy use case. I think that's really relevant to a lot of the people probably in this room, right? You have two tenants. They need to think that they are running in two different clouds that belong to them. You can use the constructs that we have in ISC, what we in Intel Security Controller call security groups, or in the previous slide we're called workload groups, to group an entire tenants domain, let's say, of VMs. And this is a dynamic group, if you want, that will add new workload instances as soon as they get created in a tenant. And at that logical boundary, apply IPS, or next-in-firewall, or whatever type of DPI inspection. And Meadonet in the background is orchestrating all of this. By the way, we also have our own home-brewed method for doing service insertion within Neutron, but it's mostly a reference design, I would say, and can only do service chains of one, which is good for demo purposes, I would say. But we encourage people going with a fully-fledged SDN controller to take care of their networking needs. So you can inspect that this logical boundary, while knowing all the time that in the practical world, you have virtual instances of IPS that are sitting on your compute host, and the workloads are commingled on these hypervisors throughout your data center, throughout your cloud, and that the traffic is being rerouted as necessary to be inspected as necessary anytime that you need that it's a traffic that's designated with a specific policy to be inspected. And the IPSs know how to interpret that traffic and apply the correct policy. So this is a use case that we hear from time and time again as what our customers want to do. And the customers who we're running POCs with right now on this, this is what they want to do. So one of the other interesting use cases that I hear about from customers more in the provider space is, and a lot of people are talking about this, virtual customer premise edge, or VCPE. Everybody loves acronyms. So you have a bunch of branch offices. In each branch office, there's a communications closet. That closet has a bunch of fixed function hardware in it. Every time you want to make a change or make a configuration update or do something, you have to send a guy down to go get on the CLI for this box and configure it. And not only to do that, but install it and you have to buy all these hardware things from different vendors. And so what I hear from my customers when I talk to them in this space is, it would be a lot easier if I could deploy a generic X80 Intel server into this closet or a few of them and manage them remotely and install virtual instances of router, a firewall, an IPS, or some other function, have those managed remotely and be able to do it all from afar. So that's something that brings a lot of business value. Cuts a lot of cost, so helps reduce cost in a lot of cases. And also gives you a lot of flexibility because you're managing remotely and everything software. Like I said, if you need to add another instance of IPS because this office is producing more traffic, there's more throughput, no problem. You don't have to add another physical appliance. All you have to do is boot up another instance. So tell ISC to tell this thing we want another instance over here. So this is another interesting use case. So where do the customers see the benefit? It comes down to business value. So we're making security for attacking this big problem, this visibility hole that people have when they're running their open stack clouds, seeing what's going on inside from a security perspective. We're bringing the automation and the agility that enables you to really do that. We're enabling customers to dynamically scale out their DPI type advanced security appliances. We're enabling them to map policies to workloads intelligently. And then on the personnel side, because none of this happens in a vacuum, we're enabling the people who work on certain areas like the security admin can continue to do her job of creating policies, looking at alerts, figuring out what actions to take if there are breaches that are detected. And the infrastructure administrator can continue to do his job of running the open stack environment, which is a full-time job. So they don't need to learn all of each other's other functions. So it's really about bringing security in an agile way to this agile environment. OK, now this slide, huh? So how much more time do we have? About seven minutes, I think. We're supposed to be done at 5.10? Seven minutes? OK. So Pino already talked about this, so I think I want to skip this slide. But what I do want to talk about is, like I said, one of the take-homes is if you're an operator, you should be thinking about how you can bring security inside your cloud and help manage this east-west vulnerability. If you're a managed services provider, you should be thinking about how can I provide value-added services, like charge my customers more for security? This is how you can do that. If you're a security VNF vendor, you could be thinking, how can I leverage this Intel Security Controller platform to make my virtual function orchestratable in mass in this way and leverage all the work they've already done, cover all these environments that are already supported? So there's value there for those folks. And then if you're in Pino's case, if you're a SDN controller vendor, if you're an infrastructure software piece vendor, I think you should be thinking, OK, well, I want to make sure that people are that I'm useful in running all of these virtual functions that I could do service insertion, and we can help do that. So we can help enable you to deal with NFV, I think, security NFV in an easier and more headache-free way and bring in all of these other security functions to work on top of you, like the Intel ones we've already integrated and the third-party partners that we're in discussions with right now. So that said, from the VNF perspective, there's a few modifications that I think one has to make in order to enable and appliance to be orchestrated by ISC. So it has to have a small agent that's running in it that allows it to communicate back its health and status and things to the controller. And a small agent that allows it to count statistics about what the traffic that's going through it and help in managing those things so it can tell the security controller what's going on. So it's really not a lot. And we have developed, we've already developed these things for our own appliances. We've done a reference implementation with the Snort open-source IPS appliance. And when we open up ISC, we are planning on releasing these SDKs to help enable the VNF vendors to join the platform. So that's pretty much what I had. I think we can open it up for questions in the last four minutes. So if you have one, shoot. For me or Pino? Yeah, you can step to the mic or you can just yell. Since you are in Intel, and Intel has TXT, trusted execution for execution, and the attestation. How does TXT relate into this so that I could have trusted attestation from hardware all the way up? I couldn't have planted a better question because I'm talking with the TXT team about how we're going to integrate those pieces today. And we see that as an important piece to help enable trusted virtual network functions because we're deploying them. And so we should be able to deploy them on trusted compute hosts, and then also attest to the fact that this VNF is the same one that you bought from the store. So this is something that we are working on and that will be included in not in this ISC 2.0 release that's coming out in November, but in the open source version that will be, I think, probably in the community. I can't really give you a time, but let's say next year at some point. Yeah, you're welcome. Yes, sir? Yes. I think this is for you probably, huh? Yeah, yeah, just curious. So service search machine is used to run one of the security lines, for example, like ideas, ideas, or whatever. But what's the point of putting the firewall and splitting this service data network and service VM in different trusted hosts? What's the point? Sure, so actually this is just, so in Neutron, you get a port level firewall by default. And if the APIs allow you to turn off the port level firewall, it's gone. So right now, I believe, the API that we were working with, Kilo, I think you may be right, the port level firewall may not be wrong and my drawings may be wrong. The Intel security controller has Neutron API. So when it launches this service function, it has the ability to control the ports. So it can just turn off port level firewall here. It can use the port security extension to turn off this firewall. And therefore, I'll correct my diagram. Thank you. You're right. There's nothing. And the only reason, so basically, these port level firewalls are here because I was thinking that Neutron would put them there by default, but with the port security extension, we can get rid of them. This one actually would probably be here on the management side. This one would not. And as for this one, there is a point in having that, because that way you have layer for security on your VM, right? Separate from the service VM. Does that answer your question? Yeah? Good catch. It's based on antivirus. No, so this is the McAfee network security platform, right? So it's the service VM, right? So it's own VM. It's not running the antivirus engine. It's running a totally different engine that does full de-packet inspection on all the packets and stuff. It's like the market leading IPS that you can buy. And yeah, so it doesn't have any direct communication with the hypervisor. It just receives packets from the service chaining logic in MetaNet or from OBS or whatever directly. It's not doing introspection into any of the other guest operating systems adjoining it. So that's a separate product that McAfee creates. You could think about this as just a virtual version of a network IPS, like a box, that you would normally plug a bunch of wires into. Only we're doing the wiring all in software and all dynamically through MetaNet. And it runs really well in the virtual environment. Yeah? I think that's it then. Yeah, I guess that's it. So if you have any other questions, feel free to come approach me in the back or up front. We didn't have time to show a demo. But if you want to see a demo of this stuff really working, like it's a real product, you could buy it today. We could show you the demo. So I'd be happy to do that as well. We'll be around. We'll be here all weekend. So just let me know. Thank you, everybody. Thanks, everyone.