DDoS Protection in an Operator Network: Selection Criteria

The decision to deploy DDoS protection is rarely made in calm conditions. It is usually preceded by an incident: an attack that clogged the link or paralyzed customer service for several hours. Under time pressure, it is easy to make a choice driven more by the vendor's marketing materials than by the network's real needs. The result is sometimes a system that looks good in the offer but does not fit the operator's architecture or generates costs nobody expected.

Below we have compiled the criteria worth checking before making a decision, and we show how LiveShield measures up against them.

The first question worth asking is where traffic analysis and filtering actually take place. Some solutions work on-premise, directly in the operator's infrastructure: all traffic stays in the network, and filtering decisions are made locally. Others redirect traffic outside, to a scrubbing center managed by the vendor.

The difference is not only architectural. Redirecting traffic means additional latency, dependence on the availability of an external service, and a transfer cost that can come as a surprise during a large volumetric attack.

LiveShield is designed as an on-premise system: installed directly in the operator's infrastructure, without redirecting traffic outside. Analysis and mitigation take place locally, which eliminates additional latency and dependence on an external service, and traffic remains under the operator's control at all times.

An anti-DDoS system that does not integrate natively with your BGP is a system that requires additional integration work. It is worth checking whether the solution has its own BGP daemon or depends on external software, and whether it supports both BGP FlowSpec and RTBH (remotely triggered blackholing).

FlowSpec allows precise, granular filtering rules announced directly to edge routers, without manual ACL configuration. Blackholing is a simpler, blunter mechanism, effective when an attacked address must be cut off immediately at the cost of its complete unavailability.

LiveShield has its own BGP daemon and supports both mechanisms, FlowSpec and selective RTBH, choosing the appropriate one depending on the nature of the attack, with no need for manual configuration on the operator's side. The solution has been tested on hardware that most ISPs in Poland work with: Juniper routers (MX, PTX) and Cisco (ASR1k, ASR9k, NCS5500 in SE variants, 8000 series). This is not a declaration of compliance with the standard "on paper"; it is a list of hardware on which the configuration was actually verified.

Classic detection focused on a single IP address copes well with a simple volumetric attack, but gets lost with carpet bombing attacks, spread across many addresses or an entire subnet at once, where traffic to each individual IP looks harmless on its own. This is an increasingly common vector because it effectively bypasses mechanisms designed for a single target.

LiveShield detects attacks both per-IP and per-subnet, automatically aggregating attacks spread across many addresses into one, as narrow as possible, filtering rule, so as to limit the impact on traffic that is not part of the attack. An anti-overload mechanism additionally protects the detection system itself from overload at a large scale of simultaneous incidents.

Operators subject to the National Cybersecurity System act are required to report a serious incident to the relevant CSIRT in three stages: an early warning within 24 hours of detection, a full notification within 72 hours, and a final report within a month of the notification. In practice this means that during an attack someone must simultaneously respond operationally and prepare documentation compliant with these deadlines.

LiveShield's reporting module generates a ready summary of attack data (duration, vector, scale, mitigation actions taken) in a form that can be used immediately when preparing a notification to the CSIRT. This genuinely shortens the time needed for documentation in the 24-hour window, when every hour counts.

It is worth naming this honestly, however: a module that supplies data for a report is not the same as a ready-made compliance tool. The final assessment of compliance with the KSC and the preparation of the notification remain with the operator. LiveShield relieves the team at a critical moment but does not replace regulatory responsibility.

The next question is what the system is actually supposed to run on. Some solutions require a dedicated, closed appliance, which means a rigid entry cost and no flexibility when scaling. Others run on standard server hardware, provided it meets certain minimums.

LiveShield runs on standard x86 hardware supporting DPDK, with no need to invest in a dedicated appliance. The module responsible for real-time packet processing (Worker) requires a physical machine; it is the only component with such a requirement. The other two modules, Manager and Analyser, can run virtually, which makes it easier to fit the deployment to the infrastructure the operator already has.

Indicative hardware minimum: number of physical cores calculated from the formula Gbps ÷ 10 + 4 (no fewer than 8 cores), 32 GB+ RAM, NVMe disk from 60 GB and a DPDK-compatible network card. Recommended models are Intel X710, XXV710, E810 or X520, or possibly Mellanox ConnectX cards. Zero dependence on a single hardware vendor.

Billing models differ greatly between vendors. Some bill by network throughput: one parameter, one price, all features included. Others use modular licensing, where advanced filtering, FlowSpec support or reporting are separate cost items, bought separately.

The LiveShield license is tied solely to incoming traffic (Gbps), with no division into modules and no additional fees for FlowSpec, advanced filtering or reporting. The full functionality of the system fits in one price, which makes it easier to predict costs as network traffic grows.

The last, often overlooked element is what happens after the contract is signed. Does the vendor offer consultations during a self-run deployment? Is it possible to test the solution before purchase, on real traffic? What does response time to technical questions look like in practice, especially those asked during the first configuration of detection thresholds, when wrong settings can mean false alarms or, worse, a missed attack?

Included in the LiveShield license price, we offer free consultations during deployment and verification of the configuration's correctness by our engineer. A demo license is also available for testing the system on real traffic before the purchase decision.

Before making a decision, it is worth having an answer to each of the following questions:

To each of these questions LiveShield has a concrete, verifiable answer, and not just a declaration of compliance with the standard.

Full technical documentation: docs.liveshield.net.
Technical questions: office@liveshield.net