Which two properties make a network protocol usable as a reflection amplifier?

## The shortlist an attacker applies When someone is looking for new amplifier stock, they are screening protocols against a very short checklist. Two properties are structural and one is economic. ### 1. The answer is committed on the strength of a single arriving datagram The service must be willing to produce output after receiving one packet, with no preceding exchange. There is no round trip in which the requester has to demonstrate anything before the answer is generated and sent. This is the ordinary behaviour of connectionless request/response services: they exist precisely so that a lookup costs one packet each way, and that efficiency is the point of the design. ### 2. The answer's destination is taken on trust from the request The service replies to whatever sender address the arriving datagram carried. It performs no test that the party at that address is the party that asked. From inside the service this is not even a decision — the reply is simply addressed back to where the request said it came from, which is the only information available. Take those two together and the consequence is mechanical: a request can be sent that causes bytes to be delivered to a third party who never asked for them. This is the whole shape of reflection, and it is present with no defect anywhere in the chain. ### 3. There exists a request whose answer is much larger than it The first two properties give reflection. This one gives amplification. The attacker is not looking for a service that answers; they are looking for a *question* whose answer is bulky. Enumerations, full status dumps, discovery responses, bulk record sets and anything that returns a list are the interesting ones; a single-value lookup is not. That is why quoting a factor for a protocol without naming the request is imprecise: the same daemon can be a 3x amplifier and a several-hundred-x amplifier depending on which request it is handed. ## What is deliberately not on the list **A vulnerability.** No memory corruption, no authentication bypass, no unpatched release. Nothing is being exploited in the sense of subverting the service's intended behaviour. The service is being *used*, at scale and on someone else's behalf. **Compromise of the answerer.** The attacker never gains any access to the answering host, never runs code there, and never needs to. They are a client, and a well-behaved one at the protocol level. **A misconfiguration, necessarily.** Sometimes the service is exposed more widely than intended, and narrowing that exposure is the practical remedy. But a service that is intentionally public and intentionally connectionless still satisfies the checklist. Reachability is a scoping decision, not an error. ## Why a connection-oriented equivalent is a poor amplifier If the protocol completes a handshake before the payload flows, the requester must receive something at the address it claimed and echo it back. A party sending from an address it cannot receive at never completes that step, so the large payload is never produced. You can still bounce the handshake response itself off a listening host, but that response is roughly the size of what provoked it, so the factor sits near 1 — reflection without leverage. The handshake is not a security feature bolted on; the return-path proof is a side effect of establishing state, and it happens to remove exactly the property the amplifier needs. ## The refusal that still amplifies A subtle case worth being able to state: adding an access check does not by itself remove amplification unless the check happens *before* bytes are committed to the claimed address. A service that receives a 60-byte request from an address it does not recognise and replies with a 500-byte structured refusal is still an amplifier, at roughly 8x, and it is now amplifying on behalf of anyone at all rather than only authorised clients. The rule is about the size and destination of what leaves the host, not about whether the request was granted. ## What actually removes the property Only two levers exist, and both are choices rather than fixes. **Scope**: decide which networks may ask at all, so the population of reachable answerers shrinks. **Protocol**: adopt an exchange in which the answerer sends something cheap to the claimed address and requires it back before committing the expensive answer — a token or cookie echoed in a second, small exchange. That second lever is the only one that removes amplification while keeping the service public, and it is a design decision taken in the protocol, not a patch shipped by a vendor.