Comparing Gatekeeper with traditional DDoS firewalls

[datutu58888]

hello
"I've been looking at Gatekeeper for a while and still don't understand what its function is. I'm deploying it now. My current understanding is that DDoS defense primarily works by identifying traffic at the TCP and UDP transport layers and applying a verification mechanism to filter out malicious traffic. It's similar for Layer 3 and Layer 4 applications; without that, it would be impossible to judge if the traffic is legitimate."
"Traditional commercial DDoS firewalls allow users to define cleansing thresholds for attacks like SYN floods and UDP floods to activate verification and filtering mechanisms. I don't see how Gatekeeper can identify and cleanse illegitimate packets, such as those from a SYN flood."

"Does Gatekeeper support multi-tenant environments in an IDC (Internet Data Center), with deployment options like passive (out-of-band) or inline (bridge/serial) mode, and is its presence transparent?"

[AltraMayor]

Hi @datutu58888,

Since you are still learning what Gatekeeper does, I recommend you watch our NANOG 82 presentation and explore the other references on the Publications page of our wiki.

For a Gatekeeper deployment to support multiple tenants in a datacenter, one has to write a policy that is aware of the tenants. Since you're just getting started with Gatekeeper, I advise you to start with the simplest policy you can get running and grow from there. The wiki page Tips for Deployments can help with these initial steps.

Our documentation focuses on Gatekeeper deployments in line with the protected networks, but this is not a requirement. See this NextHop 2020 presentation for an advanced example of a deployment that dynamically allocates network prefixes to off-path Gatekeeper servers. For this to work, one needs to plan the routing infrastructure carefully.

Typical Gatekeeper deployments write policies for Gatekeeper to be transparent for the protected applications because the deployer has no way to modify the applications. Therefore, as long as one writes a policy aware of the applications, Gatekeeper will be transparent for the applications. When the deployer controls the protocols the applications use, it's possible to write much tighter policies.

If you want to flatten the learning curve and have professional support, see Digirati's Gatekeeper consultancy. They have been contributing to the Gatekeeper project since the beginning, have operational experience with Gatekeeper, and are committed to the project's long-term success.

[datutu58888]

You do realize null-routing isn't exactly a solution, given a customer would start looking for a different service as soon as you drop all their traffic. I would, if I was a customer.

Our IDC has a 2Tb egress bandwidth, while the upstream ISP has 7Tb. If we offend a certain attacker, they can easily take us down with a UDP reflection attack. In that case, the 7Tb ISP must handle the blackhole routing.

[AltraMayor]

Hi @datutu58888,

As you pointed out, blackholing is a last resort option. Designing a Gatekeeper deployment around blackholing is not a good plan. Your Gatekeeper deployment can circumvent the high cost of expanding the bandwidth at your datacenter by deploying Gatekeeper servers in Internet exchanges where bandwidth is much cheaper, so only filtered traffic goes to your datacenter. Once your deployment is distributed, you may not need 2Tbps capacity at the datacenter.

Gatekeeper targets use cases like yours: large-scale, distributed deployments, and multi-tenants. But such a deployment takes time to build. Given that you're not making it through the presentations and documentation I cited above because of the language barrier, how do you expect to maintain your deployment?

[datutu58888]

Hi @datutu58888,

As you pointed out, blackholing is a last resort option. Designing a Gatekeeper deployment around blackholing is not a good plan. Your Gatekeeper deployment can circumvent the high cost of expanding the bandwidth at your datacenter by deploying Gatekeeper servers in Internet exchanges where bandwidth is much cheaper, so only filtered traffic goes to your datacenter. Once your deployment is distributed, you may not need 2Tbps capacity at the datacenter.

Gatekeeper targets use cases like yours: large-scale, distributed deployments, and multi-tenants. But such a deployment takes time to build. Given that you're not making it through the presentations and documentation I cited above because of the language barrier, how do you expect to maintain your deployment?

我尝试用中文表达一下，看看你们的翻译软件是否更出色

☺️将gatekeeper部署到交换中心，这在中国不可想象，中国有三大国有电信公司控制整个互联网，三家电信公司分别在全国部署了网络，然后三张网络在九个城市做了互联互通，中国的idc公司只能在idc出口部署过滤，idc只能选用三家电信的类gatekeeper产品，近几年中国政府推动交换中心建设，但是三家电信并不配合

[AltraMayor]

I'm sorry, @datutu58888, but I can't help you. You are better off hiring a DDoS protection company in your area. They will understand your challenges well and serve you in your language. Good luck!

[datutu58888]

I'm sorry, @datutu58888, but I can't help you. You are better off hiring a DDoS protection company in your area. They will understand your challenges well and serve you in your language. Good luck!

Thank you very much for your reply. I just received my E810 NIC (Network Interface Card) a few days ago, and I am preparing to test GATEKEEPER, primarily focusing on its performance after bridging. Although your defense mechanism differs from our traditional approach, I am still keen to try it out. Currently, we only have five local DDoS service providers, and their effectiveness is unsatisfactory. While I may not fully grasp your defense methodology through our discussions, I believe it is worth a try as long as it supports cleaning and mitigation in an in-line, bridged deployment within our IDC (Internet Data Center).