Summary

  • RFC 5210 reported that packets without authenticated source addresses were not forwarded in a fully featured experimental SAVA path. The condition matters: access, intra-AS and inter-AS validation were all present.
  • Each fence answers a different question from mutable state. A port binding, prefix/interface rule and inter-AS tag do not combine into a timeless proof of the human or organization behind a packet.
  • Source validation reduces spoofing opportunity. It cannot prevent a compromised host or botnet client from attacking with the address legitimately assigned to it.

A green packet at 09:00

At 09:00, a packet leaves a host whose IPv6 address is bound to switch port 17. The access device accepts the tuple. At the provider edge, an intra-AS rule accepts the prefix on that interface. Across the wider path, the destination member of a validation alliance verifies the current inter-AS tag. A controller records three successful checks.

At 09:12, the host fails over to another attachment. A prefix mapping changes at roughly the same time, and an alliance tag is rotating. One validation engine holds the new rule; another still has the previous route-derived set. Old and new tags are temporarily accepted to avoid loss during transition. At 09:15, an assurance screen still says source authenticated, without naming the packet, fences, route view, binding epoch or overlap window.

The first result was not false. It described one packet under the state installed at 09:00. The later badge makes the unsupported move: it converts a layered acceptance result into a durable property of an address and then quietly into an identity claim about a sender.

This is a constructed scenario, not an account of a real operator, product or incident. It isolates the control problem in RFC 5210: validation has coverage, granularity and time. Delete those fields and a useful anti-spoofing result acquires authority it never earned.

What RFC 5210 actually demonstrated

RFC 5210 is an Experimental document from June 2008. Its authors built a Source Address Validation Architecture prototype and deployed it across 12 university ASes connected to CNGI-CERNET2. Six of those ASes had the fully featured arrangement: validation at the access network, inside the AS and between ASes.

The reported result is substantial and carefully scoped. For an AS with all three layers, packets without an authenticated source address were not forwarded in the tested network. The experiment also exercised normal, dynamic and anti-spoofing cases, including tag changes, alliance membership changes and adding or removing address space.

The document does not present that result as an Internet Standard or a finished universal architecture. It says the prototype and experiments are input to later IETF work and points directly to limitations. That status is not a reason to dismiss the work. It is a reason to preserve the experiment's exact claim instead of inflating it.

The phrase “fully featured” carries most of the logic. The test result does not say that one enabled box made every source authentic. It says a packet traversed a path on which access, intra-AS and inter-AS checks were installed. Partial deployment can still reduce spoofing. It simply cannot make unobserved segments disappear.

Three fences, three kinds of evidence

At the access fence, the prototype attempted host-level control. One variant created a dynamic binding among an IP address, a MAC address and a switch port. Packets that did not match the address-and-port tuple were discarded. Another variant derived key material from network-access authentication and used it to protect traffic between the host or local agent and the validating device.

That fence can establish that a packet matches an allocation and attachment under a local binding table. It does not establish who is operating the host, whether the host is compromised, or whether the application generating the packet is authorized.

The intra-AS fence used the ingress-filtering ideas of RFC 2827 and RFC 3704. Here the evidence is coarser: is this source prefix plausible on the interface under the chosen routing model? Strict reverse-path, feasible-path and looser checks make different trade-offs, particularly when routing is asymmetric or a customer is multihomed. An accepted prefix is not a host binding.

The neighboring inter-AS mechanism associated incoming interfaces with permitted source blocks. A rule-generating engine exchanged AS-level information, an AS-to-prefix service projected it into IPv6 prefixes, and validation engines received the resulting rules. For non-neighboring alliance members, the experiment used temporary tags: an egress border added a value and the receiving border verified and removed it.

These checks can reinforce one another, but they do not merge semantically. Host attachment, prefix plausibility and alliance provenance are separate rungs. A defensible system retains each result and its source instead of compressing them into one luminous noun.

Every result has an epoch

The access binding changes when an address is reassigned, a machine moves ports, an interface fails over or a wireless attachment changes. The RFC itself warns that the prototype's access approach would not be sufficient for production without handling such cases.

The neighboring-AS rule changes when relationships, routes or prefix ownership change. RFC 5210 notes that its AS-relation mechanism may not synchronize quickly with route dynamics and can produce false positives. It worked in a relatively stable testbed; instability was an open subject for further study.

The alliance tag also has a life cycle. Membership must be current. Prefix ownership information must be exchanged. Tags or seeds must be refreshed and installed at both peers. During the experiment, old and new tags were valid together for five seconds. The intended alliance could change dynamically, yet initial trust in the testbed was confirmed offline.

None of these details is clerical. They define the period in which an acceptance result has meaning. A dashboard that stores only valid=true loses the answer to the next incident question: valid according to which state?

A proper receipt carries the binding version, source of allocation, attachment, route view, interface rule, AS-prefix mapping, alliance snapshot, tag epoch, overlap deadline and installation acknowledgement. It also identifies the first fence that was absent, stale or bypassed. Without that last field, partial coverage tends to masquerade as complete coverage.

Traceback improves before identity appears

RFC 5210 connects reliable source addresses with more confident traceback. That is reasonable: if spoofed packets are rejected at several boundaries, investigators can rely more heavily on the remaining address and path evidence. But confidence is not a change of category.

RFC 7039 later makes the warning explicit. It is tempting to treat source-validation data as proof of the person—or even the end system—that originated a datagram. The technology can supply circumstantial evidence, not solve attribution by itself. Multi-user servers, relays, proxies, application platforms and compromised endpoints all sever the simple line from address to actor.

Even an ideal address binding says where a packet was acceptable in the network model. Account authentication says which credential acted. Workload evidence says which process emitted traffic. Organizational records say who controlled an asset. Human attribution and intent require still more evidence. No one of those claims can be borrowed from the preceding layer.

This distinction also protects users. Binding logs can be useful during an incident, yet they can reveal where a person or device was active. Retention, access and interpretation need an explicit privacy basis. A technically plausible association should never become automatic punitive attribution.

A valid address can carry a valid attack

The most important limitation in RFC 5210 is easy to miss because it appears after the positive experiment. A large fraction of denial-of-service attacks can be sent from legitimate addresses belonging to botnet clients. Even universal source-address validation would not stop those attacks.

That sentence defines the ceiling. SAVA can make it harder to forge another source and can improve the path back to the sending network. It does not attest endpoint health, benevolent intent, permitted volume or application legitimacy. A compromised laptop that uses its assigned address can pass every anti-spoofing test while generating harmful traffic.

Executives should therefore resist the phrase “authenticated traffic” unless the noun following it is precise. An address may have been accepted. A packet may have traversed a validated path. Neither means the application, account or actor has been authenticated, and neither means the traffic is safe.

Control-plane proof is not data-plane proof

The experiment also exposes a practical execution boundary. Its lightweight alliance value was a shared random tag, not a per-packet cryptographic identity proof. RFC 5210 discusses an on-path attack risk and the cost of stronger cryptographic processing. It also reports reduced forwarding speed when IPv6 hop-by-hop options encountered routers that handled them on a slow path.

The operational question is not simply whether a rule or tag exists in a controller. It is whether the intended interface installed it, whether packets hit the fast or slow path, whether invalid traffic was dropped, and whether counters can be correlated to the current rule epoch.

A configuration snapshot is evidence of intent. An installation acknowledgement is evidence that a device accepted state. Data-plane counters and test packets are evidence of effect. None should impersonate the next.

The receipt worth keeping

For each packet or sampled flow, retain the capture point and time, intended validation profile and required fences. At access, record allocation provenance, address, attachment, binding creation and expiry, and move handling. At intra-AS ingress, record mode, interface, routing view, prefix rule and generation time.

For inter-AS validation, retain the AS relationship, prefix mapping, rule source, distribution acknowledgement and installed hash. For alliance tags, retain membership state, peers, ownership exchange, tag or seed epoch, overlap interval and expiry. Attach software and hardware versions, unsupported option behavior, counters, drops and test provenance.

Then stop at the evidence boundary. If the system has independent device, workload, account or human attribution, link it as a separate receipt. If it does not, report address/path accepted; actor unknown. That wording is not weak. It is the exact statement that lets an investigator know what must happen next.

Sources