Summary

  • The IESG opened Last Call on 17 September for revision 21 of the SAVNET inter-domain problem statement, seeking comments by 1 October. It is an intended Informational Internet-Draft, not an approved RFC or a newly deployed filter.
  • The draft identifies both improper blocking of legitimate traffic and improper permitting of spoofed traffic. Its troubleshooting section says a border router cannot inherently detect these mistakes from its own SAV table.
  • A practical response needs a feedback path from affected neighbouring operators to the owner of the filtering decision. A traceable complaint-to-correction record is this article's proposal, not a specified IETF protocol.

A border router can answer a narrow question quickly: does the incoming packet's source address fit the local source-address-validation table for this interface? It cannot answer the larger question merely by repeating that lookup: was the table's view of the legitimate source complete? That distinction is the news in the SAVNET working group's problem statement now before the IESG. The document moves beyond the familiar instruction to reject spoofed sources and names the cost of a wrong rejection, as well as the cost of letting an illicit source through.

The draft's examples explain why the first error is possible without assuming an incompetent operator. A prefix can be announced only to selected networks, or used as a source-only or direct-server-return anycast prefix without the BGP visibility a filter expects. A route table is therefore not a universal register of valid senders. If the SAV table is built from incomplete routing information, legitimate packets can be discarded. Conversely, a method that relaxes the direction from which a prefix may arrive to avoid false blocks can admit spoofed traffic.

Partial deployment further limits any claim that traffic originating within a customer cone has been fully screened.

Section 6 is unusually candid about diagnosis. The AS border router performing SAV cannot itself discover every improper block or permit caused by its table. Operators may learn of a problem from the downstream or peering network whose traffic is affected, and troubleshooting then crosses an organisational boundary. The local device records a verdict. The other side may be the first to know that the verdict has harmed reachability. Neither a drop counter nor a complaint alone proves which prefix and interface rule was wrong; they are starting points for investigation.

This differs from a laboratory benchmark. A test lab can declare which synthetic packets are legitimate before running the filter and score false positives against that prearranged answer. Production networks do not get that oracle. The SAVNET problem statement is not presenting measured incident rates or a certification scheme. It is asking future methods to improve accuracy, update SAV information with less manual work, benefit early adopters during partial deployment, secure any new SAV-specific information, converge efficiently and provide troubleshooting guidance. It does not prescribe a universal inter-operator ticket format.

An operator can nevertheless make the boundary accountable. A useful local receipt would record the ingress interface and neighbour relationship, the bounded source-prefix claim, the SAV-table and input versions in force, the time of the observed loss or suspicious permit, the affected party's feedback, the investigator, the decision to change or retain the rule, and evidence of closure. Some of that material exposes traffic or commercial topology; it should be minimized and disclosed only to those who need it. This is an editorial operational recommendation, not a requirement of revision 21.

Nor would every reachability complaint mean the filter made a false-positive decision.

The process status matters. Revision 21 was dated 19 July; the dated September event is the IESG Last Call, with comments due 1 October. The document is a gap analysis and requirements statement, not a new data-plane protocol, a repeal of BCP 38 or proof of deployment. Its value at this stage is to make an ownership problem explicit: the party that enforces an inter-domain source rule may not hold the evidence needed to validate the rule's effects. A security control whose errors are visible only elsewhere needs a disciplined way for that evidence to travel back.

Sources