Planning a DDoS Test: What Must Be Agreed Before a Simulation?

Before a DDoS simulation, the objective, authorised systems, participating networks, traffic limits, test window, measurements and stop rules must be recorded in writing. Owning an application does not automatically grant authority over cloud, transit, CDN or third-party systems. Controlled test traffic should begin only after every affected operator has approved the specific scope.

First decide: exercise, load test or DDoS simulation?

Three formats answer different questions. A tabletop exercise walks through alerts, decisions and communications without adding network traffic. A functional acceptance test uses legitimate requests to check login, new and active sessions and reconnection. A load test generates expected or elevated legitimate traffic. A DDoS simulation, by contrast, deliberately attempts to trigger protection mechanisms with a controlled attack pattern. It therefore needs its own authorisation and must not be relabelled as an ordinary load test.

AWS: distinction between network stress tests and DDoS simulations

Owning an IP address is not complete authorisation

Planned traffic normally passes through systems operated by several parties. These may include the test provider, internet access networks, transit providers, DDoS mitigation, a CDN, cloud platform, data centre and the application itself. For every stage, identify the applicable terms and approvals. Microsoft, for example, permits Azure DDoS simulations only through approved testing partners and against particular owned, protected resources. AWS also defines approved partners, eligible target resources and technical limits. Those rules are provider-specific; their figures or permissions do not transfer to another network.

Microsoft Azure: test DDoS protection through authorised simulations

AWS: DDoS Simulation Testing Policy

• The service owner confirms which application they control may be tested and which business functions must be protected.
• The target resource owner confirms the exact IP addresses, prefixes, hostnames and accounts; shared or third-party targets remain excluded.
• Network, cloud, hosting, CDN and protection providers approve only the part for which their terms require approval.
• The test provider identifies its source networks, contacts and authority and accepts the agreed limits.
• A named test lead has authority to start, pause and stop; the other side confirms a contact who remains reachable throughout.

Authorisation should include the period, time zone, targets, sources, permitted test categories and maximum limits. This article is a technical planning aid, not legal advice. A product enquiry, trial account or ownership of a server is not on its own permission to run a DDoS simulation.

What belongs in the test sheet

• Objective and decision: which assumption is being tested, and which operational decision will use the result?
• Positive scope: exact target addresses, services, ports, protocols, IP versions and intended traffic paths.
• Negative scope: DNS, management access, shared platforms, partner APIs or any other system explicitly excluded from testing.
• Sources and generators: test provider, source prefixes and the organisation responsible for the traffic.
• Traffic envelope: permitted categories, stages, durations and limits for bit rate, packet rate, requests or connections, wherever relevant.
• Schedule: start, end, time zone, staged increase, hold points and reserved recovery time.
• Observation: network, protection and application metrics, clock synchronisation, log retention and analysis owners.
• Control: approval to start, communication channels, stop word, reachable contacts and the person with final decision authority.

A production network is not a neutral laboratory. RFC 6815 explicitly warns against using the isolated benchmarking methods in RFC 2544 on production networks because the procedures themselves can be disruptive. An agreed DDoS scenario is not an RFC 2544 benchmark, but the operational lesson still matters: methods and limits must fit the environment and must not be copied from a laboratory guide.

RFC 6815: RFC 2544 benchmarking on production networks considered harmful

Success is more than triggering a filter

A test objective should connect the network with user impact. Run the same representative user workflows before, during and after the test. Define acceptable deviations in advance; there are no universal thresholds. A triggered alert is not a sufficient success if legitimate sessions fail or the operating process breaks down.

• Detection: is the event seen at the agreed measurement point and placed correctly on the timeline?
• Alerting: do notifications reach the correct roles, and can they distinguish the test from a real incident?
• Protection outcome: do the predefined legitimate user workflows remain usable within the agreed criteria?
• Operating process: do escalation, status updates, approvals and decisions work without improvised side channels?
• Recovery: do routing, protection state, application and monitoring return to the documented baseline after the test?
• Evidence: can test stages, actions, user impact and unresolved items be explained on a common timeline?

Stop criteria must be observable before the test begins

A phrase such as ‘stop if there are problems’ is too vague. Define observable triggers and who determines that they have occurred. Stopping ends traffic generation; a separate recovery plan may still be required. The communication path to the test provider must not depend solely on the application being tested.

• Traffic reaches an unauthorised target or affects a service explicitly excluded from the test.
• An agreed limit, stage or time boundary is exceeded or can no longer be measured reliably.
• The effect on legitimate users exceeds the predefined acceptance criterion.
• Monitoring, clock alignment or the independent contact with the test lead becomes unavailable.
• A participating operator asks for a pause or stop, or a separate real security incident begins.
• A service does not recover as expected after traffic stops; subsequent stages then remain blocked.

Illustrative test charter

The following pattern is explicitly illustrative. Documentation address 192.0.2.80 from RFC 5737 is not a real test target; this example grants no permission and deliberately contains no usable traffic figures.

A controlled test-day sequence

1. 1All parties confirm the plan version, approvals, baseline, reachable contacts and go/no-go; nothing starts without complete confirmation.
2. 2Monitoring and representative user workflows are checked in normal operation to provide a current comparison.
3. 3The test begins at the smallest agreed stage. Only the authorised test lead may increase it after a joint hold point.
4. 4Network, protection and application teams maintain a shared timeline and report stop signals immediately.
5. 5At the end, traffic generation is confirmed stopped; temporary changes are reversed according to plan and the baseline is checked.
6. 6Results, deviations and actions are recorded. A repeat receives a newly approved scope rather than an implicit extension.

NIST SP 800-61 Rev. 3 treats preparation, detection, response, recovery and improvement as connected cybersecurity risk-management activities. For a test, that means evaluating not only traffic but also decisions, communication, recovery and the subsequent improvement of the plan.

NIST SP 800-61 Rev. 3: incident response recommendations

If the proposed test touches a traffic path protected through AS51202, include target prefixes, services, participating providers, test objective, proposed window, traffic limits and technical contacts in your enquiry. This provides the information needed to determine whether and under which conditions the test fits the agreed protection scope. The enquiry itself is not approval to start; wait for explicit coordination among all participants.