Paying for Unproven Requests

## The three parties, then the arithmetic A reflection attack has three parties, not two. The **attacker** sends requests. An **unwitting answerer** — some ordinary internet-facing service — receives those requests and replies. The **victim** receives the replies, because the requests carried the victim's address as the sender. The attacker never speaks to the victim at all; the packets that arrive at the victim were emitted, correctly and in good faith, by strangers. The **amplification factor** describes only one property of that arrangement: how much bigger the answer is than the question. ``` factor = bytes the answerer sends to the victim / bytes the attacker sent to the answerer ``` If one datagram of 62 bytes on the wire provokes an answer totalling about 3,000 bytes, the factor is about 48x. Nothing more subtle than that is being claimed by the number. ## Why it is the number an attacker actually optimises The scarce input on the attacking side is upstream bandwidth. Whatever an operator can push out of their own hosts is fixed by what they rent or control. The flood the victim experiences is approximately: ``` delivered flood = attacker uplink x amplification factor ``` Doubling the uplink means paying for twice the capacity. Doubling the factor — by choosing a different protocol, or a different request within the same protocol — costs nothing. That asymmetry is the whole reason reflection exists as a technique. Someone selling flood capacity on a subscription or revenue split is running a margin business: they hold a fixed, cheap sending capacity and multiply it. Their protocol shortlist is ranked by factor per source packet, and it changes whenever a higher-factor answerer population becomes reachable. ## Byte factor and packet factor are different numbers An answer that does not fit in one datagram arrives as several. A 62-byte request that yields six datagrams totalling 3,000 bytes has a byte factor near 48x and a packet factor of 6x. Both are real multipliers and they are counted separately, because a large answer split into many small datagrams multiplies packet rate far more than it multiplies bytes, while a single large answer does the reverse. When someone quotes "the factor" for a protocol without saying which, treat the figure as approximate. ## The factor belongs to the request, not the protocol This is the detail candidates most often get wrong. A protocol is not a single number. The same service can answer a minimal query with a few hundred bytes and a bulk enumeration query with tens of kilobytes; an attacker sending the bulk request gets a far better ratio from exactly the same population of answerers. Published measurements across abused connectionless services span an enormous range — roughly 30x for one common discovery protocol, into the hundreds for a historical bulk-status query that has since been removed from default builds, and into the tens of thousands for a UDP-exposed in-memory cache abused in 2018. Those are measurements of particular request/response pairs at particular times, not constants. ## Reflection and amplification are not synonyms Reflection is the structural fact: the traffic reaches the victim from a third party that was asked a question. Amplification is the economic fact: the answer is bigger than the question. You can have reflection at a factor near 1 — the traffic still arrives from strangers, but the attacker gained no volume for it, so the technique buys structure without leverage. Amplification is the subset of reflection worth paying for, and a candidate who treats the words as interchangeable will fail to explain why an attacker prefers one connectionless service over another. ## What the factor does not tell you The factor is a per-exchange ratio. It says nothing about how many answerers exist, how much aggregate capacity that population can emit, or how fast the attacker can address them. A factor of 50,000x from a population of two hundred hosts on slow links delivers less than 30x from a population of two million. It also says nothing about the answerer being defective. Every answerer in this arithmetic is doing precisely what it was built to do: it received a well-formed request and replied to the address it was handed. The multiplier is a design consequence, not a bug being exploited. ## What to say in an interview Define it as a ratio, compute one out loud, name the attacker's uplink as the multiplicand, and add the two qualifications that show you have thought about it: the factor is per request type rather than per protocol, and reflection at 1x is still reflection.