🔒 Security Week Product Discussion: Protect All Network Traffic with Cloudflare

Hi everyone. Thanks for joining today's segment on Protecting All Network Traffic on Cloudflare.

My name is Ameet Naik. I'm responsible for Product Marketing for Magic Transit.

And joining me today is Annika Garbers.

- Annika, why don't you go ahead and introduce yourself?

- Sure! I'm Annika.

Super excited to be here, excited for Security Week. I'm on the product team at Cloudflare, responsible for product management for Magic Transit, so Ameet's counterpart.

Thanks, Annika.

So we're talking about a very important topic here today, and that's really about DDoS threats.

Distributed denial-of-service attacks are as old as the Internet.

And it's kind of this insidious problem that every network engineer, every network security engineer has to deal with at some point that rears its ugly head from time to time.

And when it does, it causes a lot of disruption, not just for your customer- facing applications, but just affects your entire team's ability to work and the ability to collaborate and use the Internet.

We saw a lot of this last year during the wave of ransomware attacks.

A lot of the targets were also hit with DDoS attacks so that it could slow down their ability to get back online.

So it's this insidious problem that organizations have been dealing with, and we've tried different approaches to mitigation over time.

DDoS mitigation really way back when it started off as a feature on a firewall.

That was good enough for a little while until attackers figured out how to evade that.

Then we moved to these purpose-built appliances that just got better and better at detecting and stopping DDoS attacks.

But those would run out of steam as well.

And now we're seeing a shift to cloud-native solutions, network-centric solutions that offer DDoS protection, such as Cloudflare's Magic Transit.

So before we dive into today's announcement, can you tell us, our viewers a little bit more about Magic Transit, what it does, and what problems does it solve for our customers?

Yeah, absolutely.

So Magic Transit helps protect customer networks from those exact types of distributed denial-of-service attacks you were talking about.

And it's a cloud-native service, so it runs on Cloudflare's global network and absorbs traffic as close as possible to its source in order to block those attacks really close to wherever they originate.

I'll show a diagram here that explains a little bit about how this works.

In the center here, we have the Cloudflare Global Anycast Network, and in this picture it's represented as kind of one big globe.

But in reality, what we're talking about here is a global network of 300 plus locations across the entire world that are all able to absorb traffic and block attacks.

And so good traffic from legitimate users and bad traffic comes in.

It's destined to customer networks.

And the way that we do that, the way that we steer the traffic to our network is by advertising customers' IP address ranges on their behalf.

So we say, hey, customer network is over here, traffic comes to us.

And then right there at the Cloudflare Edge, we block those attacks and then add on additional types of security functions as well, things like network firewall.

From there, we accelerate the traffic.

So we use things like our smart routing capabilities to send the traffic from where it comes in to the customer destination across the fastest path possible.

And we get the traffic back to that customer network with a variety of options.

The most popular is this Anycast Tunnel over the Internet.

And this is a really great option for network engineers because they can interact with the Cloudflare network, sort of as one large entity, one sort of point of contact that they need to set up a tunnel with.

But from our perspective, they have the full redundancy of every single Cloudflare location.

We can send them traffic from anywhere where we receive it across the whole world.

This is a really great approach in comparison to some of those more legacy solutions you were talking about Ameet, where you would have a box that was sitting right here on the customer premise that was defending against those DDoS attacks.

In that case, the attacks can get all the way to your network and potentially create problems for your upstream capacity.

Or maybe they're not able to fully block the size of attack that we're seeing as attacks continue to grow in size and volume.

But then also, this is a better alternative to that sort of middle stage that you talked about of the scrubbing center option where some providers will offer a DDoS protection service in maybe a box or maybe some software that they develop, but only at specific locations in the world and that means that traffic has to kind of backhaul from its source to these really specific geographic locations in order to get that protection, which can cause latency problems for customers.

So this solution overall is Cloudflare Magic Transit.

We launched this a few years ago.

It's been really successful in helping customers with all kinds of networks stay protected from DDoS attacks and make sure that their traffic is faster and more reliable than it would be over just the public internet alone.

So I want to talk a little bit about, as you mentioned, the Cloudflare Global Anycast Network and how that's beneficial to network engineers and ingesting traffic wherever we are.

And we'll get into a little bit of that side of the equation, but tell us a bit more about how do we connect between the customer's network and the Cloudflare network?

What are the options customers have? Yeah, sure.

So in this picture here, we have one example. This is an Anycast Tunnel.

And I talked a little bit about how this works.

But if you are watching and you're familiar with something like GRE, generic routing encapsulation or IPsec, which is another traditional sort of point-to-point tunnel mechanism, the way that these typically work is you pick an IP address at your end.

So here, the customer network, that will be something, an IP address that lives sort of at the edge of your network, on your router firewall where you're landing this tunnel and then there's an IP address at the other end.

So that would be something, in this case, that's supplied by Cloudflare.

The difference in our case or the kind of Anycast twist on this is that the IP address on our end lives at every single Cloudflare location.

And so when you connect to us, it's one tunnel from your perspective, but hundreds of tunnels or thousands of tunnels because every server can actually send traffic to your locations from our perspective.

And that allows you a lot of redundancy, a lot of resiliency for problems that could happen with the Cloudflare network, with your own network, and with anywhere in between.

Since we know that the Internet was not built to be entirely reliable and 100% up all the time, kind of have to add this additional layer of redundancy on top of it.

So that's the first option.

So that's really powerful, right?

By using one config element, you're able to get over hundreds of these logical tunnels set up that connect you to the entire Cloudflare network wherever you are, right?

So depending, wherever your users might be, trying to connect to your services on your network, there's a Cloudflare location close to them and then you get this logical tunnel back into your network.

Yeah, exactly.

So that's the first option, these Anycast Tunnels.

We've also had some customers come to us and say, "Hey, could I actually get a direct connection to the Cloudflare network?" I mentioned we're in all of these places in the world.

A lot of times customers are actually located in the exact same data centers as us and they're saying, "Hey, if my server rack is right next door to your server rack, can we just drag a cable between those?

Or can I go through a provider or someone like Megaport or PacketFabric who provide these kind of direct connectivity solutions and get direct, directly connected to Cloudflare's network that way?" And so we offer that as an option too for customers.

You can direct connect to Cloudflare's network physically or through a partner.

This is called Cloudflare Network Interconnect and lots of customers have gone with this option for even more secure and more reliable traffic delivery.

In that case, the attack traffic is still getting all the benefits of this kind of Anycast architecture.

We still absorb it wherever is closest, but then we just backhaul the traffic from that location to your destination to the place where we have that physical connection set up over an optimized middle mile path to make that traffic even faster and more secure.

And that's just the clean, good traffic, right?

So you're making sure that that clean traffic is always on the best path is on a path, network path that you can control, that you can optimize.

And so it doesn't have to go through more Internet hops.

Right?

Exactly.

Customers that onboard to Magic Transit say they just don't have to think about the bad traffic anymore.

It's just the clean pipe to them.

And that's from both a sort of network administration and security standpoint, and also from a billing standpoint.

Cloudflare only charges you for the clean traffic that we hand over to your network.

We're never going to charge you for attacks that we mitigate on your behalf because we think that's the point of the service is that you never have to think about attacks again.

Yeah, I mean, yeah, I mean, the simplicity of this and the benefits are very clear.

And that explains why a lot of customers have found a lot of value out of Magic Transit.

So changing gears a little bit, let's talk about the left side of the diagram that you had shown earlier, which is the Internet routing side.

So you mentioned that we advertise customer prefixes to the Internet and attract all that traffic.

Tell us a little bit more about how that works.

Sure.

So if you think of what the Internet is at, kind of a high level, some people will tell you it's like a series of tubes, which I think is a fun analogy.

But there's stuff at either end of all of those tubes, right?

There's routing devices that are making smart decisions about where to send traffic.

And those routing devices use this protocol called BGP in order to talk to each other and tell traffic where to go.

They'll say, "Hey, I have a route to be able to get this packet that you're trying to send to its destination.

I have a route for that over here so you can send me that packet and then I'll pass it on to the next place that it needs to go." And so BGP on the Internet has this kind of convention that the minimum size of prefixes that can be advertised to each other, so to devices between networks, is what's called a slash 24.

This is also called like a C block of IP addresses. It's 256 IPs.

And the reason for that, the reason for having this minimum enforced is because those devices that are sitting on the Internet and all talking to each other, those are pieces of hardware that have limitations in how big their routing table can be.

They can only manage so big of a list.

And so if you said any router can advertise any individual IP address, well there's millions and millions of IP addresses out there and the routing table could get really big, really fast.

And so a long time ago when all of this, like these sort of primitives of Internet communication were getting figured out, network engineers decided, hey, this is going to be the minimum that we're going to allow here so that we make sure that we don't run out of space in our global routing tables and we're able to get traffic from wherever it needs to go to wherever it needs to land on the Internet.

And so that's what we do when we onboard customer traffic to Magic Transit.

We accept a slash 24 or larger, so as a customer, you need to have at least that many IP addresses and an ASN, an autonomous system number that's associated with your network.

And we basically advertise that to the Internet on your behalf.

We say, hey, we're going to tell the world that they can send traffic that's destined to your slash 24, to your network, to Cloudflare instead.

And then usually customers will withdraw that advertisement from their infrastructure so that all of the incoming traffic to their network comes through Cloudflare.

So that's called "Bring your own IP address", and that's how Magic Transit attracts traffic today.

Yeah, that makes a lot of sense.

I remember a long time ago when the Internet routing table, the global routing table, was approaching 200,000 routes, and right when it reached that limit, routers would start keeling over and rebooting because it just couldn't handle it.

And of course, routers have gotten a lot bigger and more powerful since then.

But as a community, I think we're still trying to keep the global routing table manageable, right?

So I think it's expected to cross about a million routes in the next, sometime in the next couple of years.

Who knows how fast?

So it makes complete sense that we want to put sort of some limits on how many things the Internet wants to know about.

Right?

And the slash 24 granularity makes complete sense, but that's sort of also the minimum that we can advertise on behalf of our customers.

So I know that's been a bit of an issue for some of our customers in the past where they may not have a whole slash 24.

Right?

Or they may have lots of addresses, but that would be fine for a certain geo, but for certain remote locations, they may not be able to allocate a whole slash 24.

So talk to us a little bit about this announcement today, which is really exciting and it's going to help a lot of our customers and how that changes things and how more people will be able to use Magic Transit.

Yeah, absolutely.

I'm so excited about this.

So, as you mentioned, we have lots of customers that come to us.

They Google DDoS protection or awesome DDoS protection and they find Magic Transit and they reach out to us and they say, "Hey, can I have this?" And the first question that we ask them is, "Well, do you have at least a slash 24?

Because that's what we need in order to get your traffic to our network." And they say, "Oh, bummer, I don't.

Like I have an office or a data center or a cloud property or maybe a home network – we'll talk more about that example in a second – that I want to protect, but I only have one IP address or a couple, maybe something like a slash 27 or a slash 29.

Just a few IP addresses that were allocated to me by my ISP." And so we say, "Ah, unfortunately, Magic Transit's not going to be a good fit for you, maybe consider these other solutions." And so we're really excited today as part of Cloudflare Security Week, which again Innovation Week, focus on helping customers keep all of their traffic more secure, to extend the power of Magic Transit to customers by offering Magic Transit-protected Cloudflare-leased IP space.

So the way that this is going to work is we're advertising a really big chunk of IP addresses out of our network that's dedicated to this service specifically.

So basically carved out for this use case.

And then if you are a customer of this new service, you're going to come to us and we're going to carve out a chunk of that space that's as big as you need for your network.

So maybe that's just a single IP, maybe that's a couple of slash 29s.

But we're going to say, "These are reserved for you specifically." And then you can use them however you want.

Just like you would get an IP allocated by one of your ISPs today.

And so from there, the process works pretty much exactly the same as it does for the existing Magic Transit.

All of the other, rest of the fundamental tech is the same.

We attract that traffic to our network on those IP addresses that we're advertising.

We clean the...

we clean it. So we scrub the DDoS attacks out, block traffic that you have firewall rules in place for, record things for analytics and logs and reporting.

You get all of those juicy good visibility features that you want with Magic Transit, and then we send the clean traffic back to your network in the exact same way.

The only difference is just that you're using Cloudflare IP space instead of IP space that you own or have leased at least a slash 24 of from your ISP.

So we think this is going to unlock a lot of new use cases for our customers.

We're really excited about it.

That's really exciting.

So just if I'm a sort of network engineer, a network security engineer and...

Who should care about this?

Does this apply to mainly smaller organizations? Does this apply to global companies, large enterprises?

Who should care about this?

Yeah, this could be a huge range of potential users all the way from global enterprises down to single users at home that have a use case where they want to protect their home network from DDoS attacks.

And the reason for this is even really big enterprises that we talk to that might own a lot of their own IP space, they don't necessarily advertise it from everywhere.

This is actually the case for Cloudflare ourselves.

We have a couple of our office locations protected with Magic Transit because we're advertising slash 24s there, and so we're able to onboard them that way.

But we also have a lot of offices around the world that are much smaller where we just have a really small chunk of IP space carved out by our local ISP there.

And so our own company would be a good candidate for this.

But we've also talked to large retail organizations, for example, that are really excited about this, that have hundreds or more storefronts that need some amount of protected IP space, but don't advertise an entire slash 24 out of those locations.

So that's one example on kind of the high end.

And then on the low end, we also hear from customers that say, "Hey, I just have a single IP, maybe it's associated with my home network or an event space that I'm running or something like that.

And I want to make sure that if that IP somehow gets leaked, if attackers on the Internet get access to it, they can't bring my home network down by DDoSing me directly.

And so if you are a giant multinational corporation or an individual who needs this type of protection, you could have a great fit for this new use case.

So the home network use case is really interesting, right?

And you mentioned gaming earlier. Now, gaming has always been a huge target for denial of service, right?

One of the favorite things to do for gamers to do to take out the competition is to use some premium public domain tools out there, which are readily available to learn their opponents IP addresses and start DDoSing them, right?

This is kind of what they did before they started swatting competitors. So talk to us a little bit more about that use case, how that would work and how more people can take advantage of Magic Transit.

Yeah, totally.

When we started specking out the work for this, I had a bunch of people that were kind of watching the space around it send me YouTube videos of examples of times that streamers have been like killing it, having a great time, playing a game or like doing whatever funny thing they were doing and then they accidentally, in a lot of cases, navigated to some website or some application of theirs that they were using that surfaced their IP address.

And it was, you know, kind of funny but really tragic actually to these people in the experience that they're trying to deliver.

They have a moment where they're like, "Oh shoot, you guys can see my IP." and they navigate away from the screen, but it wasn't fast enough and somebody was able to screencap it, grab it, and then launch a DDoS attack on their home network, often within seconds or minutes.

That's how fast these attackers can move.

And so what we've heard from these gamers is that the way that they kind of navigate this after that happens is they just really need to get a new IP address for their home network from their ISP, like they just get another one and hope that the same thing doesn't happen again, hope their IP doesn't get re-leaked, which sucks.

And we've heard a request from these type of users.

"Oh, could you just actually protect that IP or protect an IP that you give me so that I don't have to go through this process again so that I can not worry about leaking my IP out to the Internet.

And so that's kind of what this use case would look like. In this case, you'll see we don't have that ingress user that we were looking at back here with this initial use case, because usually, in most cases, people aren't hosting applications out of their home network that other folks need to access.

There's obviously some sort of home network user enthusiast that would be the difference here.

But in many cases, it's just outbound traffic from your house. You're just sending traffic out to the Internet.

And so what we're doing here is giving you, the user that would be sitting at your home, access to just a slash 32.

So a single IP address or maybe a couple if you have a use case for a couple and we're going to protect those with Magic Transit.

And so in the same way as the use case that we talked about before, where the incoming traffic is routed through Cloudflare, scrubbed at the location closest to the attack and then the clean traffic is sent back to you, in here, it's going to be the same exact thing.

We're advertising that IP out to the Internet so attackers are going to hit Cloudflare, their attacks are going to get blocked and then there's going to be no disruption to your game, even in the case where someone gets access to that Cloudflare IP.

So this is one use case that we're really, really excited about and hope to be able to see our solution and hopefully other ones like it make DDoS attacks on streamers and the effect that those have had on their experience really a thing of the past.

And this is really exciting.

I know we've been protecting a lot of gaming organizations and gaming servers through Magic Transit for a long time, but this actually opens it up to smaller community organizations and smaller gaming workgroups, and folks who are hosting servers in their basements.

Everybody can start to use Magic Transit, really.

And like you mentioned, I'd love to see the day where it just it's pointless to do launch DDoS attacks against streamers because everybody's behind Cloudflare and we see that a lot for some enterprise customers as well When attackers see that they're behind Cloudflare, they give up.

They know they can't breach through to the Cloudflare network and that stops being an attractive target for them, they go on and focus on something else, right?

So that's another interesting thing to keep in mind. So once you're behind some solid DDoS protection, attackers are going to move on because they realize...

For them, it's also like a lot of economic...This is an economic argument behind a lot of that, right?

You have finite resources and you want to go after the meatiest targets that most likely to get breached.

- And if they see Cloudflare in the network path, then they give up on it.

- Totally. It's like the Internet equivalent of putting a sign outside your house that says you have a home security system or something like that.

People aren't going to mess with you because they see that you have a giant global network all protecting you, so they'll move on to somewhere else that is an easier target for sure.

That's actually a great segue to my next question, which is going to be about on-demand versus always-on DDoS mitigation.

So, a lot of folks have been used to on-demand DDoS mitigation because historically the scrubbing center model or the appliance model where you're just shunting traffic through a dedicated purpose-built DDoS-fighting hardware, it had an impact.

It introduced additional network latency and then you saw it as poor application performance for users, so they didn't want to incur that tax all the time.

So there's a lot of on-demand DDoS mitigation and use.

But talk to us about kind of some of the pros and cons of always-on versus on-demand and with this new capability, how does that fit into the picture?

Sure, sure.

So, yeah, so like you mentioned, traditionally, a lot of folks have gone toward the on-demand option because they haven't wanted to deal with that latency impact.

But we've seen that path become less and less interesting and less and less effective for network organizations as the volume and frequency of DDoS attacks have continued to rise.

Cloudflare publishes this fantastic DDoS trends report on our blog every quarter, and the attacks have just kept going up with new types of vectors, attacks are getting more sophisticated, attacks are more frequent, they're higher volume, they're more distributed.

And it's just getting easier, honestly, too to launch them, like you can, unfortunately, just like do a quick Google on the Internet and find services where you're able to pay a couple of bucks to launch an attack against anyone's network you want.

And so the number of attacks that customer networks are getting targeted with continues to go up and the frequency, and what that means is that having on-demand protection while you're able to kind of push that button, a lot of organizations are pushing the button a lot more frequently.

And some of the customers that we talked to that initially onboarded with Magic Transit in an on-demand mode have decided, actually it makes a lot more sense for us to just transition to having this always on so that we don't need to think about the button at all.

Like we don't want to think about DDoS attacks. That's the big theme we keep hearing from customers.

I just want Cloudflare to handle this and for me to just be able to go to sleep at night and know that I'm not going to get paged because my network is down because of an attack.

And on the latency side on that, the idea of sort of like a performance tax that people have had to pay before, Cloudflare really removes that problem.

We don't have you have to sacrifice performance for the security that you're getting for your network with Magic Transit.

And that's because, again, of the geographic distribution of our network.

We're really close to all the places that users are, so we're not back hauling your traffic around.

It's because of the degree of interconnectivity of our network, so we're connected with more than 10,000 other networks worldwide, which gives us lots of different paths to route traffic and avoid things like congestion.

And it's also because of the intelligence of our network.

We integrate all of the information that we have with the 20 million plus Internet properties that are on Cloudflare to make smarter decisions about how to route your traffic from its source to its destination.

And so what customers that onboard with Magic Transit find is that when they use this always-on, they often see better performance for their traffic, even though it's taking that extra hop through Cloudflare's network, than they did when it was just routed through the public internet on its own, which is really amazing to see and super critical to some of these use cases that we've been talking about, like gaming, which is an obviously extremely latency-sensitive type of application.

So always-on, on-demand, majority of our customers tend to go with always-on because of kind of the new architecture paradigm and the advances that we've made in technology that have made that possible.

And with this new service, we're always advertising those prefixes that you lease from us, essentially.

Right?

So, with Magic Transit, if you're bringing your own IPs, you can press a button at any time, whether you're technically always-on or on-demand.

You always have control over the advertisement status of those IPs from your network.

With this solution, if you want to turn it off, if you essentially want to stop using Cloudflare's IPs, that means basically undoing your onboarding process.

So re-IPing your network or changing your DNS records to point traffic to a different IP for your home network.

So that's possible.

But we expect that most customers that adopt the service will go with always-on and see all of the extra benefits that they get with that, like the improved performance, improved security, improved reliability for all of that traffic all the time.

It means better security, better reliability, better availability, better performance.

Sounds like a win-win to me, right? One more thing I want to add in there is also with always-on, one of the trends we're seeing in DDoS attacks is many of them are very, very short-lived these days.

Right?

So the time to mitigation is also very, very important with on-demand. Some organizations have an automatic workflow to activate DDoS protection and then you can have it sort of effective in a matter of minutes.

But with always-on, it can kick in as quick as under 3 seconds.

Right?

And that's immensely valuable for some of these short-lived DDoS attacks that just pop up and go away.

And we're seeing a lot more of those given all these toolkits out there that are just sort of, attackers are playing with or testing out.

They're also sort of probing a lot of networks to see how much damage they can do.

- Yeah.

- What kind of reaction they can get out of the targets. So always-on has a lot of benefits overall.

That's a great point.

And that example that I gave earlier, all those YouTube videos, right?

Like it literally is like not even enough time to react to the fact that you leaked your IP before your network goes down, the video's off.

And so an on-demand system, you're going to have to think about like, okay, I need to go push a button for this or maybe there's an integrated system, but that you have to get all the way from the detection pipeline to the triggering to the advertisement propagation before you can even turn it on.

So again, it's just like not having to think about it, right?

Peace of mind and knowing that we've got you covered.

Cloudflare blocks attacks at our edge within less than 3 seconds on average.

And so you're going to be really well covered for those types of attacks.

Absolutely.

And for folks who are looking for sort of more automation in their workflows, what do we offer in terms of how can we integrate with their existing systems and processes?

Yeah.

Cloudflare is really API first in everything that we offer. So that's all the way from, pretty much that whole pipeline that we talked about in the architecture diagram that we showed.

There's APIs that power the dashboards that you have available that make it easier for you as a user to change any of that configuration and also full Terra performance support for everything as well.

So as a user, if you want to integrate things like GRE or IPsec tunnel configuration, static route configuration, your firewall rules, your actual DDoS mitigation settings because we let you go in and see all of those and tune kind of like all the nerd knobs that we expose to you to adjust the sensitivity of any of those things.

That's all available.

And then from an observability perspective, so the data that we have about the traffic running through our network that's destined to you and the attacks that we're blocking, all of that is also available to you as well.

You can consume that from our GraphQL API.

You can go to the dashboard and slice and dice it any way that you want to, and we'll send you automatic reports to let you know what's going on with your traffic, if your network is getting attacked.

And lots of customers tell us when they get those reports or look at the data in the API, that's the first time that they were aware that they were hit by a really big attack, because again, we just kind of handle it for you.

So if I'm...

this all sounds really exciting. Magic Transit's added a lot, given a lot of value to a lot of organizations, made life simpler for a lot of network engineers.

How do I get started?

Yeah, if you are interested, I believe we have a snazzy landing page that you can go check out to learn more.

cloudflare.com/magic-transit And there's a form that you can fill out to get in contact with someone that will be able to give you more information, a custom demo, and answer all of your questions about how to get started.

That's awesome!

This is a great discussion. I'm really excited about this feature and this capability that we just launched that's going to allow a lot more organizations to take advantage of Magic Transit.

Awesome.

Thank you so much for the time, Ameet. Thanks, everybody, for watching.

Great talking to you.

Thanks, everyone.