RIOS 8.6.0 to 8.8.0: What Shipped (that you might have missed)
Our release notes cover what changed, this post explains why those changes were made across RIOS 8.6 through 8.8.0.
RIOS 8.7.0 New attack variation: attacks in the outer GRE header
RIOS has always performed inner-packet analysis of GRE tunnel traffic. When traffic arrives tunneled inside GRE, RIOS looks past the outer header, analyzes the encapsulated packets, and mitigates on what it finds there. The outer header is validated, not mitigated against. This approach focuses on deep inspection of tunneled traffic instead of reporting on the wrapper.
Last year we saw a new attack variation that took advantage of this trade-off.
The attacker spoofed the outer GRE packets themselves and used those as the flood, while placing entirely valid traffic inside the tunnel. Inner-packet analysis looked into the tunnel, found legitimate traffic, and correctly concluded there was no attack inside. The attack was never inside. It was the encapsulation.
Behaviorally the outer flood was a UDP flood, just wearing a GRE header. No new methodology, just a clever variation of strategy by attackers. See our taxonomy of DDoS attacks for how we classify the underlying methods.
RIOS 8.7.0 introduced the fix. Operators could then configure RIOS to validate both layers and mitigate on the outer packet. Previously RIOS validated the outer header and mitigated on the inner packets. Now, depending on configuration, it does both.
Who should act: anyone terminating GRE tunnels at scale, particularly hosting providers, ISPs, and scrubbing center operators. If you carry GRE and have not reviewed this setting, review it.
RIOS 8.8.0: Higher concurrent limits for spoofed AT1, AT2, and AT3
RIOS mitigates up to 64K concurrent attacks for most attack classes. Spoofed SYN Flood, SYN-ACK Flood, and ACK & PUSH ACK Flood were the exception, capped at 256 simultaneous mitigations. Force On mode, which increases mitigation aggressiveness when a standard mitigation is not fully containing an attack, was capped at 64 prefixes per attack type.
For an enterprise protecting a handful of prefixes, those numbers were never the constraint. For a scrubbing center absorbing burst attacks across thousands of prefixes, they can be. This is something learned through operation of our own rCloud scrubbing center.
RIOS 8.8.0 raises concurrent spoofed AT1, AT2, and AT3 mitigations from 256 to 16K, and raises Force On to 4096 prefixes per attack type. You can now run Force On across 4096 AT1 victims, 4096 AT2 victims, and 4096 AT3 victims simultaneously.
Who should act: if you run a large network, a hosting environment, or a scrubbing center, this is the difference between covering every affected prefix during a burst event and running out of slots partway through.
Important dependency: devices report their supported limits, but only rWeb 9.6 and later read them correctly. On earlier rWeb, the device is still assumed to support 64 prefixes and you will not get the benefit. If you are running RIOS 8.8.0, confirm your rWeb version.
RIOS 8.6.0: IPFIX export for interface visibility
What do you do when the attack is larger than your link? Every in-line deployment hits this limitation eventually.
In-line filtering handles the attack traffic, but it cannot manufacture bandwidth. If the flood saturates the upstream link, the packets never reach the filter, and no amount of mitigation capacity changes that.
Seeing it coming is the first requirement and so RIOS 8.6 added IPFIX support, allowing RIOS devices to export sampled flow data from their interfaces to a monitoring system such as RioRey Director. This provides visibility into interface congestion and traffic conditions at the point where saturation occurs.
That visibility is fed to Director where it is used to detect the condition and steer traffic off-ramp, to a RIOS device for filtering, or to cloud scrubbing, before the link is the thing that fails.
Who should act: any in-line operator whose upstream capacity is smaller than the attacks they expect to see. Which, at some volume, is everyone.
RIOS 8.7.2: SNMP HOST-RESOURCES-MIB
SNMP reporting now exposes all elements of the HOST-RESOURCES-MIB. If you pull RIOS device health into an external monitoring system, you have more to work with.
RIOS 8.8.0: DPDK driver updates
Routine. RIOS uses DPDK as its interface to the network hardware, and we track upstream releases for fixes and useful features. No configuration change, no action required.
We are including it here because the honest version of "here is what we shipped" includes the parts that do not matter to you. This layer has been stable for us and we rarely need to touch it.
RIOS 8.8.0: Improved power management
Many data centers now impose power constraints, and in general power has become more expensive. This build optimizes for much lower power consumption for mostly-idle links, helping reduce RioRey operating costs even further.