ReAct: Reflection attack mitigation for asymmetric routing

This work was conducted in collaboration with David Hay from The Hebrew University of Jerusalem and Shir Landau Feibish from the University of Haifa, and was published in the proceedings of the IEEE International Conference on Computer Communications (INFOCOM) 2026.

Distributed Denial-of-Service (DDoS) attacks have been a longstanding threat and continue to be a destructive force on the Internet. These attacks become even more destructive when the attack traffic is seemingly legitimate, as in the case of Amplified Reflection DDoS (AR-DDoS) attacks.

Existing mitigation strategies can work well when traffic is symmetric - when a response follows the same path as its corresponding request. However, if even a small amount of traffic is asymmetric, it will cause those strategies to drop legitimate traffic, leading to a potentially significant disruption of service. These downsides make operators resistant to deploying AR-DDoS detection techniques.

ReAct was created to address this gap: It provides efficient and effective mitigation against AR-DDoS attacks, when routing is either symmetric or asymmetric. In the case of asymmetric traffic, ReAct will not drop legitimate traffic.

We have implemented ReAct for the Intel Tofino and the Nvidia Bluefield-3.

Why networks are still vulnerable to reflection attacks

In a nutshell, AR-DDoS attacks exploit vulnerable servers on the Internet, turning them into reflectors that overwhelm the targeted victim with excessive traffic. In most cases, the reflectors also amplify the traffic, as the amount of traffic they send to the victim is much larger than the traffic they receive from the attacker(s). Perhaps the most infamous such attack is a DNS AR-DDoS attack, in which an attacker sends numerous DNS requests on behalf of the targeted victim, which are then spammed by DNS responses it did not ask for.

Certain communication protocols (like DNS, Network Time Protocol (NTP)) feature small requests that generate disproportionately large responses. AR-DDOS attacks exploit this amplification. The attacker spoofs a source IP address, causing the response to be sent to the victim. Such attacks usually work on connectionless protocols, typically done over User Datagram Protocol (UDP). Since there is no pre-established connection and thus no connection identifier, a transaction ID is often used to match the response to the request.

Before the introduction of programmable devices, users had very limited ability to change the applications running on the hardware, and often relied on manufacturers to make necessary changes. Recent advancements in programmable networks allow new functionalities to be performed inside the data plane. Users can create new telemetry applications, support new protocols, add customized firewalls, and more, just by writing a simple program.

Existing programmable-switch-based systems use request-response counters to decide whether to drop responses. As an example, Jaqen counts received requests. When a matching response is received, it decrements its counter. If the counter is , then the response is categorized as an attack and is dropped, because there has not been a request. DIDA works similarly, but maintains counters based on source and destination IP addresses.

All of these solutions make the underlying assumption that routing is symmetric. However, the route of requests from the client to the server may not be the same as the route taken by the corresponding response. This presents a significant challenge to solutions that rely on symmetry, as it will cause them to erroneously drop legitimate traffic.

How ReAct works

ReAct is a solution that is capable of identifying AR-DDoS attacks regardless of whether routing is symmetric or not. This allows operators to identify legitimate traffic, so that attack traffic is blocked while legitimate requests are processed as usual.

ReAct can run on a variety of different programmable devices - we have prototypes for the Intel Tofino programmable switch and the NVIDIA Bluefield-3 smartNIC. ReAct can also be implemented in other places in the network, for example, a Content Distribution Network (CDN) Point of Presence (PoP) at the network edge, or in large data centre networks. The only requirement is that traffic (both ingress and egress) traverses one of the programmable devices.

ReAct works by matching requests and responses using the transaction ID.

In the symmetric case, this is simple. We store the transaction ID of the request and wait for a response. When the response arrives, we look up its ID to see if we have previously seen the request with the matching ID. If we have, we classify this as a legitimate response, and we forward it to its destination. Otherwise, it is attack traffic that should be blocked.

ReAct performs the same joining of request and response in the asymmetric case, but requires some coordination between the programmable devices in the network. Each programmable switch maintains a list of prefixes and of the switches that handle requests from those prefixes. When a switch receives a response, if it has not seen the corresponding request, it forwards the response to the switch that would have seen the request.

There are two ways we identify which requests each switch handles. If routing is known already, and we know which prefixes a switch serves, we can create a set of forwarding rules ahead of time. If switch A sees a response from a prefix served by switch B, switch A will have a rule to forward that response to switch B.

If we don't know the routing ahead of time, the switches learn this information as it becomes available. ReAct relies on request retransmissions, which are triggered if the original request has not received a response within some amount of time. If switch A sees a retransmitted request, this may be because a different switch (switch B) saw the response and incorrectly dropped it. In this case, switch A will broadcast the request to all other ReAct switches in the network. When this broadcast request reaches switch B, switch B learns that switch A processes the requests for that prefix, and switch A learns that switch B processes the responses. ReAct updates forwarding rules accordingly after learning this routing.

In an ideal world, we would be able to keep track of every single request and response we see. Unfortunately, programmable hardware often has limited resources and processing capabilities, which makes it impossible to store all the relevant traffic at today's network speeds. As an alternative, ReAct uses an approximate representation of the requests that have recently been seen, which allows it to use a fraction of the memory that would be required for taking exact measurements (while maintaining high accuracy).

ReAct accomplishes this with a Bloom filter - a probabilistic data structure used to test set membership. Packets are hashed to a bucket in the Bloom filter based on the transaction ID. If the packet is a request, we set the bit in that bucket to . If it's a response, we check if the bit is (the switch has seen the corresponding request). Bloom filters do not track exact measurements, however, because of the possibility of hash collisions. Two transaction IDs could hash to the same bucket, potentially causing a false positive. In our case, this would mean that we can incorrectly identify a malicious response as legitimate.

In practice, however, we find this error rate to be relatively low. For a 30-second simulation of 7,000 requests per second, ReAct's error rate was less than 3%, or less than 6,000 misclassified responses.

What's next?

ReAct works well for protocols like DNS, which include a transaction ID in both the request and response. This does not hold for all protocols. For example, in NTP, the ID is based on the timestamp of the request. If a request is re-transmitted, it will have a new timestamp, which means there will not be a consistent ID. A key next step for ReAct is supporting these types of protocols that do not rely on transaction IDs.

Our work focuses on AR-DDoS detection and mitigation, but we welcome and encourage discussions on how this distributed defence system can be expanded to prevent other types of attacks and vulnerabilities.

Mary Hogan is an assistant professor at Oberlin College. Her work focuses on developing applications for programmable network devices that help bring security and efficiency to networks. She also develops abstractions to make it easier to work with programmable devices.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.