On-Premise DDoS Mitigation for Regional ISPs on Constrained Budgets

Most published guidance on DDoS mitigation is written for operators whose revenue per subscriber can absorb a Western European price list. If you run a regional ISP or a hosting business in Eastern Europe, the Caucasus or Central Asia, the arithmetic is different in a way that no amount of architectural elegance fixes. Your attack profile may look much like a Western operator’s; your revenue per subscriber does not. A design that is correct in Frankfurt can be financially unserviceable in a city where the same subscriber pays a fraction of the monthly fee.

The usual response to that gap is to buy a smaller version of the same thing. That is frequently the wrong move, because the cheapest element of a mitigation programme is not hardware at all, and because the most dangerous cost in a small operator’s budget is not the purchase price but the renewal that follows it in someone else’s currency.

This article takes the economics honestly. It covers what you can do with no capital, when the correct decision is to buy nothing on premise, how to stage capacity so that growth costs a licence rather than a chassis, where used equipment is sensible and where it is not, the currency exposure hiding inside a foreign-denominated support contract, and the point at which protection stops being a cost centre and becomes a margin line. The engineering sequence for actually building the thing is a separate subject, covered in the scrubbing centre build guide; the general cost argument for on-premise mitigation is made in the total cost of ownership guide and is not repeated here.

Start with what attacks already cost you

Before any option can be priced, you need to know what the current situation costs, and most small operators have never assembled that number. It is not one line in the ledger; it is four, and all four are recoverable from records you already hold.

Transit cost attributable to attack traffic. If any of your transit is billed on a percentile of measured throughput, flood traffic that crosses your ports is billed to you whether or not it reaches its target. Pull the samples around the incidents you remember and see whether they moved the billing percentile.

Engineer hours. Count the hours booked to attack triage over the last twelve months, including out-of-hours callouts, and convert them at a rate your finance colleagues already recognise. In a small operator this is usually a senior engineer who is also the person responsible for the projects that did not get finished.

Customer credits and churn. Service credits are visible. Churn is harder, but if you lost a hosting customer within a month of an incident that took their service down, that is a data point, and a handful of them is a business case.

Collateral outage. The attacks that cost the most are rarely the ones aimed at your biggest customer. They are the ones that saturated a shared port and took out everyone behind it. Count those separately, because they are the events that justify spending.

Everything that follows is a comparison against that baseline. If the four numbers together are small, the honest conclusion is that you should not be buying an appliance this year, and saying so internally is more valuable than a business case built on ambition.

The tier that costs no capital

There is a set of measures that requires engineering time and a working relationship with your upstream providers, and nothing else. It is not a substitute for mitigation, but it is a permanent floor beneath whatever you build later, and it is where an operator with no budget should spend the next quarter.

Get the prerequisites in place. If you do not have your own AS number and provider-independent address space from your regional internet registry, you cannot announce a blackhole route, cannot divert a prefix, and cannot sell protection to anyone. The cost of registry membership is small next to any hardware, and it unlocks every option below. This is the single highest-leverage item on the list for operators who are still using addresses assigned by their transit provider.

Agree remote-triggered blackholing with every upstream, in writing, before you need it. Destination-based RTBH lets you announce a route that instructs your provider to discard all traffic toward a given destination at their edge, so the flood never reaches your ports. RFC 5635 documents the mechanism, including the source-based variant that depends on unicast reverse-path forwarding, and RFC 7999 defines a well-known community for the purpose. What you need from each provider is specific and worth collecting during contract negotiation rather than during an incident: which communities they accept, the longest prefix they will honour for a blackhole announcement, how quickly the announcement takes effect, and how they will verify your identity if you have to phone them.

Be clear about what RTBH is. It is not protection; it is a controlled forfeit. You complete the denial of service against the target in order to protect everyone else behind the same ports. For a residential access network that is often exactly the right trade. For a hosting customer paying you to stay reachable, it is the outcome they are paying to avoid — which is precisely why hosting revenue changes the calculation.

Ask what else your upstream will do. Beyond blackholing, provider capability varies enormously and is rarely advertised to small customers. Some transit providers publish communities for geographic or protocol-level filtering, or for diverting your traffic into their own scrubbing service. Some will accept a limited set of BGP FlowSpec rules from customers, though most will not; the validation procedure in RFC 8955 and the hardware rule limits behind it make inter-AS FlowSpec fragile, and the universal primitive facing upstream remains RTBH. Ask for the list, in writing, per provider. Buying filtering from a provider you already pay is usually the cheapest mitigation capacity available to a small operator, and it is frequently cheaper than the same capacity from a specialist because it rides on transit you are already buying.

Stop being a source. Source-address spoofing is what makes reflection and amplification attacks work, and ingress filtering at the customer edge is the countermeasure: RFC 2827 (BCP 38) states the principle, and RFC 3704 (BCP 84) covers the multihomed cases where strict reverse-path checks break because traffic is asymmetric. This costs configuration time on access routers, not money. It does not protect you directly; it protects everyone else, and it keeps your address space out of the reputation systems that your customers’ counterparties consult.

Close the reflectors on your own network. Open recursive resolvers, exposed NTP, memcached, SSDP and similar services on subscriber and hosting address space are amplifiers that will be used against third parties, generating abuse reports, transit cost and, in the worst case, retaliatory traffic aimed at you. RFC 5358 (BCP 140) covers the recursive nameserver case specifically. Scanning your own space for these is a scripting task, and the remediation is usually a filter on the access network.

Reduce what is exposed. Management interfaces on routers, switches, CPE and the OSS itself should not be reachable from the internet. Attackers do not have to flood a control plane that they can reach directly. This is the least glamorous item here and the one that most often turns out to have mattered.

Use FlowSpec inside your own AS. If your existing edge routers support it, RFC 8955 for IPv4 and RFC 8956 for IPv6 give you the ability to push match-and-drop rules to hardware you already own. This is capacity you have already paid for. Operate it with a hard cap on the number of rules, automatic expiry on every rule, and a record of what is currently installed — a badly written rule propagates across your edge in seconds.

Sometimes the correct answer is to buy nothing

There is a ceiling above which on-premise equipment cannot help you, and for a small operator it is often lower than the attacks being discussed in the trade press.

That physical limit interacts with the economics in a specific way. If your total external capacity is modest, the range in which an on-premise device is the deciding factor is correspondingly narrow — wide enough to cover state-exhaustion attacks, application-layer floods and the sub-saturating volumetric traffic that makes up most incidents, but not wide enough to justify an appliance if those incidents are rare and cost you little.

So the case for buying nothing on premise is real, and it holds when several conditions coincide: your subscriber base is largely residential, you host little or nothing that customers pay to keep reachable, incidents are infrequent and short, blackholing an affected address is commercially acceptable, and your upstream will sell you filtering at a price that fits your revenue. Under those conditions the correct plan is the no-capital tier plus a written escalation procedure with your transit providers, and the appliance decision is deferred until something changes.

What usually changes it is hosted services. The moment a meaningful share of revenue comes from customers who are paying for reachability, RTBH stops being an acceptable answer, because using it means delivering exactly the outcome the customer bought protection against. Selective filtering that keeps the customer online is a different product from dropping the customer, and it is the product you can charge for.

Staged capacity: buy for today’s peering, grow by licence

The classic mistake in a constrained budget is the opposite of overspending. It is buying a platform sized for the network you hope to have in five years, on the assumption that this avoids a second purchase — and thereby spending capital today on capacity that sits idle while the renewal on it recurs every year regardless.

The alternative is to size against what your edge can deliver now, and to make growth a licence transaction rather than a hardware transaction. This only works if you establish three things before you sign.

Does inspection capacity rise on the same chassis? Ask directly whether the platform’s throughput and packet-rate limits can be raised by licence without replacing hardware, and what the ceiling of that path is. A platform with no licence path means every capacity increase is a new purchase, new installation risk and a new maintenance window.

What does each step cost, and is that price fixed now? This is the part that gets skipped. A licence path that exists technically but is priced at the moment you need it leaves you negotiating from a position where the alternative is replacing the device you just installed. Get the steps and their prices into the original contract.

Is the physical envelope adequate for the whole path? Licensed capacity is useless if the chassis cannot hold the interfaces you will need at that capacity, or if the power and cooling in your facility cannot support it. Check the interface options and the power envelope for the top of the licence path, not just for the entry point.

There is a related sizing point that is easy to get wrong on a small budget. Bit rate alone is a misleading specification, because small-packet attacks hit the packet-processing limit long before the bit-rate limit. Ask for the packet-rate figure in writing and run acceptance testing at the smallest packet size, not at a size that flatters the datasheet. An appliance that meets its advertised gigabits and collapses at your real packet rate has cost you the whole budget and solved nothing.

Where used and previous-generation hardware makes sense

The used market is not uniformly a trap, but it is a different proposition depending on which part of the estate you are buying.

Passive optical taps, transceivers, patching and transport switching carry no software entitlement, have long service lives and fail in ways that are obvious and cheap to diagnose. Buying these second-hand is ordinary procurement, and for an operator building out a monitoring path it is a legitimate saving.

The mitigation engine is a different case, because most of what you are buying is not the metal. It is detection logic, ongoing software maintenance and the right to receive both.

Four questions decide it, and all four should be answered before money moves.

Does the entitlement transfer? Whether support and software licences follow the physical unit to a second owner is vendor policy, and there is no universal answer. Establish it in writing with the vendor — not with the seller — before purchase.

How long will the platform receive security updates? A mitigation device is an internet-facing system with a control plane. Running one that no longer receives security patches is a poor trade even at zero purchase price. Ask for the published end-of-support date and compare it against the period over which you expect the device to pay for itself.

Does that generation reach your packet rate? Older platforms are frequently adequate on bit rate and inadequate on packet rate, which is the dimension that actually matters for the attacks you are buying protection against.

What does it cost to run? Take the throughput and the power draw from the datasheets of both generations and compute the ratio yourself. In a facility billed by the amp, an older unit can consume its purchase-price advantage over a few years, and the comparison is arithmetic you can do before you commit.

There is one use of the used market that is unambiguously sensible for a small operator: buying a second identical unit as a cold spare. It reduces your dependence on an RMA process that may be slow to reach your country, it costs a fraction of a support tier that promises fast replacement, and it does not depend on entitlement transferring, because the spare inherits the role of a unit you already own.

Currency: the renewal you signed is not the renewal you pay

This is the exposure that most damages small operators in the region, and it is almost never discussed as a technical decision, because it is not one.

The structure of the problem is simple. Capital cost is paid once, at a rate you know on the day. Support and licence renewals recur annually, are usually denominated in the vendor’s currency, and are paid out of revenue denominated in yours. Between two renewals, a currency movement raises the real cost of the contract in local terms without any change whatsoever in the service delivered. Over a five-year ownership period, the recurring foreign-currency line can move a great deal relative to the local-currency revenue that funds it — and unlike transit, it is not a cost you can renegotiate downward by shopping around, because it is attached to hardware you have already installed.

Several levers exist, and they are negotiable at the point of purchase in a way they are not afterwards.

• Ask to be invoiced in local currency. Some vendors and most local resellers can do this. It moves the exposure to them, which is where a party with a treasury function should carry it.
• Ask for a rate cap or a fixed multi-year support price. A ceiling on the renewal in local terms converts an open exposure into a bounded one.
• Consider prepaying a longer support term. This converts several future exposures into one at today’s rate. The trade-off is real: it consumes cash a small operator may need elsewhere, and it prepays for support on a device you might replace.
• Price the whole landed cost, not the invoice. Import duty, VAT treatment, customs clearance and the freight on an RMA are part of the cost of owning foreign hardware, and in several jurisdictions in the region they are a material addition rather than a rounding error.
• Confirm a payment route exists and is likely to persist. The ability to actually settle an invoice with a foreign vendor is not a given everywhere in the region, and a support contract you cannot pay is a support contract you do not have.

The general principle worth carrying into the negotiation: a purchase converts a recurring foreign-currency exposure into one large exposure today plus a smaller recurring one, while a subscription-priced service leaves the entire cost recurring and exposed. That asymmetry is a legitimate argument for owning equipment rather than renting capacity, and it is one that a finance director in a soft-currency economy will understand faster than any architectural argument you can make.

When protection becomes a margin line

Everything above treats mitigation as a cost to be minimised. The decision changes character entirely at the point where the same hardware carries paying tenants, because an appliance bought as insurance runs at zero utilisation while an appliance carrying customers has a payback schedule.

Three capabilities separate a device that improves your network hygiene from a device you can invoice against, and they are worth treating as procurement criteria rather than features.

Per-tenant policy. Every customer’s normal is different. A game hosting customer’s UDP profile cannot be governed by the thresholds that suit a customer whose traffic is almost entirely TCP on port 443. You need separate baselines, thresholds, countermeasure ordering and whitelists per customer on shared hardware, driven by templates rather than by fifty hand-written configurations.

Per-tenant isolation. An attack aimed at one tenant must not degrade the protection of the others by consuming shared session table, rule capacity or processing resource. The question to ask a vendor is not how many tenants are supported but how one tenant can affect another.

Per-tenant reporting. The customer never sees your mitigation engine. They see your portal. A readable report showing what was stopped is more persuasive at renewal than any technical property of the engine, and it is the document the customer will use in their own audits. For technical customers, an API that lets them pull the data into their own monitoring is a purchase criterion in its own right.

Those three criteria, plus a licence path that grows capacity without a new chassis and detection that runs on the device rather than depending on a vendor cloud you may not be able to reach or pay for, are a usable specification for a constrained-budget operator. Appliances meeting that combination exist, but the criteria are what should decide the tender, and each of them should be demonstrated in a proof of concept on your own traffic rather than accepted from a datasheet. The buyer’s guide for ISPs and telecom operators develops the full specification; the commercial packaging, pricing axes and SLA wording are covered in the scrubbing centre build guide.

One warning belongs here rather than in the commercial section, because it is the mistake that most often destroys the economics of a first deployment. Never advertise a protection level above your own edge capacity. If the number in your marketing exceeds what your transit and peering ports can physically deliver, an attack of that size fills those ports before it reaches your appliance, every customer behind them is affected, and under percentile-based transit billing the attack traffic arrives on your own invoice. Publish a ceiling derived from your real edge and transport capacity, and write into the contract what happens above it. A declared blackhole threshold is a sign of maturity, not weakness.

Appliance	Upstream only, no capital	Staged on-premise	Used or previous-generation
Capital outlay	None beyond engineer time and RIR membership	One chassis, sized to today's peering	Lower purchase price, unknown remaining service life
Recurring cost	Whatever your transit provider charges for filtering	Support and licence renewal, usually in a foreign currency	Support renewal only if the vendor will sell it to a second owner
What it stops	Volumetric floods, at the price of dropping the target with them	Everything below your edge capacity, without dropping the customer	The same, if the platform is still receiving software updates
What it cannot stop	Nothing selectively — blackholing is not filtering	Anything that saturates your transit or peering ports	Anything the packet-rate ceiling of that generation cannot reach
Currency exposure	Limited, and usually inside your existing transit contract	Annual, and unhedged unless you negotiate it	Same annual exposure, on an asset with a shorter remaining life
Can you resell it	Only what your upstream lets you resell	Yes, if the platform supports per-tenant policy and reporting	Only if the entitlement transfers and reporting is per-tenant
Main failure mode	The customer under attack goes dark and blames you	Selling more protection than your edge can physically deliver	End of software support arrives before the payback does

These are not three rungs of a ladder — the first column is a permanent floor. Whichever of the other two you choose, the no-capital measures stay in place, because they are what you fall back to when an attack exceeds your edge.

A worked example, to be re-derived with your own numbers

The following is an illustrative worked example using placeholder figures. The numbers are invented for the purpose of showing the shape of the calculation; none of them are observed values, and the exercise is worthless unless you substitute your own.

Suppose an operator establishes, from the four measurements above, that attacks currently cost them an annualised total made up of: additional transit billed at the percentile, engineer hours at their internal rate, service credits issued, and one hosting customer lost per year. Call that total A.

Suppose the appliance option has a capital cost C, amortised over an expected ownership period of n years, plus an annual support and licence renewal R denominated in a foreign currency. The naive comparison is whether A > C/n + R. It is naive for three reasons, all of which matter more in a soft-currency economy than in a hard-currency one.

First, R is not constant in local terms. Model it at the current rate and again at a materially weaker local rate, and see whether the decision survives both. If it only works at today’s rate, you have not made a decision, you have made a bet.

Second, C/n understates the cost if the platform reaches its capacity ceiling before year n. If your peering is growing, either the licence path covers that growth at a known price or n is shorter than you assumed.

Third, and in the other direction, A is the wrong figure entirely if you intend to sell protection. The correct comparison then includes the contribution from tenants, and the question becomes how many paying tenants are required for the deployment to break even — which is a number your sales team can be held to, unlike a projection of attack frequency.

Run all three variants. If the purchase only survives the most optimistic one, the honest recommendation is the no-capital tier for another year.

What to ask before signing

A short list, drawn from the arguments above, that can be lifted into a tender or a supplier conversation.

1. What is the ceiling of the licence path on this chassis, what are the steps, and what does each step cost — with those prices fixed in this contract?
2. What is the packet-rate figure, in writing, and will you support acceptance testing at the smallest packet size on our traffic?
3. Will you invoice in our currency, or cap the exchange rate, or fix the support price for a multi-year term?
4. What is the published end-of-support date for this platform, and what is your policy on transferring support and licences to a second owner?
5. Does detection run entirely on the device, and what specifically degrades if the device cannot reach your infrastructure?
6. Can we demonstrate per-tenant policy, per-tenant isolation and per-tenant reporting in a proof of concept, using our own traffic and our own customers’ profiles?
7. What is the power draw and the interface capacity at the top of the licence path, not at the entry point?

The answers to those seven questions determine whether a purchase is a staged investment or a fixed liability in someone else’s currency. The cloud, on-premise and hybrid comparison sets out the architectural trade-offs that sit behind the same decision.

The order that actually works

For an operator starting from nothing, the sequence is not the same as the sequence for an operator with capital available.

Secure the prerequisites — registry membership, your own AS number and address space — because they cost the least and unlock the most. Put the no-capital tier in place and keep it in place permanently, because it is the floor you fall back to when an attack exceeds whatever you build later. Measure what attacks actually cost you, in four lines, over a year. Buy filtering from your upstream if they will sell it, because capacity riding on transit you already pay for is usually the cheapest capacity available to you. Only then consider hardware, sized against the edge you have today, with a priced licence path to the edge you expect, and a currency exposure you have negotiated rather than accepted. And when you do buy it, buy a platform you can put tenants on, because that is the difference between a cost you defend annually and a line that contributes.

The uncomfortable conclusion is the one worth stating plainly: for a genuine subset of regional operators, the right answer this year is to do nothing on premise, do the free work properly, and revisit the decision when hosted revenue makes forfeiting a target commercially unacceptable. A vendor will not tell you that. It is nonetheless sometimes true, and an operator who spends a constrained budget on the wrong year of this decision does not get a second attempt at it.

Sources and further reading

The documents below are the standards and operational references that belong on the table during this decision. No figures are attributed to them here; the only arithmetic in this article is the labelled worked example, which must be re-derived from your own measurements.

Blackholing and upstream signalling. Remote-triggered black hole filtering, including the source-based variant that relies on unicast reverse-path forwarding, is described in RFC 5635; the destination-based method in RFC 3882; and the well-known BLACKHOLE community in RFC 7999. General BGP operations and security guidance is RFC 7454 (BCP 194).

Source address validation. Ingress filtering to defeat source-address spoofing is RFC 2827 (BCP 38), and the multihomed and asymmetric cases are covered in RFC 3704 (BCP 84). NIST SP 800-189 provides an institutional framing for teams that need one, and MANRS expresses the same obligations as operator commitments.

FlowSpec. Dissemination of flow specification rules is RFC 8955 for IPv4 and RFC 8956 for IPv6. The rule validation procedure and the defined action set are in those texts; which subset your own line cards implement in hardware is a question for your platform vendor.

Reflection and amplification. RFC 5358 (BCP 140) covers preventing the use of recursive nameservers in reflector attacks. RFC 4732 is an informational overview of denial-of-service considerations in internet protocol design.

Routing security. The RPKI architecture is RFC 6480, the ROA format RFC 6482, origin validation RFC 6811, and guidance on maxLength values RFC 9319 (BCP 185). If you plan to announce a longer prefix during diversion, your ROAs must permit it, or the announcement you need most will be invalid exactly when you make it.

Standardised mitigation signalling. DOTS defines a vendor-neutral way for a customer device to request mitigation from your layer: architecture in RFC 8811, signal channel in RFC 9132 and data channel in RFC 8783.

Commercial documents to request rather than cite. Ask each transit provider for their written community list, accepted blackhole prefix lengths and committed response times; ask each shortlisted vendor for published end-of-support dates, the licence-path price schedule and their second-owner transfer policy. Analyst subscriptions publish market overviews of this segment, and if your organisation holds one, request the current document rather than relying on a summary of it.