Summary

  • The IESG's September 17 Last Call seeks comments by October 1 on draft-ietf-savnet-inter-domain-problem-statement-21 as an Informational RFC; neither approval nor deployment has occurred.
  • Its gap analysis separates customer, lateral-peer and provider interfaces, where avoiding wrongful blocks and allowing forged traffic have different evidentiary and operational costs.
  • Working-group consensus, IESG review, a later mechanism, local policy and measured traffic effects are distinct decisions.

A packet arrives at a border router with a plausible source address. The router has a route to that prefix. Neither observation settles the important question: was this neighbor entitled to send traffic bearing that source through this interface? The ambiguity is not an exotic exception that a single global lookup can erase. The SAVNET draft organizes it by commercial and routing relationship—customer, lateral peer and provider—and asks future designs to avoid both improper blocking and improper permitting while keeping operational cost manageable.

On September 17 the IESG announced a Last Call on revision 21, requesting substantive comments by October 1. The request is to consider a problem statement, gap analysis and requirements as an Informational RFC. The Datatracker still lists it as an active Internet-Draft at “Publication Requested.” A successful Last Call would not itself install a filter, publish a mechanism specification, authorize an operator's local policy or demonstrate a reduction in spoofed traffic.

The customer-facing cases expose why the wording matters. A multihomed customer can selectively propagate a prefix, including by using NO_EXPORT, while sending legitimate traffic from that prefix along another path. A direct-server-return deployment can use an anycast address as a response source on a path where that prefix is not advertised from the edge server's AS. A strict route-derived source list can then discard a valid packet. The diagrams in the draft are thought experiments used to test mechanisms; they are not reports of named production outages.

Conversely, broadening an allowlist to suppress those false blocks can permit a customer-cone neighbor to spoof another neighbor's source, particularly when enforcement has not reached the nearer network.

Peers change the inference again. Asymmetric paths make a narrow reverse-route test especially fragile at a lateral interface. An operator may choose a more permissive method, but a permissive result says only that a source is reachable somewhere, not that this peer is the authorized ingress. At an upstream provider interface, the draft contrasts the upkeep of ACL rules with Loose uRPF's weaker directionality: a prefix in the FIB may still be spoofed by traffic arriving from the provider. These are different failure modes, not one universal false-positive rate.

The document's requirements therefore reach beyond a nicer prefix lookup. They ask a future mechanism to seek accurate validation, manageable overhead, useful protection before universal adoption, protection against tampering with SAV-specific information and sound convergence after routing or validation-state changes. A local routing view and an RPKI object, which may have been created for another purpose, are not interchangeable with a new SAV-specific assertion. The source, freshness, authorization and trust model of each assertion matter before it enters an enforcement table.

The institutional trail is also bounded. The document shepherd's July account records two working-group Last Calls and broad agreement, and explicitly says the text is not a protocol document or a BGP/RPKI extension. An early Routing Area review of revision 20 praised the analysis but asked whether “seek to achieve zero improper blocking” was a hard requirement or an aspiration and how the information trust models should be distinguished. That is a dated review of an earlier revision, not an unresolved IESG verdict on revision 21. It illustrates the kind of precision the final comment period can test.

The relevant evidence for this Last Call is thus a text-and-decision record: which interface cases are within scope, which guarantees are design goals, what a candidate mechanism would need to authenticate, and which operational feedback is required when legitimate traffic is blocked or spoofing slips through. It is not yet a deployment ledger. A future standard would need its own review; an operator would then choose, configure and monitor it; traffic measurements would have to establish effects separately.

Sources