Cybersecurity Cooperation Across the Turkic States: The DDoS Layer

Regional cybersecurity cooperation tends to be discussed at a level of abstraction where it is impossible to be wrong. Working groups are announced, capability-building is welcomed, and information exchange is agreed in principle. None of this is objectionable, and none of it changes what happens at four in the morning when an operator in one country is absorbing a flood sourced from, or transiting through, another.

The gap between those two things is narrower and more specific than it looks. It is not a gap in willingness or in legal authority. It is a gap in interfaces. Cooperation on denial-of-service defence becomes operational at exactly the point where one party can send another a request that the receiving side’s equipment understands without a human translating it — and it stays declaratory until then.

This guide is about that interface. It is written for the people in Azerbaijan, Kazakhstan, Uzbekistan, Kyrgyzstan and Türkiye who would have to build it: network operators, national incident responders, and the procurement officials whose tender documents quietly determine what is possible five years later. The political framing is somebody else’s work. What follows is the engineering.

Four workstreams, in ascending order of difficulty

Anything worth calling cooperation at this layer decomposes into four pieces, and it is worth being honest about which are easy.

Shared threat signalling between national teams — structured, perishable, machine-readable observations about attacks in progress. This is the easiest, because it requires no change to anybody’s network and no delegation of authority.

A standardised mitigation-request interface, so that an operator can ask an upstream or a peer in another country for help in a format both implement. Harder, because it requires agreement on protocol, authentication and scope — but it is a bounded engineering problem with existing specifications.

Joint exercises that test the above under conditions resembling an incident. Harder still, because exercises expose the parts that were assumed rather than built.

Common procurement criteria, so that five markets buying independently do not converge on a single supplier and a single foreign legal regime by accident. Hardest, because it touches budgets and incumbency — and the one with the longest-lasting effect.

The ordering matters. The second item is load-bearing for the first and third: a signal that cannot be acted upon is a newsletter, and an exercise with no interface to exercise is a tabletop discussion.

Appliance	DOTS signal channel	DOTS data channel	BGP FlowSpec	RTBH
What it expresses	"Help me protect this target"	Pre-agreed aliases and filter rules	"Drop or rate-limit flows matching this n-tuple"	"Discard everything to this address"
Specification	RFC 9132, architecture in RFC 8811	RFC 8783	RFC 8955 (IPv4), RFC 8956 (IPv6)	RFC 5635
Transport	CoAP over DTLS, or TLS over TCP	RESTCONF over TLS	BGP, as a distinct address family	BGP, as an ordinary route with a community
When it is used	During the attack	Before the attack	During the attack	During the attack
Who decides the countermeasure	The receiving side	Agreed in advance	The requesting side, within accepted limits	The receiving side, bluntly
Realistic cross-border posture	The right channel to standardise on	Provisioning step for the above	Rarely accepted between operators	Widely accepted, widely destructive
Collateral effect	None inherently — it is a request	None	Confined to matching flows	Completes the outage for the target

Columns are mechanisms, not products. The two DOTS channels are complementary rather than alternatives: the data channel provisions what the signal channel later refers to by name, which is why the provisioning work has to happen on a quiet day.

Why the interface has to come first

Consider what a cross-border mitigation request actually needs in order to work. Three things have to be true simultaneously.

The request must be unambiguous. “We are under attack, please help” is not actionable. A useful request names the target prefix, the transport protocol, the port range, the direction and a lifetime after which the request expires on its own.

The request must be authenticated and scoped. The receiving side is being asked to discard traffic. It needs cryptographic assurance of who is asking, and it needs to know that the requester is entitled to ask about that particular prefix — otherwise the mechanism becomes an attack in its own right.

The request must survive the conditions that produced it. A signalling channel that fails when the link is congested is useless precisely when it is needed, which rules out anything built on the assumption of a healthy path.

These are not novel requirements, and they have been worked through in public. The result is DOTS.

DOTS: what a mitigation request actually contains

DOTS — DDoS Open Threat Signaling — is the standardised way for one organisation to ask another for mitigation. Its architecture is RFC 8811; the requirements that shaped it are RFC 8612. The part that matters operationally is split across two channels, and the split is the design’s most useful feature.

The signal channel, RFC 9132, is the one used during an attack. It runs CoAP over DTLS — or TLS over TCP where a datagram transport is impractical — and it is deliberately small. Messages are compact, sessions are resumable, and the protocol expects to operate over a path that is degraded, lossy or partially saturated. A DOTS client and server maintain heartbeats so that each knows the other is reachable before anything goes wrong, which means the session is established on a quiet day rather than negotiated in the middle of a flood.

A mitigation request carried on that channel expresses the scope directly: one or more target prefixes, a target protocol, a target port range, optionally a target FQDN or URI, and a lifetime. It can also refer to an alias — a named bundle of targets provisioned earlier — which is what keeps the urgent message short. The requester sets a lifetime because a request that never expires is an operational hazard; the mitigation withdraws itself unless refreshed.

Two return paths matter. The server reports mitigation status back to the client, so the requester knows whether the request was accepted, is active, or was refused. The client sends efficacy updates in the other direction, reporting whether the attack traffic actually subsided. That second path is the one most proprietary integrations omit, and it is the one that turns a fire-and-forget request into a control loop.

The data channel, RFC 8783, runs RESTCONF over TLS and is explicitly not for use during an attack. It is where aliases are defined, where standing filter rules are provisioned, and where the relationship is configured. This division is the point: everything that requires deliberation happens in advance, so that the message sent under pressure is short, typed and unambiguous.

There is also a telemetry extension, RFC 9244, which allows a client to convey baseline traffic levels, pipe capacity and attack characteristics alongside the request. In a cross-border context this is more valuable than it first appears — it lets the receiving side distinguish “this operator’s 10 Gbps circuit is saturated” from “this operator has spare capacity but wants a specific vector filtered”, which are different requests deserving different responses.

One honest caveat, repeated because it matters for planning: field adoption of DOTS remains limited. Most commercial mitigation services still expose a proprietary API. That is an argument for writing DOTS into tenders now, not an argument for waiting.

FlowSpec: the enforcement side, and its ceiling

DOTS is how the request is made. BGP FlowSpec is one of the ways the answer is enforced.

FlowSpec, specified in RFC 8955 for IPv4 and RFC 8956 for IPv6, distributes n-tuple match rules over BGP as a distinct address family. A rule can match on destination and source prefix, IP protocol, source and destination port, ICMP type and code, TCP flags, packet length, DSCP and fragment state. Actions are carried as extended communities: rate limiting, with a rate of zero acting as a discard; redirection to a VRF for further inspection; and traffic marking. Compared with dropping an entire destination address, this is surgical.

Two constraints keep it from being the whole answer, and both are worth stating plainly because they shape what a regional arrangement can realistically promise.

Rule capacity is finite and platform-specific. FlowSpec rules consume hardware resources on every router that installs them. The usable number varies by an order of magnitude across platforms, and it is not a number vendors volunteer. Any design that assumes thousands of simultaneous rules should be verified against the actual line cards involved before it is written into a procedure.

Inter-AS acceptance is the exception, not the rule. The validation procedure in RFC 8955 ties a flow specification to the neighbour from which the best-match unicast route for the destination prefix was learned — a sensible safeguard, and one that constrains what a peer in another country can legitimately originate. Beyond the specification, operators are understandably reluctant to accept instructions to discard traffic on their own networks. Where an upstream does accept something from a customer, it is frequently only a destination prefix with a discard action, which is remotely triggered blackholing (RFC 5635) under another name.

The practical posture, therefore, is the same one that applies domestically: run FlowSpec inside your own autonomous system, where you control the policy and the hardware; use DOTS as the channel across the boundary, where the receiving side decides how to implement the request using whatever mechanism it prefers. That division of labour is what makes the cross-border case tractable at all — the requester describes the problem, the responder chooses the countermeasure.

Where a cross-border request would actually land

Two structural facts make this more feasible in this region than the geography suggests.

The first is that the five markets sit in a common regional internet registry service region, administered by the RIPE NCC. This is not a diplomatic arrangement; it is an existing operational reality, and it has concrete consequences. There is one authoritative routing registry to consult, one RPKI trust anchor hierarchy for route origin validation, and one set of database objects describing who holds which resources. The single hardest problem in any cross-border filtering arrangement — establishing that the party asking about a prefix is entitled to ask — is already partly solved by infrastructure that exists and that every one of these operators already uses. RPKI origin validation, specified in RFC 6811 over the architecture in RFC 6480, is the same tooling that would underpin the entitlement check in a DOTS relationship.

The second is that transit topology, not geography, determines where help is useful. A substantial share of traffic between these markets does not travel directly; it transits carriers and exchange points outside the region. This cuts both ways. It means that a bilateral arrangement between two national teams may have no effect on the path an attack actually takes, and it means that the most valuable cooperation is often not between the two countries involved but between each of them and the transit providers in the middle. A regional arrangement that ignores this will produce agreements that cannot be executed.

The constructive reading is that both regional interconnection and standardised signalling work on the same problem from different ends. More direct interconnection shortens the path that a mitigation request has to influence. Standardised signalling makes the request usable by whoever happens to be on that path — including parties outside the region who were never part of any agreement, which is the whole advantage of using a published specification rather than a private one.

Shared threat signalling: what is worth exchanging

The signalling workstream is the easiest to start and the easiest to get wrong, because it tends to drift towards completeness rather than usefulness.

The formats exist and are unglamorous. IODEF, RFC 7970, is the standard structured representation of an incident report between response teams. STIX and TAXII cover structured indicators and their transport, and the open-source MISP platform is widely used for operating a sharing community in practice. The Traffic Light Protocol maintained by FIRST is the established convention for marking how far a given item may travel. None of this needs to be invented; it needs to be chosen and then used.

What matters more is the editorial discipline about content. Material that belongs in a fast lane between national teams has three properties: it is machine-readable, it is perishable, and it is low-sensitivity. Prefixes currently under attack. Observed vectors, with the ports and protocols involved. Reflector and amplifier sources being used against targets in the region — which are frequently misconfigured hosts inside the region, making this the single most reciprocally useful category. Timing.

Attribution belongs in a different lane, and probably a slower one. It is the slowest item to produce, the most contested, and the least actionable inside the hour that matters. A technical channel that becomes a venue for attribution disagreements is a channel that stops being used.

The reciprocity problem deserves naming, because it is what quietly kills these arrangements. Sharing is asymmetric by construction: the team with the most sensors has the most to give and the least to gain, and after a while it stops giving. The mitigations are structural rather than moral — make the exchange automated so that participation costs nothing per incident, make the low-sensitivity categories the default rather than the exception, and ensure that the arrangement returns something to every participant regardless of what they contributed, such as visibility of amplifiers inside their own address space.

Exercises: test the parts nobody built

Exercises in this domain fail in a predictable way. The scenario is realistic, the participants are competent, the report is positive, and the capability tested is the one that already worked.

A useful joint exercise at this layer tests the things that are usually assumed:

That the channel has ever carried a real request. Not that it is configured — that a mitigation request has been sent, accepted, acted upon, reported back and withdrawn, end to end, with the efficacy update returned.

That it works out of hours. Almost every arrangement is validated during business hours in the capital. The relevant question is what happens at 03:00 on a public holiday, when the duty engineer has an escalation list rather than a relationship.

That authorisation is pre-granted. If the duty engineer must wake a director to authorise a request, the interface’s latency is measured in the director’s sleep, not in milliseconds. The exercise should establish whether standing authorisation exists within defined bounds — and if it does not, that is the finding.

That credentials and trust anchors are current. Certificates expire, contacts leave, keys rotate. A signalling relationship provisioned two years ago and never used is a relationship that will fail on first use. Regular use is the only reliable test, which is an argument for exercising quarterly rather than annually.

That withdrawal works. More incidents are prolonged by a mitigation nobody could turn off than by one that was never applied. Lifetimes, expiry and clean withdrawal are the least exciting and most operationally consequential thing to rehearse.

That the fallback path exists. When the automated channel fails — and it will — what replaces it, who is on the list, and in which language does that conversation happen. This is where contact lists earn their place: as the documented degraded mode, not as the primary interface.

Common procurement criteria, and collective supplier concentration

This is where a regional arrangement produces its most durable effect, and it works through a mechanism most cooperation frameworks miss.

Five states procuring independently, each shortlisting the vendors most active in their market, tend to converge on the same small set — because language, price, support geography and integrator relationships push in the same direction everywhere. The result is a bloc that has, without anyone deciding it, placed a large share of its defensive capability under a single foreign export-control regime. Every individual purchase was rational. The aggregate is a common-mode dependency.

The instinctive response — joint procurement — is the wrong tool if the goal is resilience. Aggregating volume lowers unit price while concentrating the dependency further. What travels well between states is the specification, not the award: a shared technical annex that every tender in the region can reuse, with each state contracting separately and, ideally, differently. Common criteria, separate contracts.

A regional annex worth reusing would require, at minimum:

1. DOTS support, citing RFC 8811 and RFC 9132, with the signal channel demonstrated during acceptance rather than asserted in a datasheet — and with RFC 8783 provisioning shown to work.
2. BGP FlowSpec support, citing RFC 8955 and RFC 8956, with a vendor-confirmed list of supported match and action types and a stated rule capacity for the specific hardware being sold.
3. A documented offline mode. What the product does, precisely, when it cannot reach the manufacturer for ninety days — tested during acceptance, not described in a meeting.
4. Local classification. Whether detection and policy decisions are made on the customer’s own hardware or depend on a manufacturer-operated intelligence cloud in the decision path.
5. Exportable telemetry in open formats, so that national aggregation does not require every participant to buy the same platform. IPFIX (RFC 7011) for flow export is the baseline.
6. Disclosure of the four legal mechanisms that reach the supplier: export licensing, sanctions exposure, extraterritorial data-access law and cloud dependency. Our vendor jurisdiction analysis sets out how to ask these in a form that produces documentary answers.

Criteria three and four are the ones that convert a procurement document into a resilience measure, because they determine whether a supply interruption is a degradation or an outage. An appliance that performs its full classification on the customer’s own hardware, with no manufacturer-operated cloud in the decision path, and that speaks DOTS and FlowSpec at its boundary rather than a proprietary protocol, satisfies both at once. Those two tests are worth applying to every candidate on any shortlist, because the difference only becomes visible on the day the link to the manufacturer stops working.

For buyers weighing the residency dimension alongside the supply-chain one, the Kazakh localisation analysis works through how the two interact in a single architecture decision.

A minimum viable arrangement

If the objective is a capability rather than a document, the sequence is roughly this, and it is deliberately short.

1. Agree the signalling stack. DOTS for mitigation requests; IODEF or STIX over an agreed transport for incident information; TLP for handling. Publish the choice so that vendors and operators can build to it.
2. Establish the trust plumbing. Certificate issuance and rotation for DOTS peers, and entitlement checks anchored in the routing registry and RPKI data that already exist for this service region.
3. Provision on quiet days. Aliases, standing filters and heartbeat relationships configured through the DOTS data channel before anything happens, because the signal channel is not where configuration belongs.
4. Write the annex. The six procurement criteria above, published as a reusable technical annex rather than a joint tender.
5. Exercise quarterly, in rotation. Each participant hosts, each exercise sends a real request through the real channel, and each produces a finding list rather than a communiqué.
6. Measure two numbers. Time from detection to a request reaching a party who can act, and time from that request to observed traffic reduction. Everything else in this domain is commentary on those two figures.

The honest limits

Three caveats, because an argument that produces only one conclusion is not an argument.

Standardisation does not create capacity. If nobody in the arrangement has scrubbing capacity meaningfully larger than the attacks being seen, a perfect signalling interface distributes the problem faster without solving it. Interoperability is a force multiplier on capacity that exists; it is not a substitute for it.

Most of the value is bilateral and unglamorous. The arrangements that will do the most work are between individual operators and their direct upstreams, and between operators and the exchange points they connect to. A regional framework helps by standardising what those relationships look like — it does not replace them, and a framework that tries to will be routed around.

The interface is a means, not a position. Adopting DOTS and FlowSpec commits nobody to anything except the ability to make and receive a request that the other side can parse. That modesty is a feature. It is why the recommendation here is technical rather than political, and why it remains sound regardless of how the surrounding arrangements evolve.

Sources and further reading

We do not paraphrase paywalled analyst research, and we do not describe legal or institutional arrangements we cannot cite.

Mitigation signalling. The DOTS architecture is RFC 8811 and the requirements that shaped it are RFC 8612. The signal channel — the part used during an attack — is RFC 9132; the data channel used for provisioning is RFC 8783. The telemetry extension is RFC 9244. Read RFC 9132 in full before writing a tender clause about it; the scoping attributes and lifetime semantics are the parts that determine whether an implementation is useful.

Routing-layer enforcement. BGP FlowSpec is RFC 8955 for IPv4 and RFC 8956 for IPv6; the validation procedure in RFC 8955 is the section that governs what is possible between autonomous systems. Remotely triggered black hole filtering is RFC 5635. General BGP operations security guidance is RFC 7454 (BCP 194).

Routing integrity as the trust substrate. The RPKI architecture is RFC 6480 and BGP prefix origin validation is RFC 6811. NIST SP 800-189 covers routing resilience for operators, and the MANRS initiative publishes the corresponding operational norms for network operators and IXPs.

Incident information exchange. IODEF version 2 is RFC 7970. The Traffic Light Protocol is maintained by FIRST, whose membership community and published standards are the usual starting point for a team building external relationships. MISP is the most widely used open-source platform for operating a sharing community, and STIX and TAXII, maintained by OASIS, are the common structured-indicator and transport formats.

Anti-spoofing and flow export. Network ingress filtering is RFC 2827 (BCP 38) and RFC 3704 (BCP 84) — the measures that reduce the reflector and amplifier population inside a participant’s own address space, which is the most reciprocally valuable contribution any participant can make. IPFIX, the flow export protocol, is RFC 7011.

Supply chain. NIST SP 800-161 remains the closest thing to a neutral reference framework for the procurement analysis above.