Security Week Product Discussion: Magic WAN & Magic Firewall

Hello and welcome to Cloudflare TV. My name is Patrick Donahue. I'm joined here by some of my favorite product managers at Cloudflare and security team members here to take you through security week. So we've been making some cool announcements and each day we're going to be interviewing the product managers who ship them, get a sense of what we built and why, what is available today, what's coming soon. And then we're going to talk to our security team to get a sense of what are the hacks that these products are being used to defend against and how can we leverage those both for Cloudflare's network as well as for our employees. So let's just start off by introducing, Achiel why don't you start and then Annika and then Evan. But can you tell me what you do here, what your role is, what you're focused on? Yeah. Hi, my name is Achiel. I'm a product manager here at Cloudflare. My focus has generally been on like the edge of the edge and the non-HTP protocols, but recently been refocused on Magic Firewall and really excited to chat about that today. I'm Annika. I'm also a product manager. I work on Magic Transit and Magic WAN, which we're going to talk about more today. I'm Evan Johnson. I'm from our product security team. We work with all the product managers and engineering teams to help build great products, but also make sure they're secure and make sure that we're using them as part of our security model. So we have some skin in the game and it's a lot of fun working with all these people. Great. And I definitely want to get into some of that later, Evan, but I want to start out by asking Annika, big announcement this morning, Magic WAN and Magic Firewall. We'll get to that in a second, but what is Magic WAN? Like why do we build this? What problems are we trying to solve with it? Yeah. Magic WAN is a product that allows companies to connect all of the entities on their network that make up their corporate network. So that's offices, data centers, clouds, user devices, connect them all to Cloudflare's network, and then manage connectivity between them and routing between them as a service from our edge. And this solves a lot of problems for organizations that we'll get into in more detail, but traditionally the way that they've done this is by using things like private connectivity and MPLS or SD WAN boxes. And these solutions are traditionally really expensive. They're a pain to manage, they're missing visibility and they have gaps in security. And so Magic WAN with Magic Firewall and other products in the Cloudflare One umbrella is aimed at helping solve this for our customers. Very cool. And so I know we had a product previously known as, or still known as Magic Transit that we announced previously. What is the difference between these products? What is Magic Transit? What is Magic WAN? Yeah. Magic Transit is really about protecting customer networks from bad traffic on the outside, on the external Internet that's trying to get in. So that's things like DDoS attacks, malicious traffic that we can block at the edge with a firewall and making sure that we send only the clean traffic that customers actually want to receive back into their networks to them, to their data centers. Magic WAN is kind of flipping that and thinking about connectivity and security with a customer's internal network. So traffic between their offices and their data centers or their offices in cloud properties or user devices. So things happening internal to the network and making sure that those are performant and secure as opposed to Magic Transit, which is for kind of outside in North -South traffic. Got it. And I'm sure Evan, you would probably tell us that as we think about securing Cloudflare's network, we obviously focus on external threats, but of course, you know, you'd be remiss not to focus on internal as well, right? Yeah, totally. You can have a great perimeter, but the perimeter security model is kind of antiquated. And so having security within your network built in is the way to go. Cool. I actually have a quick question. So Annika, you were talking about North-South traffic, but for like the folks at home that have never heard of this term, what does that mean? Does that mean the data actually goes from like the North data center to the South branch office? That's a good question. So when network engineers talk about North -South and East-West traffic, North-South is really thinking about like external into you. So that's in the case of Magic Transit, we're talking about traffic into and out of the Internet. So out of your network or back in. East-West traffic is traffic within your network. So within a single office from one VLAN to another or between offices, you can kind of think of also as East-West traffic. So it has nothing to do with physical locations, which is kind of strange, but thanks for calling that out. That's a good clarification. Great. Good, good shot, Akiel. Thanks for chiming in there. So Annika, you mentioned something called MPLS. For those that haven't been in networking for decades, what is that and why do businesses deploy it? Like what are they trying to do with it? Yeah. MPLS stands for multi-protocol label switching, and it's a technique that telecom companies can use to get traffic with a short path from location A to location B. So if I'm a company and I have a whole bunch of offices and I want to be able to get, let's say, a voice call from one office to another quickly, I can pay a telecom to have an MPLS link between those two locations and get traffic from point A to point B securely. And in this case, the traffic is going over basically this private link, not the public Internet. And so I can sort of, by default, assume that it's private and secure. But there are lots of challenges with MPLS. The biggest one that we hear from customers all the time is that it's really, really expensive. Customers spend millions of dollars on MPLS every year. Just as one data point, it's kind of a recent analyst report said MPLS connectivity still is in the hundreds of dollars per megabit per second per month, whereas something like broadband Internet is like $1.50, around that range. So much, much cheaper. But companies are really, have been kind of stuck in this model where they're paying for this private connectivity because historically, the Internet was not built for the kind of reliability and security that companies need for this kind of very sensitive traffic that they send between these corporate locations. Yeah, that makes a lot of sense. The way I think about it is, I don't know if you remember, when you want to call somebody, you used to have to pay some long distance rate. And then the Internet came along and you've got things like FaceTime, where you can just route stuff over the Internet and it doesn't cost you anything. You can take advantage of all of these improvements and enhancements in the underlying network and layer intelligent, secure services on top of that and just kind of grow with that and get better connectivity with that. So what about, a lot of our customers have offices all around the world, right? And so they've maybe, I think it's actually just north of 50% of our businesses is international, outside the US. How do you think about connecting those? Can MPLS connect those globally? Are there challenges there? How do we think about connecting our customers' offices around the world? Yeah, this is actually a huge problem for customers that have offices internationally because they often have to figure out how to manage multiple providers in different regions for connectivity. And so they might have provider A in North America, provider B in Europe, provider C in the Asia Pacific region, but they have to figure out how to get all of these offices maybe to talk to each other as well. One common circumstance that we hear from customers is they'll have a head data center or a regional data center that's got a lot of internal applications that their users need to be able to access. And so now they have to figure out how to get traffic from all these locations that are connected with MPLS to that central location, which can incur big latency penalties as well. Cool. And what about, we made some other announcements today, right? We had some partnership announcements with some SD-WAN providers. Can you tell me a little bit about that and kind of how that fits into the story here? Yeah, super excited about those. So we announced today some new network on-ramp partnerships with some partners. And what these are going to allow us to be able to do is work with these partners to get Magic WAN set up very quickly in places where they already have some of these SD-WAN devices. So we've talked to organizations that are kind of in all places in their journey of moving network functions to the cloud. Some are using kind of a hundred percent MPLS and old school WAN technologies. Some are cloud native and thinking about everything from that perspective. A lot are somewhere in the solutions like SD-WAN hardware to help them manage different kinds of connectivity from their locations like MPLS, broadband Internet, maybe LTE at some places. And so what we want to do is partner, what we are doing is partnering with these SD-WAN providers to be able to use their technology as sort of on-ramps to Cloudflare's network. And so it's really easy if you have, for example, an Aruba Silver Peak appliance, they're one of our partners that we announced with to connect to Cloudflare's network, send your traffic to us, and then get it to maybe other places that you also have these devices as well. Yeah, that makes a lot of sense. And I think, you know, one of the things that for those listening at home, and I know when I have conversations with customers, we get asked about a lot is like, how did you actually build this? What is the underlying technology that's behind this? You know, I think people ask us, you know, are we buying, you know, network appliances and using them and deploying them on our network? Are we running software somewhere in the middle? Like, how do you think about that? And how does the engineering team that you work with think about that? Yeah, so MagicWAN, like all of our other products here at Cloudflare is built in software from the ground up and run on commodity hardware at our edge. So all of our products run on every server, which are all basically commodity x86 boxes in every data center all around the world. And we designed them on kind of foundational technologies in the Linux kernel to be able to scale very, very quickly. And so what we do is take these pieces of core technology, these kind of primitives, figure out what can we do with them to be able to create value for our customers and kind of productize them and use these pieces to work together. And then we deploy them not just in one place or a handful of places, but everywhere. And then we enable customers to connect to them using kind of standard tunneling technologies that are compatible with whatever hardware they have. So they don't have to think about installing additional hardware at these locations in order to connect to us. It's just bring whatever you have today, whatever hardware, whatever carrier you have, whatever connectivity options connect to us. And then also as our network continues to scale as well, our customers will also get the benefits of that scalability for every single one of our products. Cool. So you said a number of things there I want to jump into a little bit. So, we're talking about taking advantage of the public Internet and connectivity advancements and reductions in latency and increases in bandwidth. But what about if we're in the same data center as a lot of our customers? I know we have 200 plus cities around the world, over 100 countries and just a massively growing network. And I'd imagine that a lot of our customers are probably in some of these same data centers or nearby. How do we think about bringing them into the fold from that perspective? Yeah, that's a great question. I mentioned the SD-WAN partnerships that we launched today as part of our network on-ramp partners, but there's also another set of partnerships too, which are in the physical connectivity space that I'm also excited about. So, back last year, I guess a few months ago now, we announced Klobler Network Interconnect, which is the ability for our customers to directly plug into Klobler's network and receive traffic that way with a physical or a virtual connection. And this is basically a supported on-ramp of Magic WAN. And so, if you're located with us in one of our data centers, which it's very likely that you are if you have co-locations because we're kind of all over the place, then you can basically just plug directly into Klobler and get traffic delivered to you that way or send us your private traffic that way for us to dispatch it to other places as well. So, it's just another flexible connectivity option that can give you even more security and more reliability because you have really that kind of dedicated link in the place that we're located to get there. And what sort of like networking equipment do you plug into today and like will that change over time? Like how do you take those connections? So, if I'm in the same data center as Klobler, like what is actually on the other side for me, like on my side of it? Can you ask the question again? Sorry, I think I'm missing what you're... Yeah, no problem. So, like what am I plugging into on my side? So, if I've got some cross -connect between my rack and Klobler's physical presence, like am I plugging into a router, firewall, like switch? Like what am I actually am I plugging into on my side? Yeah. So, this can be just like a basic switch if you're talking about the physical connectivity aspect. Also, to make it even easier, we have a variety of virtual partnerships too. So, if you already have connectivity with someone like Megaport or like an Equinix or Packet Fabric, then you can leverage that connectivity that you already have to get to us too. So, you might not even need to run a new cable in order to get onto our network. Cool. And I think one of the things you said earlier about us running on commodity hardware, obviously high performance, networking cards and disks and things like that, but the underlying technology is open source, Linux, kernel, and all the networking advancements. And that I think was a big bet 10 years ago when Klobler embarked on that. And I think people might have said at the time, hey, Linux networking is slow. And obviously, there's been just massive improvements over those 10 years that we've been able to leverage. And every time, similar to how if you think about our workers platform, when the Chrome team or the V8 isolates team ships enhancements to that, we automatically benefit from that. And I think there's an analog there with the Linux kernel and the Linux networking stack. What are some of those underlying building blocks that we're actually using? Can you get even more specific on some of the technologies that are used to actually make this happen, make this actual product? Yeah, sure. So, one of the pieces of technology that has been really fundamental to Magic Transit and that we're also leveraging for Magic WAN is the concept of a network namespace, which basically is like a logical copy of a network stack that can be applied to one specific, basically like a specific smaller entity. So, in this case, a customer. So, every Magic Transit customer or Magic WAN customer has their own network namespace that maintains its own routing table, maintains its own firewall rules. And basically, all of the pieces that are in the sort of bigger picture kernel that's running on a given box, you can kind of look at as like a zoomed in version of that that's dedicated to just a specific customer. And so, when a customer wants to add a firewall rule, for example, at the edge, and Akhil can get more into this in a minute, that can be added to that customer's namespace, not just on that one specific server, not just, you know, kind of globally for the whole box, but everywhere. So, that's one of the pieces of technology. There's some newer ones that we're looking at leveraging in the stack in the future, things like eBPF, which is kind of like a small sort of like network function that you can run in the kernel. It's very flexible and allows you to do a whole bunch of things, foundational pieces of technology that allow us to deploy rules and use them in different ways. So, lots of cool things that we can kind of puzzle piece together to do different stuff, and then also build on top of with kind of our own products and proprietary software. Yeah, eBPF is fascinating. I think I saw a post the other day, like, you know, there's the software is eating the world, but like eBPF is eating like the networking world, right? And we're already using that quite a bit, obviously, on the Magic Transit side and for a lot of our DDoS mitigations, you know, and so really cool to see kind of that network, you know, function virtualization happening for things like, you know, you talked about before the MPLS, like, I've deployed this in the past, you know, super expensive. Fortunately, I wasn't paying the bill for this, but I was administering like all the networking equipment, you know, in between and doing things like quality of service and saying, you know, if there's IP telephony between offices, or there's video conferencing, you know, the only control I really had was at the at the, you know, on premise customer premise equipment to try to tag this stuff and then trust that this MPLS network can do it. But it seems like we're entering a world where you're gonna have much greater control over programming of that network, right? I think that's a pretty cool, for me, as you know, a former network administrator, a pretty cool way to think about it. So yeah, totally. And then, you know, on the open source and the Linux side of it, like I've, I've run in the past, you know, I think, like my the link sys, you know, wrt 54g, or whatever it was that had the first, you know, open source stack that you could run on it for administering your network. And then, you know, most recently, I bought, I got into the ubiquity craze. And I've got, you know, the unified dream machine, and I've got the unified dream machine pro. And, you know, I know, Rustam, who obviously we work closely with has some of that stuff as well. We actually have been spending time and I'm going to get to a kill in a second, because I want to talk about the security side of this, like, we've been spending time connecting our networks together, like our, you know, small little home networks. And, you know, for those that aren't familiar, you typically aren't using on your local network, you know, when your machine boots up, it's getting an IP address that is a private address, right? They often refer to as RFC 1918 address. And so people would think of, you know, 192.168.0.0 slash 24 is kind of the canonical example there. But like, can you tell us like, what is RFC 1918? And how can we use some of the technologies you just described to connect these networks together, right? So presumably, you know, I'm not the only one that has 10.0, you know, slash 24. And Rustam is not the only one that has 192.168.0 slash 24. Like, how can is that that namespace technology you mentioned? And can you just kind of talk to me a little bit about the private addressing versus public addressing? Yeah, sure. So I mentioned before, kind of the distinction between Magic Transit and Magic LAN is you can think of Magic Transit as facing the public Internet. So the way that we attract traffic to our network is we advertise a customer's public IP space out to the Internet with BGP. And we say, hey, all of your traffic from here. And that IP space is unique, basically, right? Like a given, you know, slash 24 that we advertise out to the Internet belongs to a customer with an ASN autonomous number. And then we can we know, like, that's for them, and we can direct traffic back to their network. But like you said, like, you're not the only one in the world that has 192 space. There's also private IP space. There's a couple of reasons for having this distinction. One is just that, like, IP space is limited, right? And if every single person had a unique IP address for their laptop that's running on their home network, we would run out of IPs very quickly. But the other is that you don't really need to have, like, a publicly addressable or publicly routable IP for every single device that's inside an internal network. Instead, you can have devices that sit kind of at the edge, at the perimeter, and not IP space. So, say, okay, traffic coming in for Akil's laptop should go to Akil's laptop, and traffic coming in for Annika should go to Annika. And so, what Magic WAN does in comparison to something like Magic Transit, where we're talking about public IP space and sending packets in and out to the Internet, Magic WAN can allow you to route private IP space. So, in the example that you're just talking about, where you and Rustam are kind of, like, connecting your private networks, we can say, hey, this private IP address that's associated with a device on Rustam's network can be routed basically to Cloudflare in this, like, little mini namespace that's associated with just the test network that we set up for you guys. And then if Pat wants to send traffic to that device, you're able to do that. And really, all of that traffic stays within that small namespace that's dedicated to you once it comes to Cloudflare's network. And so, that's how we know that when you send traffic to, you know, Rustam's light, for example, that's 192.whatever the specific address is, that it goes to him and not somebody else's light that's up in some other customer namespace. Yeah, that's actually a funny story. I think maybe I'll share that for the audience at home. But, you know, I think we love, as product managers, getting our hands on, you know, the really cool stuff that's getting built and being able to test it. And, you know, I think we're the best at probably finding bugs and pointing it out. And so, we do it both on just our private personal setups, as well as Cloudflare, right? Anything we build, we deploy to ourselves first, because we're going to be, and Evan and his team are going to be sort of the most critical people that we can be and improve the product before we put it in the hands of our customers. And so, in this particular case, you know, I set up my Ubiquity router and Rustam set his up. And so, we did GRE tunnels back to the closest Cloudflare data center. And, you know, we can talk about Anycast and how it routes there and finds the optimal location and really simplifies that setup. You know, you're just setting up a single tunnel. But once they were connected, you know, I wanted to have some fun. And so, when my first job at a school, actually, after doing network administration, I was doing penetration testing. And so, you know, trying to, you would get brought in and they would plug you in, you know, inside of a bank's network, and you would try to break into certain stuff. And really fun time. And so, I, you know, dusted off some of those tools from back then and started mapping Rustam's network. And, you know, lo and behold, I found something on, you know, 192.168.0.54 or something. And did some fingerprinting on it and found the ports I was listening on and the web interface response. And I was like, oh, that's interesting. He's got some smart, you know, some Philips Hue smart bulbs running there. And so, you know, did a little digging and said, how can I start turning these lights off and, you know, having some fun? And I want to get to the security. This is my way of getting to the security story here in a second. But, you know, I sent an API command to it. And I think the documentation said, okay, you just need to press this one button on the machine once that request comes in. And so, he pressed it, you know, just playing along as the good, you know, social engineering recipient that he was and hit that button. And then, all of a sudden, I had control, you know, over his lights. And I sent him, sent an API call. And I said, hey, are the lights on? He goes, no, they're off now. And I just kept turning them off and on. And so, obviously, like, you want to connect these networks together, but you want to provide some security between these offices, right, in these locations. And so, Akil, how do you think about, you know, Magic Firewall? What is the role there in terms of, you know, that interconnectedness and the security layer that we're providing to our customers that are using Magic Light? Yeah, I'm happy to get into that. But for starters, sounds like if you ever want to get out of product management, Evan Johnson might be interested in employing your services. We've been trying to hire Pat for forever. Okay. Magic WAN is, like, honestly, it feels like a magical product to me, right? Like, literally operating your network in the cloud and having, like, these things talk to you. Like, literally, Rustam being able to potentially use your printer feels, like, totally bonkers to me. But on that note, yeah, for sure, Rustam might not be interested in you kind of, like, being able to turn on and off the lights. So, that's kind of where Magic Firewall comes in. Traditionally, people employ, like, firewalls all over the place. So, you would have, like, a firewall for every branch office location. You have one in every data center. Your HQ probably has one. You might have one centrally where everyone connects to with their VPN. And they pose, like, a whole bunch of problems. Like, for starters, the maintainability. Like, being able to keep your policies consistent who is and is not allowed to do things and who is and is not allowed to talk to each other. It's, like, every time you want to add another data center or branch office, that's really clunky because you have to buy yet another box for it. I don't even want to know how much money these people spend on these things. And that's expensive from a monetary point of view, but also just really clunky to maintain. Every time you want to make a change, you do it everywhere. There's the challenge of, like, maintaining that hardware. You have to make sure that you buy a box that's, like, large enough. Like, do you even know how much network traffic you're going to be pushing through your boxes? Do you need, like, the 1,000, the 100,000, the $1 million box? Those are really tricky things to kind of plan for. And you have to continually buy new ones because you want new features or security updates, all of that type of stuff. And the compliance is also something you continually keep track of. Like, how do you prove that no one changed your magic or your firewall configuration in this or that box and make sure that everything is secure? So, with Magic Firewall, we try to solve for all of that. Like you said, you're connected to Magic Transit right now with just a basic Ubiquiti router. So, that's a really simple, cheap box, right? This is literally commodity hardware. We want to allow you to just use that to connect to Cloudflare and then Magic your entire network policy there, centrally located. And this is really great because you don't have to worry about how large that box is. You don't have to worry about keeping all of your configuration consistent because there's one central place where you can configure the policy, and it gets automatically, instantly propagated through the entire Cloudflare network. Very cool. Sorry, go ahead. No, I just wanted to say, like Anik mentioned, we're all running on the commodity hardware. Magic Firewall runs on all of the metals inside of all of Cloudflare's data centers. Every time we make improvements, whether it's from open source software or we upgrade our hardware, add data centers, that automatically feeds into making Magic Firewall better. Yeah, I think the thing that, for me, that was kind of a mind shift in terms of how we think about the way we deploy our services is so where we started was very much in the reverse proxy space, where a connection would terminate on a given server in a data center. And so we would use any cast to announce these IP prefixes, draw the traffic close to it, and then there would be some piece of software that would perform a TLS handshake and then run the web application firewall. That's kind of a layer seven of the OSI model, thinking about the application layer. The thing that really I had to wrap my head around was these machines are now acting as routers and firewalls at the network layer. And so I think what's really cool is when we talk to customers, we can say, this particular traffic you want to come in and you want to just route it and do DDoS protection and you don't want us to unwrap the actual contents of the packet for whatever reason. And then this other flow, you want to come in and say, actually, I do want to do some inspection on this. And so for me, trying to think about how these machines are now routers and firewalls and all that in one is a pretty unique offering and shift in terms of how we think about delivering services. Some of the stuff you said about patching firewalls and things like that, as a network administrator, I used to have to be running back in the day Cisco PICS firewalls and then ASAs. And some offices would have PICS OS and other ones would run ASA. And it was like two different syntaxes. And I had to keep both of them in my head. And some had certain amount of RAM and I could do certain things on them, certain feature sets. And then you got into the integrated routers that had some firewall capabilities with it, but they were all very different. And I think the challenge for me was managing both the updates to them, pushing those updates out and keeping everything on the latest. You saw the F5 vulnerability last week or whatever it was, where a packet coming back could totally compromise the device. You'd have to rush those sorts of things out. But then also the configuration change that you mentioned. So I would actually run SSH-ing into these things where possible or SNMP and pulling configs down and using these tools called Rantid and then putting them into Git. And actually probably back then it was like pre-Git or whatever, CVS or SVN or some awful old technology. And then trying to track those changes over time. I think the thing that I'm really excited about if I were going to deploy Magic Firewall is that auditability, that single place where I can go into the Cloudflare dashboard and see here's the policies that are running across the entire network. And so you don't have to think about what's wrong on this device or that device. It's I care about my devices and how they talk to each other. And so that to me would be one of the most interesting things there. So you mentioned physical firewalls and deploying these things. So if you think about a rack today, you've got typically a router, a firewall, a switch, WAN optimization. We've gone through this before. What is the legacy network deployment? Over time, do you need all that stuff? How does Magic Firewall fit into that? So ultimately we're looking to allow you to displace all of your firewalling requirements with a network as a service solution in Magic Firewall. So I think we literally want you to end up with a basic router and either you plug in physically with a Cloudflare network interconnect or you set up a GRE tunnel or any other forms of connecting to Cloudflare. And then you can start off just with a basic DDoS protection. But I think one of the really cool things about Cloudflare versus other vendors is with other vendors, you buy a whole bunch of boxes and they have overlapping features and you're still kind of doubly paying. You have to figure out like, OK, I want to add this feature. I need the whole new box and I need to phone up 100 people to install. With Cloudflare, you can just start really simple and just like add on products as you go. So one of the or a couple of the really exciting things that we're working on right now is like being able to just selectively upgrade your traffic for like full stateful inspection with the gateway. So what that allows you to do is maybe you want to do more than just layer three, layer four filtering and allow listing. You want to actually like inspect like, OK, so Bobby here is in the marketing department. He's in this branch office. He's allowed to post to Facebook, for instance. But all these engineers here, it's fine if they read Facebook, but I don't want them to actually like upload content. And so we're going to allow you to upgrade, selectively upgrade traffic to be able to apply like layer seven outbound policies. I'm really, really excited with what that's going to allow customers to do. Further on, we're very actively looking at intrusion detection, so being able to look at like, hey, so what's what's even going on in your network? And can we proactively give you information about like scary things that are happening? So all that to say is you can like really start off really simple with Cloudflare and we can get as complex as you want. I think you're on mute. Oops, I didn't click hard enough. I think that's one of the things that I love about how we ship product is we're constantly kind of pushed to whenever we have something that's usable and solving a customer's problem and we push it out. And it's a little unnerving at first, right? It's like, OK, it only does this little thing, but that little thing is something that somebody has an acute problem for and they're wrestling with something today. And that's something that's super kludgy and cumbersome to deploy and to manage. And what I love about it is we put that in customers' hands and then we don't stop there. We release early and then we release often. And so we're continuing to push out feature after feature. Anika sends one of my favorite emails. I get the weekly magic, all things magic roundup. And there's just like feature after feature after feature of like, we did this this week and we did this that week. And we ship stuff incrementally and you log in and all of a sudden something will show up. Some tunnel health stuff I know she's been working on and some packet capture and debugging tools and all sorts of stuff like that. Going back to the firewall for a second, like one of the things that I think is really interesting is how we actually built it, right? And so from like a user interface perspective and a rule set perspective, can you speak to some of the prior art, so to speak, there that you're able to leverage to kind of build this quickly? Yeah, for sure. So we definitely love to ship early and ship often. So when Magic Transit kind of launched, was it 18, 20-ish months ago? We knew we needed some form of basic firewalling capabilities and we had like the way for us to configure. So we launched it and then we basically just work with customers like, hey, just tell us what your network configuration looks like, what policy you want to put into play. And then we kind of just art coded them because it was already like super valuable in that form to our customers and our customers loved it from the get-go. Ultimately though, like a lot of these people want to be able to configure it themselves. So over time, we've kind of just like added that in stages. So I think it was like six or seven months ago, we launched Magic Firewall like self-serve, which was just an API version. So there was no UI, nothing. People could just use their API. They grab a token from our dashboard and they can just like create, read, update, delete rules at will. And this was like really, really great because people can just put up these rules and they get propagated globally within seconds, right? And compare this to the traditional thing, I almost can't say this enough, where you have to SSH into 200 different boxes or have some other wonky way of managing that. This is like really, really cool. That works for most of our customers, but ease of use is like a huge thing. And a lot of people just really want a click and point thing. So today with the announcement of general availability of Magic Firewall, we're also launching UI. So please do go to the dashboard and check that out. It allows you to just create, read, update the rules for all your Magic Transit on ramps and manage them centrally. And what about like the syntax and the kind of the rule set capabilities? Like how do we think about that as customers come from layer seven to layer three? Like, is there familiarity with that? And how do you think about that? Yeah, sure. So we've already, we've traditionally used a Wireshark syntax and we're just using the same syntax here. So we have a really nice little whizzy wig. What you see is you get to editor where you can just click like, Hey, IP is that, or it contains in that. If you don't like using that, you can just input the Wireshark syntax directly. You can do that through the UI or if you prefer using our API or Terraform, everything just works. I haven't heard a whizzy wig in a long time. So thanks for the blast from the past. Yeah. I mean, I think that's the way I think about on the application security side, which is where I'm focused. The way I think about like, as we add new capabilities to that syntax language, everything we add to it helps make the existing stuff more powerful. So one of the things that we were able to do on the bot management side, for example, is all the intelligence that the bot team is surfacing, you can use in those firewall rules at layer seven. And so I'm excited to see kind of what comes to be surfaced to be used in these magic firewall rules at the network layer. And so if you want to be able to, one of the things we're doing, for example, is gathering and searching and finding all the open SOX proxies on the Internet, right. And providing that as a managed list that can be interpolated into those rules. And so I'm sure there's a lot of roadmap there for you to think about what is actually coming in and integrated in. And as we work closely with the team side of the Cloudflare business, like a lot of that threat intelligence that they are producing, I have to imagine is going to make its way back into magic firewall, right? Yeah, for sure. I think with Cloudflare one, the kind of the umbrella product suite that we announced last year, that's very much our vision that regardless of how you connect to Cloudflare, whether it's like a Cloudflare network interconnect, which is a physical plugin, or a GRE tunnel, or IPsec in the future, or even like warp clients today, we want you to be able to apply policy to all of that from one central place. So magic firewall is for sure going to add interop for warp clients. So then you're protecting not only like your branch office and your data centers, but you can also protect any remote employee, especially now with a lot of us finding ourselves working remotely. I think that's a key to get that visibility and that style of policy across the board and not just for one or two things. Yeah, absolutely. And I think the thing I love is being a one person network administrator at home is like this self -serve ability of that, right? And so you mentioned that, but being able to make a config change, and I personally like Terraform, it keeps infrastructure as code, it keeps it really neat and clean, and I can keep my config in GitHub, for example. But being able to merge that and push that config out and see it change within seconds is pretty cool as I iterate on my own network. Last thing before we start to jump to Evan to talk about how we're using some of this stuff and how we're planning to, how does magic firewall fit into magic transit, right? We spend most of the time talking about magic when and kind of securing connections between corporate data centers and branch offices, but what about the ingress connectivity from the Internet at large to our customers, IP spaces that we're announcing for them? Yeah, sure. So I think with magic firewall, we just want to allow you to apply policy to any traffic, regardless of how it flows into, outside to, or in between your offices. So we allow you to put up rules that allow you to define exactly like which traffic is allowed to go from the Internet into your data center or branch office. We also allow you to specify exactly what those branch offices and data centers are allowed to egress out to the Internet. But we also, to tie it back to magic one, we also allow you to exactly specify which traffic is allowed to go from one branch office to the other. So for Rustam, who really doesn't want Pat to turn his lights on and off, you can just put in those things. Those are not north-south traffic paths, right? Those are east-west traffic paths between these things. We allow you to exactly segment which traffic is allowed to cross those borders. Probably a smart idea for Rustam to do so. Evan, let's talk about, how do you think, before we get into the specific deployment scenarios here, I'd love for you to share. You've been at Cloudflare for a long time and we've worked really closely together over the years. How do you think about how the security team works with product management? Can you just describe that for those at home? Because I think it's pretty unique to Cloudflare. At least I've never worked anywhere where we've had such a close partnership. Yeah. On the security team here at Cloudflare, we're really fortunate that we're a security company first. So all of our product managers and everybody at the company are working on security. A lot of security teams, you talk to them and they're like, I'm having so much trouble getting buy-in to accomplish my roadmap and do the things that I want to do. And at Cloudflare, that's not the case because everybody is literally working on security every day in the engineering and product orgs. So the way we think about ourselves is we're really just the customer of a lot of our products. And so being just like our customers, we started where Cloudflare started using a lot of the layer seven security features. And now as you all are building out this great product suite in the magic asterisk category, there's so many different great magic products coming out. We're trying to figure out, okay, exactly how do we want to deploy this? And what capabilities does it add to what we have and what does it replace? And yeah, it's a lot of fun working with all the product managers and being kind of the first best customer of where we can be really candid about things that aren't working or things that we really want to see or whatever it is. Yeah. I think that candid is the right word there. I met with Joe Sullivan, our CISO, a couple of weeks back when we were talking about what we're launching for the week. And I went in and had some thoughts and share some stuff. And I left with a huge list of like, hey, this is what I want to see us building as I think about protecting Cloudflare's employees and our network. And so it's kind of fun to have that fast lane, I would imagine, from a requirements perspective to get that. And then when we're working on the blog posts for announcing a lot of this stuff, there's a lot of cool dialogue between John Graham-Cumming, our CTO, and Joe Sullivan talking about how are we using this at Cloudflare. And I think that's one of the things that is super valuable to us on the product management side, where you've got experts that are going to ask the same questions that our customers are going to ask. And so you're able to come in and say, think through these questions and we'll have answers and we'll have work stuff on the product by the time it actually goes to our customers. And a lot of the requirements, some cool stuff I know that you're going to be talking about publicly soon, but some of the stuff around how do we identify, making sure that with our access product, for example, that these resources are only accessed by, we all have these security keys, right? But presumably you could take a key out and put it in another machine. And some of the stuff we're going to announce later this week, but how do we deploy and increasingly protect the network? So I want to talk about just going back to like Magic WAN and Magic Firewall. How are we thinking about using this and how are we using this to protect Cloudflare's network? Yeah, we have it deployed in right now, I think one of our offices that we wrote about publicly and there's that whole story on our blog. And one of the capabilities that we have is we have a box deployed that's like literally a network tap to do intrusion detection and have a great log of all the traffic flowing through our corporate networks. And as we centralize or as we move a lot of our management of this corporate network to the Magic Transit, Magic Firewall products and connect all of our offices to the Magic WAN, we kind of get one central place where we can make the changes and enforce the policies that we want in Terraform. So we have a nice audit log and can show our compliance team and our auditors that we have the configuration that they want to see. And what was another thing in there? Oh, and replace some of these antiquated boxes that every time we get a new office, we've got to ship this IDS to it in order to have visibility into what's happening. It's great that that just comes for free with Magic Transit and being able to get network logs. So there's a lot and the velocity of the product, it's been tough to keep up with because you all are shipping it so fast. But it's one of the things that we want to do. And just last week, I got off the call with one of the folks from our corporate network team who was looking at the syntax of how to actually set it up and going over how Austin is configured. And he was like, oh, yeah, this is so simple. It's just these few lines of code. He was pasting it to me in a chat. It was a simple enough amount of code to get set up with Magic Firewall in just a few lines. So it looked pretty straightforward. I'm excited to do more with it. Well, make sure we carve out a nice fast lane for me, prioritize my traffic. I know Anika's thinking through the quality of service and the performance side of it. I want to just jump to that for a second while we're on it, then I want to come back to you, Evan. So Anika, we talked a lot about security, but tell me about performance with Magic WAN. I know with Magic Transit, for example, when we deployed it for customers, just by sheer nature of the interconnectedness of our network, we were able to help accelerate some of their traffic, right? So they saw congestion go down and latency and packet loss and things like that. But how do you think about this from the Magic WAN perspective? Beyond security, what are some of the performance things you're excited about? Yeah, there's kind of three buckets that we're thinking about this in. The first is just comparing the architecture of legacy WAN networks to Magic WAN. We expect a lot of customers to get a performance upgrade just by using the Magic WAN architecture instead. So Akil talked about how we have Magic Firewall, Magic WAN deployed everywhere. Customers can set up these tunnels to us using any cast, and so their traffic always lands at the location that's closest to them, and then they can enforce these rules at the edge. And so this is a huge performance benefit over something like a hub and spoke model, where customers often have to backhaul traffic to central places that have this stack of security boxes that are running through all those functions before the traffic is allowed to go out to, for example, the Internet. So one benefit or one kind of way to think about performance is it's just literally physically, because of limitations of the speed of light and distance between locations, using Magic WAN is going to get you better performance for your network. Another example, as you mentioned just now for Magic Transit, how customers that are using Magic Transit often see performance improvements even with Cloudflare in the path. And so that sounds counterintuitive, right? Like how does putting someone in the middle make my network actually faster? But it's due to the degree of interconnectivity of our network. Because of our CDN business that we've had for a very long time, it made a lot of sense for us to invest in connectivity to eyeball networks being really as close as we can get to the places where users are. And so these investments are paying off for products like Magic WAN and Magic Transit, because for all of these users that are working from home now and need to access corporate resources, there's a Cloudflare data center very close to them. And then the third bucket is in stuff that we want to do next. So on top of these benefits that we get from just the architecture of the solution versus legacy architectures and the sort of built-in performance benefits that we get from just having our network, we want to do even more with those. And that's things like we have a solution at Layer 7 called Argo Smart Routing, which can deliver on average a 30% performance improvement for Layer 7 traffic. It's kind of like a Waze for the Internet. We can choose ways to direct traffic that are intelligent and route around things like packet loss or connectivity issues on the Internet. And we want to be able to do that at the network layer as well. So just an on switch for Argo for all of your network traffic, it's going to be magical. And then also things like quality of service. So we'll be able to say like, yeah, if Pat's in the office, the Austin office, his traffic is always going to be perfect no matter what anybody else is doing. Or if someone is like streaming YouTube or something, we can deprioritize that traffic and prioritize kind of business critical applications over that. So lots of stuff coming up in that space that I'm super excited about. Well, I remember back when I was in college managing the campus networks, like going and plugging my physical laptop in front of the network. And back then we had these traffic shapers. And so cool that we can do that in software today. And Evan, I'll work with the network team to get myself in the fast lane. I think one of the things that you mentioned, Anika, that I think is inherent to how we build security product is that security versus performance trade-off. And so getting that traffic to the closest data center possible that's single digit milliseconds away, ideally, that avoids some of that tension. Like Evan, you must, in deploying security solutions, you must have to balance that usability or at least historically you probably had to. How do you think about that or how do users think about that? Because I imagine there's some balance between what you want to do and what is kind of practical. You don't want to completely lock stuff down. You want people to be productive. But how do you think about that? Yeah, it's a real challenge trying to maintain usability for everybody working. You want people to be able to do their jobs, but you want to be able to enforce a baseline of policies. So it is always a constant challenge and it's give and take. But one of the things that I've always felt is when you're trying to enforce policies and trying to get a baseline of security, there's usually one or two really, really important things that are non-negotiable. And the rest is usually more gray. And so I usually try to pick the few things that are really important. Like we need to enforce egress rules from our networks. We need to make sure we can block malicious sites that our employees are accessing. And then the rest is usually it's a gradient and a little gray area. So we want strong monitoring. We want strong alerting in those places, but maybe not a strong enforcement of like a strong locking policy or something. So I would say it is always a challenge trying to balance those two things. And so if you're a security person, my best advice is like pick the two things that matter, stick with it, and then monitor the rest. Yeah. I mean, I think the thing that we found too is people have moved out of offices to working from home where we all are today. How can you enforce those same policies where you're not running through that hub and spoke model that Anika mentioned? I remember sitting next to my dad before he retired, firing up his VPN clients and routing it through a different country. And it was so slow and it would have driven me absolutely bonkers. And I think the thing that we think about too is when we're running at home and we've got these things on our laptop that are lightweight and able to connect us to the closest data center and apply that security policy there versus having to go through some hub and spoke model as Anika mentioned. Yeah. We were really well positioned with this transition to working from home because we had invested so much in our Zero Trust model and using Cloudflare access and our own Cloudflare for Teams products before all of that happened. And so we were really in a fortunate place to keep that productivity going and still not have to be sacrificing security of saying, okay, we're out of VPN licenses and we're not going to buy any more boxes. So people just have to work without the VPN. We thankfully were not in a position like that. Yeah. I remember early days, we were always hitting the VPN license counts and we'd have to wait to talk to Cisco and get an updated license. And then actually at one point they stopped supporting the version we were running on the particular Mac OS version I was running. And it was just- Yeah. I remember that. You'd get in the office early in the morning and you'd get onto the VPN. And then around 10, when we ran out of licenses, the first people in the office would get kicked off of the VPN back in the day when that was our status quo. But the biggest thing here about, you've mentioned the Zero Trust Cloudflare access products that we've relied on heavily. And then these magic products that were more deeply integrating into our security model. The biggest thing is having a centralized policy enforcement mechanism and then a distributed processing mechanism so that all of the traffic is fast, it's secure, but we have one place to enforce the security policies we need and show that we're compliant with the things we need to be compliant with. So we kind of get the best of both worlds. Yeah. That compliance angle, I hadn't really thought of as much until I spoke to you, but if I were on the receiving end of demonstrate that this product is doing this and you have this policy, it would be a nightmare trying to pull that from all these devices. And so I think that's pretty cool that we're able to provide that. And maybe that's something kind of roadmap that we can make easier for customers where there's a one click, dump all the rules and security posture, and maybe we can turn it into a nice diagram or something. But I can imagine that that would help save a lot of time for teams under a CISO organization. For sure. Any security compliance person would love to be able to click a button and download a JPEG of all of their offices fitting together and where the policies are being enforced, egress policies and all of that. So a feature request, I'll file this in JIRA and I'm sure based on the pace y'all are shipping, it'll probably be finished next week or something. I didn't want to say this, but all the blogs for Magic Firewall are available today. Just saying. All right. All right. No, I think I love the feature request, Evan. I can see Anika like scribbling away there. I know you'll be diligent and file it in our ticketing system, but it's really cool to see the partnership and you pushing us on the product side. Speaking of a feature request, we've got about five minutes left. What are some cool things that are coming that we can maybe talk a little bit about roadmap? Obviously, anything we talk about is forward looking, not necessarily going to happen, but how do we think about what's some fun stuff on the horizon? I'll start with you, Anika. Sure, sure. So I already spoiled some of the performance stuff, but our goal for networks is in progress on some of the quality of service stuff that we're thinking about. And then also deeper integration with Cloudflare for Teams too. So we spent some time talking about the security aspect of Magic Firewall at the network layer. Akil mentioned we're also going to be able to upgrade for more policy enforcement, but really thinking about how we fit these pieces together and present a unified solution for devices and offices and data centers and clouds, because companies have really thought about these traditionally as kind of like separate entities. You have a stack of boxes that manages the traffic from your physical locations, and then you have other boxes that manage traffic from your employees that are working remote. And that's just a gigantic pain to manage, and we want to make that easy from one single pane of glass. And so we have some of that integration in place today. We're looking at adding more of it and basically just tying these pieces that we already have in place together more tightly so that it's very, very easy for administrators to log in and see all of their stuff in one place, put in one rule, and then whether I'm working from home in my apartment or from a Starbucks or from a Cloudflare office, I can have the same policies enforced on the traffic that I'm trying to send out or the applications that I'm trying to access. Very cool. If I could add one to your list, when I set up the ubiquity stuff, it was just a few lines, but I think it'd be even cooler if I could just simply click a button and have that automatically provisioned to Cloudflare's network. I submitted a pull request and clicked merge, and it was a lab, so I kept my fingers crossed, and it all worked out. But I think it'd be even cooler to be able to just have a one-click deployment for some of the more kind of prosumer, if you will, devices at home, because I could see a lot of interest there. And I think after I tweeted out earlier what we announced, I've got people sliding into my DMs looking for access to some of this stuff. And maybe at some point, we can open it up to a broader audience. That might be fun. Yeah, absolutely. Cool. Akil, what are you excited about? What is coming down the pipe? And what are some of the requests you're getting from customers that you're thinking about? Yeah, sure. So I talked about this a little bit earlier, but we talked about adding boxes and managing them and installing them, all that being really, really clunky. I think the number one thing that a lot of our customers and the prospects that we talk to chat about is I would really love to do intrusion detection. And we often ask them, so why aren't you doing this already? It's like, well, it's really important, but it's not urgent, if you will. So either they're like, OK, we're definitely doing that next quarter. And then you talk to them a quarter after, and it's like, yeah, no, next quarter, we're really going to do it. Or they have a box, and they just don't have the time to put it in the corner. They don't have the time to install it. So we're really looking to make that easy and good. We just want you to be able to hit a box on Cloudflare, and voila, you get full view into the scary things that are happening in your network. And we believe we can do it in a way that's not going to be clunky to maintain. It's not going to cause you a lot of headaches. You can literally just add it, get that visibility, and more importantly, get that compliance. So I think we have a minute or two. I actually have a question for you, Pat. Honestly, I was reviewing the list of stuff that we're launching this week, and today alone, Magic WAN, Magic Firewall, and a bunch of other things. What's the most exciting thing, or a couple of the exciting things that we're going to announce later this week that you personally are psyched about? Good question. And we've got just under a minute here, so I can, I think, maybe 30 seconds. I think the thing that I'm most excited about is the API security stuff that's coming out. And so the close partnership with the bot management team, they've been doing some amazing stuff, like building these. I saw a demo the other day of these Markov chains that they're building to look at the probability between moving through states of API calls, and I sat through a customer demo of that. And I'm stoked for that, because I think we've long had great API protection, but making it super easy to use is going to be awesome. So I think we're running out of time, but thank you so much for everyone's contributions here. I really enjoyed chatting with you. Thank you, everyone.