Summary

  • draft-sriram-savnet-intrasav-solution-00 proposes building per-interface source-address allowlists from explicit routing and source-use configuration, including BYOIP prefixes that are never announced.
  • Its zero-improper-block and zero-improper-admit statement is conditional on complete configuration. Revision 00 does not yet define the receipts that would prove a configuration generation reached, committed on and governed the intended router interface.

The Configuration Manager has calculated a perfect allowlist. Customer 2 may route prefix r and may source packets from s, even though s is not announced. The rule for its Customer Edge interface therefore contains both. On paper, no legitimate packet is blocked and no spoofed source is admitted.

Now move the change by thirty seconds. The customer registered s after one CE router had already committed the previous generation. Or the controller sent the new list to a logical interface that was replaced during a maintenance window. The set remains correct in the Configuration Manager. The packet still reaches a different rule.

That is the useful tension in IntraSAV - A Solution for Intra-Domain Source Address Validation. Revision 00 was uploaded on 1 October 2026. It is an individual Internet-Draft in I-D Exists, with intended status Best Current Practice. It is not SAVNET Working Group adoption, an RFC, an implementation report or deployment evidence. If approved, it would update BCP 38 and BCP 84; it does not update them today.

Stop asking the FIB an authorization question

The proposal addresses a real gap. Conventional strict unicast reverse-path forwarding asks whether the route back to a source points through the interface on which the packet arrived. That can block legitimate asymmetric or multihomed traffic. Loose mode avoids some false blocks by checking only whether a route exists, but it loses directionality and can admit spoofed sources. An access list can be precise, yet it becomes wrong when an operator does not update it with the permitted prefix set.

The deeper category error is that a FIB represents reachability. It does not necessarily express authorization to use an address as a packet source. Direct Server Return makes the distinction vivid: an edge may legitimately send a response using an anycast service prefix that it never advertises as a route. A BYOIP customer may likewise use one prefix for both routing and sourcing and another only for sourcing.

IntraSAV moves that hidden fact into explicit local configuration. A customer tells the local AS which prefixes it intends to use, on which interface and for which purpose. The local AS adds the corresponding information for its own provider-owned prefixes. A Configuration Manager, possibly with a SAV Agent, consolidates those inputs and constructs a separate allowlist for every relevant CE interface.

In the draft's example, Customer 1 registers {p, q} and routes both, while Customer 2 registers {r, s}, routes r and uses s only as a source. Interface 1 receives {p, q}; Interface 2 receives {r, s}. That is more faithful than pretending the absence of a route for s means packets sourced from s are illegitimate.

Local authorization and the ROA tell different truths

The draft asks prefix owners to create ROAs authorizing the local AS as origin. Yet it also says that, for locally originated routing or sourcing, local configuration takes precedence over ROA information. The AS should compare the two and alert a customer when they disagree because remote networks may use the ROA when building their own inter-domain SAV view.

This is not a contradiction. It exposes two control surfaces. The local AS needs a precise assertion that a customer may source one prefix on one interface now. A remote AS needs evidence about the origin authorization visible beyond that local boundary. A ROA match can improve consistency, but it does not prove that the customer submitted the local binding, that the interface still belongs to that customer or that a rule has reached packet-processing hardware.

Revision 00 says the Configuration Manager authenticates customers. It does not define the enrollment protocol, credential, authorization scope, change approval, revocation, replay protection or signed receipt for the customer-prefix-interface statement. Those choices can remain local in an initial specification. Their results cannot remain invisible if operators later want to prove why one packet was allowed and another was dropped.

A conditional guarantee is a design property, not an observation

The draft's strongest sentence says that, as long as the local Configuration Manager has complete configuration information, IntraSAV guarantees zero improper blocks and zero improper admits. For the modeled set, the logic is clean: every authorized source for that interface is on the list; everything else is not.

But “complete” is doing the decisive work. The document does not give an independent completeness test. It defines no configuration generation, effective time, expected router inventory, atomic update, delivery acknowledgement or rollback. It does not say how to treat an interface while one prefix is added, removed or moved, how a restarted router catches up or how two conflicting inputs are resolved.

The distinction matters because an internally correct controller result can coexist with an incomplete network rollout. One CE accepts generation 41; another still enforces generation 40. A rule lands in software but not the forwarding ASIC. A customer is rehomed to a new interface while the old permit remains. Removing a prefix closes a spoofing aperture on one router and briefly blocks legitimate failover traffic on another.

None of these possibilities disproves the proposal. They identify the receipt layer that running code must add. “Zero” becomes operational evidence only when there is a denominator: the authorized prefix-interface population, the committed generation on every intended enforcement point, labeled legitimate and spoofed test traffic, and counters that distinguish proper permit, proper block, improper permit and improper block.

One aggregate filter can conceal two missing bindings

The draft also contains an explicitly unsettled paragraph. An operator might apply an aggregate {p, q, r, s} allowlist at an AS Border Router if the topology guarantees that all arriving traffic should use prefixes originating from the local AS. That may be practical when upgrading an ASBR is easier than upgrading CE routers.

The text labels this idea “To be Discussed” and says it likely extends beyond the problem statement's scope except when the ASBR directly serves hosts or a non-AS customer. Leadership should preserve that caution. A union at Interface 3 can show that a source belongs somewhere inside the AS, but it loses the narrower evidence that s belongs specifically on Customer 2's Interface 2. Aggregate defense and per-customer enforcement answer different questions.

Incremental deployment adds the same challenge. The SAVNET problem statement requires measurable benefit when only some external interfaces participate. A controller can report that it generated rules for 60% of CE interfaces. That is a deployment inventory, not yet a security outcome. Operators still need to know which attack paths the covered interfaces close, which legitimate flows they risk, and whether uncovered or broadly filtered edges become the path of least resistance.

Put a generation number between intention and packet

A defensible operating model keeps ten receipts separate: customer authentication; authorization for a prefix, interface and use mode; acceptance of a versioned configuration; ROA consistency; allowlist calculation; delivery to the intended router and interface; atomic commit or rejection; packet match/drop counters; labeled false-positive and false-negative tests; and the observed security and service outcome.

The minimum-specification doctrine in Heng Lu's notes supports a narrow common method without demanding that every operator expose the same internal machinery. The running-code doctrine then asks for evidence at the execution boundary. A Configuration Manager can remain locally designed, while still producing a configuration digest, per-interface generation and commit acknowledgement that an independent operator can reconcile.

IntraSAV's decisive improvement is to stop inferring source authorization from routes alone. Its next test is whether the explicit truth stays explicit all the way to the packet. A complete allowlist in a controller is the beginning of that proof, not its final receipt.

Sources