CLDAP amplification was first documented in October 2016, when Akamai's response team traced a new reflection vector to exposed Connectionless LDAP services and measured an average amplification of 56.89 times the request. It still matters because the reflectors are misconfigured directory servers rather than obscure appliances, so a thorough DDoS test treats it as a live volumetric case and not a historical curiosity. The mechanism underneath is the ordinary amplification attack recipe, forging the victim into the source field of a UDP request so that a stranger's directory server replies to a machine that never queried it.
What makes CLDAP amplification specific
The abused service is Connectionless LDAP, a UDP-based shortcut to the Lightweight Directory Access Protocol that answers on port 389 without setting up a session. A single small CLDAP query aimed at a directory server's root DSE returns the server's naming contexts and capabilities, a reply many times the size of the question. Akamai's measurement put a roughly 52-byte request against replies near three kilobytes, which is where the headline average of about 56.89 times comes from, with individual servers observed pushing the ratio toward 70.
What sets this vector apart from the older UDP reflectors is the population answering it. The exposed hosts are overwhelmingly Windows Active Directory domain controllers and other LDAP servers that were never meant to face the internet on 389 but do, so the reflector pool tracks enterprise misconfiguration rather than forgotten consumer devices. That makes it a compact but potent reflector: a modest set of directory servers can build a multi-gigabit flood, and the amplification factor is high enough that the attacker commits very little outbound traffic of their own.
Why it matters under attack
A filter has nothing to work with here. Each packet is a valid LDAP response from a real, correctly functioning directory server, indistinguishable from an answer that server might give any client, so reputation lists and signature matching have nothing to grip. The link fills on raw response volume, and it fills before the request ever reaches an application port, which leaves the defender absorbing bytes rather than rejecting a sender.
The two controls that would actually stop it both sit off the victim's network. If the carriers where the spoofed packets originate enforced source-address validation (BCP 38), the forged queries would never leave; if the operators running those directory servers closed CLDAP on port 389, the reflector pool would empty. The target owns neither, so the vector outlives every advisory written about it.
What a DDoS test measures
With the cure out of reach, the test at the target can only quantify how much punishment it takes. It drives a load profiled on reflected CLDAP and watches two numbers: the point at which absorbed volume starts costing real users their goodput, and the lag between the flood starting and mitigation taking hold. The second, inward-facing check is specific to this vector: enumerate your own directory servers and confirm none of them answer CLDAP from the public internet, because an exposed domain controller makes your network a weapon in someone else's campaign. Understanding DDoS Attack Vectors sets CLDAP beside the other reflection vectors a test tends to drive together.