Gatekeeper

What is Gatekeeper?

Gatekeeper is the first open-source DoS protection system. It is designed to scale to any peak bandwidth, so it can withstand DoS attacks both today and tomorrow. In spite of its geographically distributed architecture, the network policy that describes all decisions that have to be enforced on the incoming traffic is centralized. This centralized policy enables network operators to leverage distributed algorithms that would not be viable under very high latency (e.g. distributed databases) and to fight multiple multi-vector DoS attacks at once.

The intended users of it are network operators of institutions, service and content providers, enterprise networks, etc. It is not intended to be used by individual Internet users.

How does Gatekeeper work?

It has two components: Gatekeeper servers and Grantor servers. Gatekeeper servers are deployed throughout the Internet at locations called vantage points (VPs). Vantage points are Internet exchange points (IXPs), border and peering-link routers, and (potentially) cloud providers. The aggregated bandwidth of all Gatekeeper servers is what enables a Gatekeeper deployment to scale its incoming bandwidth to match the peak bandwidth of DoS attacks.

Gatekeeper servers use BGP to announce the network prefixes under their protection. Thus, each traffic source is bound to a VP. Gatekeeper servers’ primary function is to enforce network policy overflows; a flow is defined by the pair source and destination IP addresses. An example of a policy decision is for IP address A to be allowed to send packets to IP address B at 1Gbps or less. An analogy that may help some to wrap their head around Gatekeeper is to think of Gatekeeper servers as reverse proxies that work at the IP layer.

When a Gatekeeper server does not have is a policy decision in its flow table to enforce over any given flow. Instead, it encapsulates the packet of that flow using IP-in-IP, assigns a priority to the encapsulated packet based on the rate of the given flow (higher priority for lower rates), and forwards it through the request channel. The request channel is reserved 5% of the bandwidth of the path that goes from a Gatekeeper server to the Grantor server responsible for the policy decision. Whenever a router forwarding the packets in the request channel needs to drop packets due to the limited bandwidth, it drops the packets of the lowest priority in its queues.

A network policy is a Lua script that runs on Grantor servers. Grantor servers are co-located near the protected destination; typically in the same data center of the destination. One can deploy Grantor servers in other locations and even employ anycast to reach varied destinations, but we assume here (for the sake of simplicity) that the destination prefix is deployed in a single datacenter.

Grantor servers are responsible for making a policy decision on each flow in the request channel. These policy decisions are sent to the corresponding Gatekeeper servers to enforce them. As policy decisions are installed into it servers, the flows of legitimate senders get moved to the granted channel, in which bandwidth is allocated according to the policy. Similarly, identified malicious hosts would be blocked. This, in turn, would reduce the delay experienced by legitimate flows waiting at the request channel.

To summarizing, a Gatekeeper deployment consists of a number of vantage points forming a shield around the protected networks. Grantor servers, which reside inside of the shield but before the final destinations of the packets, run the network policy to decide the fate of all incoming traffic. The policy decisions are installed at Gatekeeper servers, which enforce these policy decisions.

Changelog v1.1

This newer version of Gatekeeper updates Gatekeeper’s custom versions of DPDK and LuaJIT, enhances the log subsystem, adds the handy BPF program tcp-services.c, loads large routing tables much faster, allows default routes, supports more NICs, and includes several other improvements.

This version improves over v1.1.0 RC2 by:

1. Implementing our own FIB library (see pull requests #628 and #633 and issues #91 and #632);
2. Loosening verifications of the routing table to enable default routes (see pull request #630);
3. Releasing memory pressure on Lua policies (see pull request #635 and issue #212).

This version has been extensively tested in production.

Install & Use

Copyright (C) 2016 AltraMayor