Overview
This page presents an overview of the Gatekeeper architecture and system.
Gatekeeper has two main components: one or more Gatekeeper servers in a vantage point, and one or more Grantor servers in a data center close to the destination. The basic flow of data plane packets in a Gatekeeper protected system is:
- Instead of being forwarded directly to the destination specified by the destination IP address, packets are forwarded to their nearest Gatekeeper server. Gatekeeper servers announce the protected prefixes using BGP to create this anycast network.
- The Gatekeeper server forwards or drops the packets based on a policy running on the Grantor server(s). If Gatekeeper does not have a policy decision for a flow, it makes a request to Grantor. Gatekeeper servers then cache the policy decisions given by Grantor and enforce them over all packets of the affected flow. Both requests and granted packets are sent to Grantor by encapsulating them in an extra IP header.
- Grantor receives requests and granted packets from Gatekeeper and decapsulates the extra IP header. If it's a request packet, Grantor runs the request through its policy and sends back a policy decision to Gatekeeper. If it's a granted packet, Grantor forwards the packet to the ultimate destination.
Gatekeeper servers are the servers allocated at Vantage Points. They announce routes to the protected prefixes in the destination and enforce the policies specified by Grantor servers on flows. These policies may be to drop packets or rate limit flows.
Grantor servers are the servers allocated close to the protected destinations. They make policy decisions according to the Lua policy specified by the operator, and forward granted packets to their ultimate destinations.
Points at which Gatekeeper servers are deployed, such as Internet exchange points (IXPs), some cloud providers, and peering links. Vantage points give a network operator control over what happens to packets close to the source of the attack, which was previously not easy to do; typically, a destination network does not have control over the policies of the network of the attack source. Vantage points make Gatekeeper effective because they allow for inspection (and dropping) of packets early in the path to the target destination without needing the cooperation of other operators.
Gatekeeper servers and routers along the Gatekeeper to Grantor path queue packets according to their priority. Packets are given a priority by Gatekeeper servers, which write the priority to the differentiated services ("DiffServ" or "DS") field in IP (both IPv4 and IPv6) packets. The type to value mapping is:
- Legacy/unclassified packets: DS field value of 0
- Granted packet, or granted packet in flow whose capability is about to expire: DS field value of 1 or 2, respectively
- Request packet: DS field value of 3-63, where a larger value is a higher priority
Request packets are given their own channel, which utilizes some small portion of the bandwidth of the link. The Solicitor block can be configured to adjust this rate. See Request Channel below for a full explanation of how capability requests are handled.
Granted packets are also given their own channel, and are allocated most of the bandwidth of the link. The granted queues also utilize the random-early-detection (RED) algorithm.
Finally, operational packets are queued separately. Note that Gatekeeper does not explicitly pass operational, control plane packets (ARP, ND, BGP, etc.) through the Gatekeeper to Grantor channel, and therefore any such packets do not fall under the request/granted scheme either because they are below the IP layer (ARP) or would be given a DS field value of 0 by legacy software (ND, BGP). This is represented by the Operational RED Queue in the above figure. Any such packets are transmitted using either a small amount of reserved bandwidth, or as best-effort utilizing whatever residual bandwidth is left after processing granted and request packets.
The request channel between Gatekeeper and Grantor servers is a critical component of the system, since it is used to restrict the ability of senders without a capability to overwhelm target servers. There are three mechanisms that make this possible: allocating a small percentage of the available bandwidth to requests, assigning priorities to requests based on the speed at which a sender is transmitting, and dropping low-priority packets when the bandwidth of the request channel is consumed.
Request packets are given a priority based on the log of the flow's waiting time, i.e. log2(delta_time). Senders that wait longer between packets to transmit are awarded a higher priority. This is similar to the exponential back-off method used in Portcullis.
Gatekeeper is an open source application in the DPDK framework. It is intended to be used by network operators of institutions, service and content providers, enterprise networks, etc. It is not intended to be used by individual Internet users, since it requires the resources to deploy in vantage points and the privileges to announce Gatekeeper-protected prefixes to be sent through Gatekeeper.
Gatekeeper servers and Grantor servers are both run using the gatekeeper executable, just with different configuration options as specified below.
The gatekeeper program is composed of functional blocks, each performing an individual task and assigned one or more lcores (threads) to do so.
The blocks are:
- CPS: tasks related to routing and the control plane. Can be run in either Gatekeeper or Grantor servers.
- Dynamic Config: tasks related to altering and viewing gatekeeper state at runtime. Can be run in either Gatekeeper or Grantor servers.
- LLS: tasks related to link layer protocols and IP address resolution. Can be run in either Gatekeeper or Grantor servers.
- GK: tasks related to the main Gatekeeper server algorithm of receiving packets and processing them according to the cached policy. Can only be run in Gatekeeper servers.
- SOL: tasks related to issuing requests to Grantor when Gatekeeper has no cached policy for a flow. Can only be run in Gatekeeper servers.
- GT-GK Unit: tasks related to receiving and processing policy decisions from Grantor. Can only be run in Gatekeeper servers.
- GT: tasks related to the main Grantor server algorithm of receiving requests and issuing decisions for how to handle flows based on a policy. Can only be run in Grantor servers.
If you are a student, researcher, or potential user of Gatekeeper and want to test it, see the page Experimenting with Gatekeeper.
To set up a full-scale Gatekeeper deployment, you will need access and resources to deploy Gatekeeper in a vantage point. You will also need the ability to announce Gatekeeper-protected prefixes to your services or hosts using a control plane tool like BIRD.
Some other useful information when choosing how to deploy Gatekeeper and set up the system:
Once the deployment is ready, Gatekeeper can be setup according to the steps in the README of the Gatekeeper repository.gatekeeper uses a set of Lua files as its configuration. See Configuration for a complete overview of how to configure the network and individual blocks before running Gatekeeper, and how to use the dynamic configuration at runtime.