Summary

  • RFC 862 made UDP Echo return the received data; RFC 864 made UDP Character Generator ignore the request and send one generated response of zero to 512 characters.
  • A forged source could point Chargen at Echo. Chargen's answer became Echo's request, Echo's answer became Chargen's next request, and the initiating host no longer had to participate.
  • BCP 38 documented this exact loop and moved control to exposure and source-prefix boundaries; later guidance added topology-aware filtering, peer validation, rate limits and circuit breakers without pretending that any one measure authenticated a host.

Begin after the attacker has left

Start the packet trace at the second exchange, not the first. A UDP datagram arrives at a Character Generator service. The service does not inspect the payload. It creates a string and sends it to the source address and source port in the datagram. That destination happens to be an Echo service. Echo returns the same bytes to their apparent origin. The apparent origin is Character Generator, so the cycle starts again.

The initiating packet mattered, but its real power was arranging identities. Its sender claimed to be the Echo endpoint. After that forgery, two honest-looking responses supplied all the causes the loop required. The initiator could stop transmitting while the services continued to consume link capacity, packet-processing time and operational attention.

This is a more exact failure than the broad label “UDP amplification” suggests. The defining property is feedback. There need not be a directed broadcast or a crowd of reflectors. The composition can involve two unicast endpoints, each performing one response per request exactly as designed.

Two diagnostic rules with no shared memory

RFC 862, published in 1983, described Echo as a tool for debugging and measurement. Its TCP version returned received data until the client closed the connection. Its UDP version listened at port 7 and sent the contents of a received datagram back in an answering datagram.

RFC 864 defined Character Generator for a similar diagnostic purpose. The TCP service continuously produced a recognizable character sequence and relied on TCP flow control. The UDP service at port 19 behaved differently: it disregarded the contents of any received datagram, selected a random response length from zero through 512 characters and sent one answering datagram. It kept no history across requests.

Each definition was small enough to implement without a conversation state machine. Echo did not need to know why the bytes had arrived. Chargen did not need to parse them. That simplicity was useful on a test bench. It also meant neither service possessed a causal fact that later became essential: whether this apparent request was itself the response to the service's previous packet.

RFC 768 supplied the minimal transport setting. UDP carried source and destination ports, a length and a checksum around a datagram. A source port could name the port to which a reply should be addressed. UDP did not establish a durable peer relationship before allowing the application to answer.

One answer was a local bound, not a system invariant

RFC 864 explicitly reasoned that the datagram service should not send data faster than requests arrived because it produced only one response for each request. Read inside one implementation, the proposition is true. Chargen does not spontaneously make a second answer to one invocation. Echo does not multiply a single input into a list of outputs.

But the output of one component can be the input of another. Once Echo and Chargen are connected by claimed endpoint identities, “one answer” becomes the edge of a cycle rather than the end of a transaction. The system-level question is not how many packets one function returns. It is whether the return value can trigger the function again through another path.

That distinction is the historical value of the episode. A local counter can certify conformance while missing persistence. Each service may log an ordinary request followed by an ordinary reply. Only a view across both endpoints reveals that replies have become requests and that no independent actor is introducing new work.

BCP 38 named the composition

The loop was not reconstructed later from vague folklore. RFC 2827, the 2000 document commonly known as BCP 38, used it as a concrete example of source-address forgery. It described an attacker sending UDP packets so that one site's Chargen service became connected to another site's Echo service. The resulting traffic persisted between the two systems.

The document drew two operational conclusions. First, diagnostic services such as these should not be reachable from outside the administrative network. If an external packet cannot reach the service, it cannot recruit that service into the composition. This is an exposure decision, not a new meaning for Echo or Chargen.

Second, a network carrying traffic from a customer should reject packets whose source address is not legitimately associated with that customer's advertised prefixes. That ingress check limits the address claims a downstream network can export. It makes an outside victim address harder to forge and narrows the place from which abuse can emerge.

The name “ingress filtering” can obscure the direction of responsibility. The filter is applied where traffic enters a provider from a customer, before the packet is allowed to travel outward. The useful evidence is not that the packet reached a destination, but that its claimed source was plausible at the boundary that admitted it.

Prefix plausibility is not host authentication

BCP 38 also recorded what its test could not prove. If a compromised host uses the address of another host inside the same permitted customer prefix, a simple prefix filter will accept it. Traffic with a truthful source can still flood a victim. The measure constrains a class of lies; it does not turn an IP source field into an authenticated identity.

Routing topology complicates the enforcement further. RFC 3704, BCP 84, described strict reverse-path, feasible-path, loose reverse-path and access-list approaches for multihomed networks. A strict test expects the best return route to use the interface on which the packet arrived. Legitimate asymmetric routing can violate that expectation.

Operators therefore choose among different evidence strengths and failure modes. Loose reverse-path checks reject sources absent from the routing table but admit more spoofing. Feasible-path methods recognize more legitimate paths but require suitable routing information. Explicit access lists can be precise but must follow prefix changes. “Deploy source validation” is a direction; its reliable implementation depends on the topology being protected.

Later UDP guidance made the missing state explicit

RFC 8085 generalized the lesson for UDP applications. A local UDP socket connected to a peer can filter incoming packets, but it does not notify the peer or establish an authenticated association. If an application requires messages from a particular source, it must check that property itself or arrange for the operating system to do so.

The guidance also states that UDP supplies no flow control. Applications must avoid patterns in which a small request elicits a much larger response, must not rely on a source IP address as authentication because it can be spoofed, and should restrict or authenticate requests that can cause substantial traffic. Rate limits and circuit breakers provide another kind of state: they ask whether continued sending remains justified even when each individual packet looks syntactically valid.

None of these controls alone is a complete answer. Closing public access prevents a path but says nothing about an internal compromised host. Source-prefix validation makes many forgeries harder but does not authenticate an address inside an allowed prefix. Application authentication may be excessive for a tiny diagnostic service, which strengthens the case for not exposing it. A rate limit contains load but does not repair false identity.

A registry coordinates rendezvous, not permission

The current IANA Service Name and Transport Protocol Port Number Registry records echo on port 7 and chargen on port 19 for both TCP and UDP. The stable numbers explain how independently built programs could find the same diagnostic functions.

They do not show that a present host runs either function, that the port is reachable, or that an answer conforms to the old RFC. Registration does not authorize exposure and does not certify safety. It is namespace evidence only.

This boundary matters in incident work. A packet addressed to port 19 is a clue, not a verdict. The investigator still needs payload behavior, direction, timing, endpoint ownership and evidence that responses are causing subsequent requests.

The constitutional lesson of a closed cycle

Echo and Chargen were not secretly malicious protocols. Each exposed a small, legible diagnostic action. The failure appeared when their outputs were composed under a false account of who had spoken. No service was responsible for the whole path, so neither possessed the state required to end it.

The durable design principle is that local work limits need a compositional test. Ask whether an output can re-enter as input, whether claimed source identity is sufficient to direct a response, and which boundary can withdraw authority when a cycle forms. “One reply per request” answers none of those questions by itself.

The Internet did not solve this by assigning all control to a central judge. Operators controlled reachability. Access networks constrained source claims. Applications validated peers and governed response cost. Observability systems connected packets into causes. The safety property emerged only when those local authorities supplied evidence the original services did not have.

Sources and evidence limits

The sources establish the protocol behavior, the documented loop, filtering methods and later UDP guidance. They do not quantify current deployment, attack frequency, average response size or BCP 38 adoption. This article therefore makes no prevalence claim and treats the two-service loop as a documented mechanism, not as a measurement of today's Internet.