Traffic Return Strategies

Hello! Welcome back to our course on architecting security products.

In our last few lessons, we've designed the core components of a DDoS scrubbing pipeline. We started with BGP Anycast for traffic ingestion, then designed detection and mitigation systems for L3/4 and L7 attacks, including the use of rate-limiting algorithms. We've successfully "cleaned" the traffic. Now, we face the final, crucial step in the data path: getting the legitimate traffic back to the origin servers.

This lesson's learning outcome is to design mechanisms for returning cleaned traffic to origin servers, considering latency, security, and protocol transparency.

The method you choose for this "traffic backhaul" has profound implications for your system's performance, security posture, and, most importantly, whether your applications can even function correctly. We'll explore three primary architectural patterns, analyzing the deep trade-offs between them.

1. The Core Challenge: Protocol Transparency

Before we dive into solutions, let's clearly define the problem. When a scrubbing center filters traffic, it acts as a middleman. If it simply receives a packet from a client and then opens a new connection to your origin server, your server's access logs will show the IP address of the scrubbing center, not the original client.

This loss of the original client IP is a critical failure. It breaks:

• Logging and Analytics: You can't tell where your users are coming from.
• Application Logic: Features based on geolocation or client IP-based rules will fail.
• Security: IP-based access control lists (ACLs) or fraud detection systems become useless.

Therefore, the central challenge is achieving protocol transparency: ensuring the origin server sees the original, unaltered connection information (source IP, source port, destination IP, destination port).

2. Mechanism 1: L3 Tunneling with GRE

One of the most common ways to achieve L3 transparency is by using a tunneling protocol. Generic Routing Encapsulation (GRE) is a standard choice for this.

A tunnel encapsulates the original IP packet inside a new IP packet. Think of it like putting a letter (the original packet) inside a new envelope (the tunnel packet) to send it to a different destination (your network edge) before it's opened and delivered to its final recipient (the origin server).

Let's explore how GRE is used in DDoS mitigation and its architectural implications.

As the article explains, after your scrubbing center drops the malicious packets, it takes the remaining clean packets and encapsulates them within a GRE header. These new, larger packets are then routed over the public internet to a GRE tunnel endpoint on your network edge (typically a router). Your router decapsulates the packets, removing the GRE header and revealing the original packet, which it then forwards to the correct origin server. The origin server receives the packet as if it came directly from the client.

Architectural Trade-offs of GRE Tunneling

While powerful, GRE is not a silver bullet. It introduces its own set of challenges, which you must design for.

Let's summarize these key design considerations:

• Latency: GRE adds some processing overhead for encapsulation and decapsulation. More importantly, it forces traffic to make an extra hop (Scrubbing Center -> Your Network Edge) instead of going directly to the origin, which can add latency.
• Security: Standard GRE provides no encryption. The "cleaned" traffic is sent in cleartext over the internet. To secure the tunnel, GRE is often combined with IPSec, which adds another layer of encapsulation and processing overhead.
• Protocol Transparency: This is GRE's main advantage. It provides full Layer 3 transparency. The origin server sees the original source and destination IPs and ports without any modification. It is completely protocol-agnostic.
• Complexity & Reliability (The "Bad"):
  • MTU Overhead: The GRE header (and IPSec header, if used) adds bytes to every packet. A standard Ethernet frame has a Maximum Transmission Unit (MTU) of 1500 bytes. If an encapsulated packet exceeds this, it must be fragmented. Packet fragmentation can degrade performance and is sometimes blocked by intermediate network devices, leading to mysterious packet loss.
  • Mitigation: You must carefully tune the MTU on the GRE interface or use TCP MSS (Maximum Segment Size) clamping to force endpoints to use smaller packets, leaving room for the tunnel headers.
  • Operational Burden: Tunnels require careful configuration, monitoring, and maintenance at both ends.

3. Mechanism 2: L7 Proxying with the PROXY Protocol

An alternative to L3 tunneling is to operate at Layer 7. In this model, the scrubbing center acts as a full reverse proxy. It terminates the client's TCP connection, inspects the application-layer data (e.g., HTTP), and if the request is clean, it initiates a new TCP connection to the origin server.

As we discussed, this breaks protocol transparency by default. The solution is the PROXY protocol.

The PROXY protocol works by having the proxy (the scrubbing center) prepend a small, simple header to the beginning of the TCP data stream it sends to the origin server. This header contains the original client's connection information.

Here is an example of a PROXY protocol v1 header:
PROXY TCP4 192.168.0.1 192.168.0.11 56324 443\r\n

This line tells the receiving server: "The real source was 192.168.0.1 on port 56324, and it was trying to reach 192.168.0.11 on port 443." The server, which must be configured to understand the PROXY protocol, then parses this line and uses these values as the effective source/destination, restoring transparency.

Architectural Trade-offs of the PROXY Protocol

• Latency: Similar to other proxy setups, terminating TCP and opening a new connection adds latency.
• Security: The connection from the scrubbing center to the origin can be a standard TLS connection, securing the data in transit.
• Protocol Transparency: It provides L4 transparency for TCP-based protocols. Version 2 can even carry additional L7 information like TLS ALPN or SNI.
• Complexity & Reliability:
  • No MTU Issues: Since you aren't encapsulating entire IP packets, you avoid the MTU problems associated with tunneling.
  • Origin Modification Required: This is the biggest drawback. Your origin servers, or the load balancers in front of them, must be explicitly configured to understand and parse the PROXY protocol. This is an application-level or server configuration change, unlike GRE which is handled at the network edge. Not all server software supports it.

4. Mechanism 3: Direct Server Return (DSR)

DSR is an advanced and highly efficient technique that creates an asymmetric traffic path. Ingress traffic flows through the scrubbing center, but egress traffic goes directly from the origin server back to the client, bypassing the scrubbing center on the return trip.

How DSR Works (from a system design perspective):

1. Ingress: The scrubbing center receives a packet from the client. It does not terminate the connection or act as a proxy. It performs its filtering and then forwards the clean packet to the origin server. Crucially, it preserves the original source IP of the client in the packet header. The destination IP is a Virtual IP (VIP) for the service.
2. Origin Server: The origin server receives the packet. Its network stack is specially configured. It has the service's VIP assigned to a non-arping loopback interface. This tricks the server's kernel into accepting the packet.
3. Egress: When the server generates a reply, its routing table is configured to send the packet directly to the client (using the original source IP from the request as the destination), via its default gateway. The reply packet's source IP is the service VIP.

Architectural Trade-offs of DSR

• Latency: Offers the lowest possible latency, as the return path is the shortest possible path over the internet.
• Security: The return path is not inspected by the scrubbing center. Also, stateful firewalls in the origin's data center may be confused, as they will see reply packets (SYN-ACKs) without having seen the initial request packets (SYNs), and might drop them.
• Protocol Transparency: Provides full L3 transparency, just like GRE.
• Complexity & Reliability:
  • Extremely High Implementation Complexity: DSR requires deep and complex modifications to the origin server's network stack and routing. It is not a standard feature and is notoriously difficult to configure correctly and maintain.
  • Scalability Benefit: Since the scrubbing center only has to process ingress traffic, its effective throughput is doubled. This is a massive benefit for large-scale services.

5. Summary and Making a Choice

There is no single "best" way to return cleaned traffic. The optimal choice is a classic engineering trade-off based on your specific requirements.

Mechanism	Protocol Transparency	Latency Impact	Implementation Complexity	Origin Impact
GRE Tunnel	Excellent (Full L3)	Medium (Extra Hop)	Medium (Network-level config, MTU tuning)	None (Transparent)
L7 Proxy + PROXY Protocol	Good (L4 for TCP)	Medium (TCP Termination)	Low (Proxy config)	High (Server must support PROXY protocol)
Direct Server Return (DSR)	Excellent (Full L3)	Low (Optimal Path)	Very High (Kernel/Network stack mods)	Very High (Complex server config)

As the FastNetMon article wisely concludes, it depends.

• GRE Tunnels remain a flexible and universal default, especially if you can control both ends and manage MTU carefully.
• L7 Proxying is a strong choice if you are already terminating TLS at your edge, need deep L7 inspection, and your application stack can easily support the PROXY protocol.
• DSR is the choice for hyper-scale, latency-sensitive applications (like gaming or real-time streaming) where you have the engineering expertise to manage the significant operational complexity in exchange for maximum performance.

Conclusion

In this lesson, we explored the critical final stage of a DDoS mitigation pipeline: returning cleaned traffic to the origin. We designed and analyzed three distinct architectural patterns to accomplish this.

Key Takeaways:

• Protocol Transparency is Non-Negotiable: Losing the client's IP address is often a showstopper. Your return mechanism must preserve it.
• GRE Tunneling provides L3 Transparency: It encapsulates original packets, making the process transparent to the origin server but introduces MTU and operational challenges.
• The PROXY Protocol provides L4/L7 Transparency: It avoids tunneling issues but requires the origin server to be explicitly configured to parse a special header.
• Direct Server Return (DSR) offers the Best Performance: It creates an asymmetric route for the lowest latency but is by far the most complex to implement on the origin servers.
• The choice is a trade-off between transparency, latency, and implementation complexity.

Preview of the Next Lesson:

We have now designed the full, end-to-end data path for a DDoS scrubbing system. But when should this system be active? Should it inspect every packet all the time, or only when an attack is detected? In our next lesson, we will evaluate the trade-offs between always-on vs. on-demand DDoS mitigation and design reactive auto-scaling mechanisms to manage these modes.