BGP (Border Gateway Protocol) and GRE (Generic Routing Encapsulation) are a popular combination for DDoS (distributed denial of service) protection. Together, they reroute traffic to dedicated scrubbing centers where harmful data is filtered out, maintaining service while stopping the attack. Let’s dive in and understand exactly why and how they’re used to protect your servers from DDoS attacks.
Although several DDoS protection techniques exist (such as reverse proxy and changing DNS records,) the BGP-GRE pair is a favorite because it provides flexibility, routing accuracy, and reliability. Let’s explore these advantages in turn to understand why BGP-GRE is such a favorable combination. But first, if you’re new to BGP and GRE, we recommend that you check out our dedicated articles to get a sense of what they are:
An organization can use the BGP-GRE pair regardless of their in-house protocol. This is because GRE encapsulates all network protocols within the OSI (Open Systems Interconnection) model layer 3, including IPv4, IPv6, Internet Control Message Protocol (ICMP) with Address Resolution Protocol ARP,) Internet Protocol Security (IPSEC) and multiprotocol label switching (MPLS.)
GRE brings two additional flexibility benefits. Firstly, GRE tunnels can encapsulate unicast, anycast, broadcast, and multicast traffic, meaning they can provide DDoS protection for diverse application types and use cases. Secondly, traffic forwarding can occur regardless of compatibility between client and provider routers, so GRE tunnels can continue directing legitimate traffic to its intended destination, even during a DDoS attack.
BGP routing is highly efficient at ensuring robust and stable packet delivery. BGP can be configured so that traffic to your server is first routed through the scrubbing center before reaching your server(s.) This way, malicious traffic doesn’t reach your server(s) at all, whereas legitimate traffic does.
BGP and GRE’s collective reliability stems from their respective keepalive mechanisms. A keepalive mechanism works by sending small data packets at regular intervals between network devices, like between routers and servers. If a device doesn’t receive a keepalive packet for a certain period of time, it assumes that either the other device or the connection itself has failed. Traffic will then use an alternate path to get to its destination.
So, keepalive mechanisms promptly detect failures and swiftly reroute traffic. This ensures minimal downtime and continuous data flow, enhancing network robustness against disruptions.
Here’s a step-by-step explanation of how BGP and GRE facilitate DDoS protection.
First, a GRE tunnel interface is configured through which packets can move. Then, routing is configured between the two tunnel endpoints—client and scrubbing center routers—at each end of the tunnel interface. The scrubbing center is the centralized place where the service provider analyzes traffic and removes malicious traffic from the client’s website. The connection between the tunnel endpoints is verified by sending keepalive messages to verify tunnel availability.
The client and service provider’s IP addresses are advertised in a BGP update message, which enables BGP to determine the available paths for traffic routing. The advert usually includes client and service provider routing and network reachability information, such as IP prefixes—IP address plus subnet mask.
Two processes then occur:
- Path selection: BGP shares routing information between sender and recipient routers so they can see each other at both ends of the configured GRE tunnel. BGP selects the best path from the multiple paths advertised and installs it in the BGP database.
- Traffic rerouting: Once BGP routing is configured, the DDoS protection service provider announces the client’s networks and routing information to show everyone on the internet that traffic routing to the client occurs via the chosen service provider.
3. Traffic Scrubbing
This is where the magic happens: DDoS attacks are stopped via real-time traffic analysis. Traffic is rerouted to the scrubbing center, where the service provider analyzes it to differentiate malicious traffic from legitimate traffic. Malicious traffic is blocked; legitimate traffic is served without any perceptible latency.
Clean traffic is encapsulated in GRE packets so that GRE can send the traffic via the tunnel. A tunnel header (and sometimes also a trailer) is added to the original packet:
- The actual data and its IP header information become the payload of the GRE packet.
- The GRE header is always added to allow packet forwarding.
- A trailer is added only when additional error-checking or data integrity features are required, such as cyclic redundancy check (CRC) fields. If these extra features aren’t needed or the underlying transport network already provides sufficient error detection and correction mechanisms, a trailer isn’t used.
The header typically contains metadata, like the protocol type, and routing information, such as the source, destination, and any other values required to facilitate packet delivery. Designating these details in the header ensures routers don’t need to access the encapsulated packets for routing details, keeping the original data secure.
Once the scrubbed traffic is encapsulated in GRE packets, it is sent to the client endpoint through the GRE tunnel.
At the other end of the tunnel, packets are decapsulated. This involves discarding the GRE header and exposing the original packet. The decapsulated packet is sent to the client’s server, from which users receive the data they requested.
Using the BGP-GRE pair presents two challenges: increased packet size and extra BGP hops.
The efficiency of a network is determined by evaluating the ratio of the actual data payload to the overhead incurred in its transmission. In GRE tunneling, the overhead is relatively high due to the addition of GRE packet headers. Although adding GRE headers bolsters packet security, the approach may affect network efficiency, increase latency, or result in unnecessary packet fragmentation.
Increased packet size isn’t a problem when the original packet is very small. But if the original packet is large, adding extra packet headers means that the packet may exceed the standard maximum transfer unit (MTU) and maximum segment size (MSS) value, since the GRE header adds about 24 bytes of overhead to the data. This can cause packet fragmentation. Packet fragmentation splits data into smaller packets to comply with MTU and MSS limits, affecting throughput and increasing error chances.
To mitigate this, path MTU discovery (PMTUD) can be used to determine the maximum MTU, then the limit can be adjusted accordingly to accommodate the GRE header. However, this requires additional computational and network resources.
Routing through a cleaning center can add additional hops, making the routing less optimal. To resolve this, choose a service provider with scrubbing centers worldwide to ensure fewer hops for all users trying to access your page.
The BGP-GRE pair is an attractive option for DDoS protection, offering routing accuracy and traffic delivery reliability. It does come with limitations, but these can largely be mitigated by choosing a responsible and reliable DDoS provider.
Gcore offers highly efficient and effective DDoS Protection with a traffic filtering capacity of over 1 Tbps, real-time statistics for transparent assessment of the traffic scrubbing process, and scrubbing centers located worldwide. Get started for free and protect your websites, apps, and servers from even the most potential DDoS attacks.