Summary

  • The 1 October revision of the SAVNET working-group intra-domain source-address-validation architecture explicitly separates operator provisioning from acquisition of routing information. For BYOIP and other externally obtained prefixes, it says the access operator should ask the customer to identify the prefixes and provide evidence of authorization to source traffic from them, even if no corresponding route is configured or advertised.
  • The draft remains an active, Informational-intended Internet-Draft, not an RFC or a deployment report. It specifies no proof format, new inter-AS protocol, registry approval process or automatic drop rule. Its narrower news is the placement of source-use evidence in the operator's customer-facing rule-generation process.

A packet can have a source address that the local route table cannot explain. That does not make the packet legitimate, but it also does not prove spoofing. A customer may have two attachments, asymmetric forwarding or a prefix used as a source without a visible destination route. The access router needs a rule at the interface where the packet arrives. The routing table is evidence about reachability; the required decision concerns permission to use a source prefix on that particular customer attachment.

The June version of the SAVNET architecture already acknowledged this mismatch. It described hidden prefixes, asymmetry and a logical SAV Agent that derives rules from routing and SAV-specific information. Revision 05 does not invent the distinction. It makes the acquisition paths and their operational responsibility more explicit. One path draws on operator-held customer, address-allocation and routing-configuration records. Another obtains useful prefixes from the routing system. The two can be combined, but missing source-only authorization cannot be reconstructed from routes that do not contain it.

That is why the BYOIP paragraph matters. For a prefix supplied by the customer or another provider, the draft says the AS operator needs the customer to identify the prefix and provide evidence that it may be used as a source. The permission must be represented even if the customer advertises no route for it. This is not a claim that a ROA, registry entry or any single external credential alone settles every packet decision. The document names no universal proof artifact. The operator must connect the evidence it accepts to its own customer, interfaces and rule-generation system.

The new worked example is deliberately small. Customer C reaches one AS through interfaces i1 and i2 on different routers. Two prefixes, P1 and P2, appear in relevant routing information; a third, H, is a hidden or source-only prefix. The example permits all three on both customer-facing interfaces once the operator's information establishes that C may use them. H needs an explicit authorization record because route-derived information cannot supply it. If assignment or authorization changes, the SAV Agent must update the affected rules on both interfaces.

The example demonstrates two information-acquisition designs, not a real customer deployment.

The boundary also protects against the opposite mistake. Automatically accepting any prefix that appears in a routing view would confuse destination reachability with source entitlement. Automatically rejecting every prefix absent from that view would penalize legitimate source-only use. Revision 05 recommends allowlist-based rules, asks solutions to account for incomplete inputs and leaves the invalid-packet action to local policy. Operators may begin with monitoring or conservative handling before strict drops. Accuracy depends on information coverage and update discipline, not simply on enabling a filter.

Nothing in this draft moves customer permission into the hands of a new central authority. The information delivery it discusses is inside the AS, and it prescribes neither a protocol nor a fixed SAV Agent location. It is still a working-group draft marked I-D Exists. The governance question is therefore practical: can the operator show why a prefix was permitted on a specific attachment, where the evidence came from and when a change reached the installed rule?

Sources