Infoblox’s Advanced DNS Protection (ADP) product has many features that enhance survivability in the face of congestion caused by line-rate attacks. One of these features is called WRED (Weighted Random Early Detection), and it acts as a resource starvation prevention mechanism.
In case you are not entirely familiar with WRED, here is a quick description from Wikipedia – Weighted random early detection (WRED) is a queueing discipline for a network scheduler suited for congestion avoidance. It is an extension to random early detection (RED) where a single queue may have several different sets of queue thresholds. Each traffic class has a queue threshold.
WRED Support in Infoblox ADP
The following ADP appliances mentioned below have an implementation of WRED.
- WRED is implemented in all physical appliances that use a network processor card for all supported NIOS releases. These include the IB-4030 series and the PT series appliances.
- The physical appliances supporting DPDK, and virtual appliances utilizing DPDK, and SR-IOV since NIOS 8.3. These include Physical and Virtual TE-14\*5, TE-22\*5, TE-40\*5.
Infoblox’s WRED implementation uses multiple input queues that are prioritized by the protocol of the packet. If there is enough processing capacity to empty all the queues then it will process all incoming packets, however, if the incoming packet rate is higher than processing capacity, lower priority traffic may be dropped.
As we have a fixed amount of memory for networking buffers in any system, WRED makes sure we have enough memory such that the system can continue to operate even under extreme traffic load such as a DDoS attack.
How WRED Manages Priority
The stack layer uses a traffic classifier, and it gives preference to the traffic in a specific order. Once it detects an overload, the traffic types higher up in the list get higher priority over the traffic types lower down in this list, which may get discarded partly or entirely.
Please see the prioritization of traffic types below.
- Internal grid VPN UDP traffic –> highest preference
- HTTPS GUI traffic
- SSH management traffic
- VRRP Traffic (in case of HA)
- DNS traffic
- TCP traffic
- ICMP traffic (important for IPv6)
- Anything else –> lowest preference, these packets may get dropped if the system is on resources.
The most significant factor in the WRED algorithm is the number of concurrent transactions the system is handling at any point of time, so latency is a big factor. Given all the different factors, it is not possible to quote WRED as a QPS/PPS rate, as memory is used for every packet, e.g., NTP, ICMP, UDP, and TCP. For example, on a 1GbE interface, you can have bursts of activity that are well over 1M QPS/PPS, and the system has to absorb the load to resolve all the QPS.
The system does not use hard limits or pre-defined thresholds when WRED kicks in; it is a continuous process that prioritizes all packets in real time to provide continuous protection.
Consider the following scenarios on a 1GbE interface:
- 1 million SYN requests per second with no other traffic – the system will process the SYN requests.
- 750K SYN requests interleaved with 750K DNS requests – most of the SYN requests will be discarded and all the DNS requests will be answered.
- 500K HTTP requests + 400K ping requests + 500K DNS requests – almost all the ping requests will be discarded; some of the HTTP requests will be discarded; and all the DNS requests will be answered.
In the previous two scenarios, if you are also part of an ANYcast group using say BGP, some of the BGP packets may be dropped. In a prolonged attack (not a momentary surge), this DNS server may be dropped from the ANYcast group, only to return after the flood subsides.
Of course, the overall intent of ADP and WRED is to remain operational despite an overwhelming attack. We’ve seen examples where the infrastructure in front of an ADP did not survive. Especially susceptible are DPI/stateful firewalls/load balancers.
The Infoblox Advanced DNS Protection protects its DNS infrastructure from the widest range of external, and internal attacks. DDoS/DoS is probably the largest attack vector used against DNS servers, and the NIOS ADP implementation of WRED supplies the last line of defense and provides an assurance of survivability.