When a TFTP server receives a read request from a forged address, it sends the first block of the file to the victim, waits for an acknowledgement that never comes, and sends the block again. That is a TFTP amplification attack, and it is the retransmission loop, not the size of the file, that a DDoS test needs to account for when it models this vector. The spoofing that points the reply at the victim is the same as in every other amplification attack; the rest of this page is about how TFTP turns it into volume.
What makes TFTP amplification specific
The Trivial File Transfer Protocol, specified in RFC 1350, is a stripped-down file transfer with no authentication, used for network booting, VoIP phone provisioning and pushing configuration to routers and switches. A client opens a transfer with a read request (RRQ) on UDP port 69, and the server replies in lock-step: one DATA block of up to 512 bytes, then a wait for the client's ACK before the next.
A spoofed request therefore cannot pull a whole file toward the victim, because the victim never acknowledges block 1. What it gets instead is the server's timeout behaviour. The server resends block 1 several times before giving up, and every resend is another full block aimed at the victim. The research that documented the vector, by Boris Sieklik, Richard Macfarlane and William Buchanan at Edinburgh Napier University in 2016, measured an amplification factor of around 60 times, with the retransmissions supplying much of it.
Two conditions constrain the attacker. The request must name a file that actually exists on the server, because a missing file produces one short ERROR packet and no amplification; in practice attackers request the default boot and provisioning filenames that device vendors ship with. And the yield depends on the server's retry count and timeout, which vary by implementation, so the same request is worth more against some servers than others.
Why it matters under attack
TFTP has an awkward property for the defender. A standards-following server does not answer from port 69: RFC 1350 has each side choose a fresh transfer ID, so the DATA packets arrive from a random high port. The cheap trick that neutralises portmap or NetBIOS reflection, dropping a single well-known source port upstream, does not work here. Mitigation has to recognise the traffic by shape, a stream of unsolicited 516-byte UDP packets carrying TFTP opcode 3, or absorb it as generic volume.
The reflectors are mostly embedded: routers, switches and phones whose provisioning server was left listening on a public interface, often by a default that nobody revisited after deployment.
What a DDoS test measures
On the receiving side, the test checks whether mitigation identifies TFTP DATA arriving from ephemeral ports or lets it through because its reflection signatures are keyed on port 69. On the inward side, it confirms that no host in your address space answers an RRQ from outside, including the out-of-band management networks where TFTP is most likely to live. How this is exercised alongside the other reflection vectors in a single run is described in Multi-Vector DDoS Testing.