Source Address Validation: A Survey of Mechanisms, Measurement, and Deployment

1. Introduction

Source address validation (SAV) limits the addresses that a sender can place in the source field of an Internet Protocol (IP) packet. Ordinary destination forwarding does not establish that entitlement. A packet can therefore reach a destination even when its source identifies a different host or network. This separation enables impersonation, conceals attack origins, and redirects replies toward victims. Network ingress filtering addresses the problem by discarding packets whose sources are inconsistent with the network from which they arrive [1,2]. Its value extends beyond any particular denial of service attack: a network that cannot trust packet sources cannot safely treat an address as evidence of origin.

Operational complexity prevents a single filtering rule from covering every legitimate path. A customer with one attachment can often use a simple prefix list. A customer with several providers can send traffic along a path that differs from the return path. A host can acquire or relinquish an address while a switch retains an older binding. A transit network can receive traffic from sources that its selected routes do not expose through the same neighbor. RFC 3704 and RFC 8704 address parts of this problem through increasingly permissive forms of reverse path checking [3,4]. The resulting tradeoff is structural: broad permission protects connectivity but admits more forged sources; narrow permission constrains attackers but risks rejecting legitimate traffic.

Measurement adds a second difficulty: a filter is not directly visible from every observation point. A received spoofed packet demonstrates a reachable failure of validation for that test. An unanswered probe does not, by itself, demonstrate successful validation. Packet loss, an inactive endpoint, a firewall, or an unobserved path can produce the same outcome. The Spoofer project, the Closed Resolver Project, and OSAVRoute expose different parts of this hidden state [5,6,7]. Their observations are valuable precisely when the direction, address class, path, and sampling population remain attached to each result.

This survey asks what evidence makes a source acceptable, what observations establish that the evidence is enforced, and what conditions make enforcement deployable. We use these questions to connect research that otherwise falls into separate communities: routing protocols, access network security, cryptographic architectures, Internet measurement, programmable forwarding, and network operations. We distinguish a mechanism’s acceptance rule from the information that supplies it. We also distinguish the protection promised to a participating network from the protection supplied to other networks. These distinctions make comparisons meaningful without assuming that every proposal solves the same problem.

Recent work makes a renewed synthesis necessary. UniSAV provides a common framework for implementing and examining SAV mechanisms [8]. Research on IPv6 side channels, ICMP messages, and tunnels extends remote deployment inference [9,10,11]. OSAVRoute examines outbound filtering through observed forwarding behavior, while EZ-SAVE evaluates routing based policies under explicit traffic engineering assumptions [7,12]. Meanwhile, SAVNET documents separate source validation requirements from the limitations of forwarding tables [13,14]. These developments require a review that connects protocol claims to measurement evidence and deployment conditions.

We make four contributions. First, we present a taxonomy that identifies each mechanism’s authority, scope, enforcement location, and trust assumptions. Second, we compare measurement methods by the conclusions they support, including the conditions needed to infer filtering rather than merely a lack of response. Third, we define an evaluation contract for correctness, transient behavior, resource use, and incremental deployment. Fourth, we synthesize open problems in authorization, visibility, and incentives. The paper is a broad, auditable literature review; its coverage and evidence limits are explicit in Appendix A and Section 2.

2. Scope and Review Method

2.1. Research Questions and Inclusion Boundaries

The review covers approximately three decades of IP source validation, from 1996 to 22 October 2026. We retain work that contributes a validation mechanism, measures filtering or spoofing capability, evaluates deployment incentives, or specifies an applicable standard. The start year defines the search window; it does not imply that the earliest retained item appeared in 1996. RFC 2267, published in 1998, provides an early normative anchor within the window [1]. We include IPv4 and IPv6, access networks, enterprise and operator domains, and interdomain boundaries.

The unit of comparison is a technical contribution rather than a count of search hits. A conference paper and its journal extension can both appear when the extension adds analysis or operational evidence. We connect such versions in the discussion rather than treating them as independent deployment observations. Examples include SAVE and its extended treatment of incoming directions, IDPF and its journal analysis, and the sequence of Closed Resolver publications [6,15,16,17,18,19,20]. Standards remain separate from research papers because they express requirements or specified behavior rather than experimental confirmation.

We exclude application identity spoofing, email sender validation, and link layer impersonation when they do not establish an IP source binding. General DDoS detection is outside the core corpus unless it directly constrains forged sources or explains a measurement method. Traceback, source authentication, and path validation enter as adjacent work when they clarify the guarantee being offered. Likewise, route origin validation (ROV) and AS relationship inference are included only where they supply context or inputs to SAV. An improvement in route security is not counted as an observed improvement in packet source validation.

2.2. Search and Source Verification

Retrieval combines keyword search with citation chaining and primary source checks. Search terms include “source address validation,” “IP spoofing defense,” “ingress filtering,” “anti-spoofing,” “source authentication,” “SAVI,” “SAVNET,” “uRPF,” and the names of identified systems. Date focused queries cover earlier mechanisms and the 2023–2026 literature separately. We also inspect the references of early surveys and recent mechanism and measurement papers [7,12,21,22]. This procedure recovers work whose title does not contain the current term SAV.

We verify bibliographic and technical claims against conference proceedings, publisher records, author hosted papers, institutional repositories, RFC Editor documents, and versioned IETF records. Crossref title matching provides supplementary metadata; weak matches and rate limited requests are retained in the audit trail and are not accepted as evidence. Author publication lists establish the existence of otherwise inaccessible items. Such records do not establish their detailed algorithms, measured performance, or production deployment. For example, the verified listing of 3L-SAV supports inclusion as an APNOMS 2025 poster, but the retrieved material does not support a numerical comparison of its design [23].

The accompanying corpus contains 86 references: 62 papers or conference contributions, 14 RFCs, eight Internet Drafts, and two project or software resources. These categories count bibliographic records, not independent experiments. The local evidence archive distinguishes extracted full text from records or abstracts. Recent contributions such as UniSAV, OSAVRoute, and 3L-SAV directly address SAV or its evaluation [7,8,23]. Related work on relationship inference, ROV deployment, and route hijacking provides context under the narrower inclusion rule for adjacent research [24,25,26].

2.3. Evidence Limits and Reproducibility

This review does not claim exhaustive retrieval from subscription databases. It uses publicly accessible discovery and primary source verification; it does not perform a complete export from IEEE Xplore, the ACM Digital Library, Scopus, Web of Science, or CNKI. Search engine ranking, inaccessible full text, language coverage, and uneven publication metadata limit recall. The Chinese survey by Jia et al. broadens the historical search, but it does not make the present review an exhaustive survey of Chinese language work [22]. No fabricated screening counts or completeness percentage are supplied.

The paper separates published observations from analytical synthesis. Numerical results retain their source, population, and observation conditions. Proposed metrics, operational procedures, and research directions are our synthesis of the literature, not results of a new experiment. We record standardization state at the cutoff and cite draft revision numbers because an expired or superseded draft is not a stable specification. The appendix describes the artifact structure and explains how to extend the search without silently changing these boundaries.

3. Foundations and Security Semantics

3.1. What Does a Valid Source Mean?

A source is valid relative to an administrative and forwarding context. A host can be authorized to use an address on one attachment while the same address is invalid on another. A prefix can be legitimate behind a customer interface while an arbitrary host in that customer network still cannot legitimately impersonate every address in the prefix. SAV therefore needs a scope: host ownership, prefix membership, AS origin, or consistency with a permitted path. RFC 7039 explicitly distinguishes the fine granularity of SAVI from the network granularity of ingress filtering [27].

We represent a packet by $p=(s,d,i,c,t)$, where s and d are source and destination addresses, i is its receiving interface, c is context such as a virtual routing instance or encapsulation, and t is time. Let $A(i,c,t)$ be the set of sources authorized to arrive in that context. A validator approximates this set with an implemented set $\widehat{A}(i,c,t)$. Its basic decision is

$$V\left(p\right)=\mathbf{1}\{s\in \widehat{A}(i,c,t)\}.$$

(1)

This abstraction covers access control lists and reverse path checks directly. A cryptographic mechanism augments membership with proof verification; a behavioral detector uses observed features to estimate membership. The abstraction does not assume that a router knows the true set A.

The two fundamental errors arise from a difference between authorization and the implemented approximation. False acceptance occurs when a source belongs to $\widehat{A}\setminus A$; false rejection occurs when it belongs to $A\setminus \widehat{A}$. The terms correspond to the improper permit and improper block concerns in SAVNET [13,14]. They are not merely classifier terminology: false rejection can disconnect a customer, whereas false acceptance can permit an attack against a third party. Their costs fall on different actors.

3.2. Direction, Granularity, and Placement

Outbound SAV constrains packets leaving a named network; inbound SAV constrains packets entering it. The same physical check can be outbound validation from a customer’s perspective and ingress filtering from its provider’s perspective. We state the reference network explicitly to avoid this terminology trap. Inbound protection frequently includes rejecting externally arriving packets that claim an internal address, while outbound protection prevents local senders from using unauthorized external sources. Neither direction implies that the other is deployed [6,28].

Granularity determines the residual spoofing space. A filter that accepts a customer’s entire prefix does not distinguish two hosts in that prefix. A validator operating at an AS boundary does not necessarily separate two customers of the same AS. A host binding enforced only at a distant router can leave local traffic unprotected. An evaluation should therefore state the unit of authorization and the unit of enforcement separately. Figure 1 shows why the placement of a filter changes both its information and the traffic it can stop.

An early filter protects resources that a later filter cannot recover. Dropping a forged packet before it leaves an access network prevents it from consuming transit capacity or reaching a reflector. Dropping it at the victim cannot undo upstream congestion. Conversely, a destination can deploy an inbound policy without waiting for every possible source operator to act. These are different deployment advantages, not grounds for declaring either direction sufficient. Prefix validation and host validation are also complementary: coarse filtering reduces the attack surface while finer bindings restrict impersonation within the accepted prefix.

3.3. Threat Models and Adjacent Guarantees

An attacker model must distinguish a malicious host from a malicious network. A host may choose packet fields while its provider chooses the next hop. An AS may choose among several neighbors, manipulate its own routing policy, or corrupt the information from which a filter is built. A stronger adversary may also forge control messages or compromise credentials. EZ-SAVE explicitly separates spoofing hosts from spoofing ASes and excludes malicious control plane routing changes from its evaluated threat model [12]. Its findings therefore do not establish protection against every combined routing and spoofing attack.

ROV validates a prefix announcement’s origin AS against authorization data; SAV validates a packet source in an arrival context. RFC 6480 defines the resource public key infrastructure (RPKI), and RFC 6811 defines origin validation [29,30]. An authorized route origin does not prove that a particular packet was emitted by a host in that prefix. A spoofed packet can travel through a network whose BGP announcements are entirely legitimate. Conversely, a route hijack can redirect packets whose source addresses are authentic. Themis operates on route origin hijacking and legitimate versus illegitimate multiple origin events; it is adjacent evidence about routing context, not a SAV filter [26].

Source authentication can establish a stronger claim than route plausibility, but only within its stated trust boundary. Passport authenticates the source AS, which remains a coarser claim than host identity [31]. Path validation additionally checks traversal or path authorization, as explored by OPT and EPIC [32,33]. Traceback instead attempts to identify where traffic traveled or originated after observation. These guarantees can support one another, but none should inherit another’s security claim merely because all concern packet provenance.

3.4. A Running Asymmetry Example

A two provider customer illustrates why a destination route is incomplete evidence of source authorization. Let customer C own prefix P and connect to providers U and W. Suppose inbound traffic for P prefers U, but a packet sourced in P leaves through W. At an upstream router, the selected reverse route to P can point toward U even though the packet from W is legitimate. Strict reverse path validation can reject it. Loose validation accepts it if a qualifying route exists, but also accepts a forged source from another routed prefix. Feasible path mechanisms occupy the space between these choices [3,4].

The same example exposes temporal and contextual limits. During a link failure, the valid set of incoming interfaces can change before validation rules converge. A tunnel can carry an inner source whose authorization differs from that of the outer source. An anycast deployment can legitimately originate the same service address in several locations. A sound comparison must preserve these cases in the legitimate traffic set rather than eliminate them through a simplified routing model.

4. Evolution of the Research Problem

4.1. From Boundary Filtering to Path Information

Early standardization makes the source network a natural enforcement point. RFC 2267 and its successor RFC 2827 recommend restricting traffic entering a provider from a customer to legitimate customer sources [1,2]. This design uses information the adjacent operator can obtain and places the check before traffic spreads across the Internet. The recommendation does not create a global protocol for distributing source authorization. Its effectiveness depends on maintaining the appropriate local policy and deploying it on the relevant attachments.

Research in the early 2000s asks how much protection is possible away from the source. Route based distributed packet filtering (DPF) evaluates filtering in an AS topology and relates protection to placement and routing [34]. SAVE addresses a different information problem: routers learn where destinations are reachable, but need information about the interfaces from which sources should arrive [15]. Hop count filtering uses a destination’s observations of packet distance, while Pi uses path marking to identify traffic independently of the claimed source [35,36]. These branches already separate three forms of evidence: routing structure, explicit source propagation, and observed packet characteristics.

4.2. From Feasibility to Partial Deployment

Mid 2000s work moves deployment assumptions into the protocol design. SPM associates temporal keys with ordered source and destination networks [37]. IDPF derives feasible incoming neighbors from information available through BGP updates rather than requiring complete global routing knowledge [17,18]. BASE explicitly targets incremental deployability [38]. Passport combines source AS authentication with a key distribution design tied to routing [31]. Their mechanisms differ, but all confront the same question: what protection does a participant receive before every network participates?

Architectural and empirical work then exposes the limits of a single granularity. The SAVA testbed organizes validation at access, intra-AS, and inter-AS levels [39]. The 2009 spoofing defense survey systematizes competing approaches and their deployment barriers [21]. Comparative evaluation distinguishes benefits for participants from benefits for other networks [40]. Meanwhile, Spoofer measurements show why passing a coarse test does not establish host level enforcement [41]. These studies motivate evaluating both the remaining spoofable space and who receives the resulting protection.

4.3. Access Standards, Services, and Programmability

The 2010s develop distinct answers for distinct administrative boundaries. SAVI standardizes address bindings near hosts through FCFS, DHCP, SEND, and mixed assignment mechanisms [27,42,43,44,45]. Interdomain proposals explore deployable authentication, feedback, mutual protection, and filtering services [46,47,48,49,50]. Software defined networking introduces a way to separate the source of validation policy from distributed packet enforcement [51]. This changes implementation flexibility without resolving the authority question automatically.

Measurements also diversify beyond voluntary clients. DNS forwarding behavior, traceroute loops, and IXP observations provide evidence from networks that do not install a dedicated measurement agent [52,53,54]. Later analysis shows why interpreting such evidence requires care about business relationships and traffic direction at exchange points [55]. A measured anomaly becomes evidence of spoofing only after the observer rules out legitimate forwarding contexts that produce the same appearance.

4.4. Explicit Evaluation and Deployment Semantics

Recent work expands the observable dimensions of SAV. DNS based inbound studies, SMap, IPv6 rate limiting side channels, and ICMP based inference reduce dependence on controlled hosts in every tested network [9,10,19,56,57]. OSAVRoute adds evidence about outbound blocking depth and granularity [7]. These contributions expand measurement capability; they do not make their target populations interchangeable.

Recent mechanisms and frameworks put deployment diversity at the center of evaluation. pSAV treats validation as a service with subscribers, providers, and auditors [58]. SAV6 explores an IPv6 address design, and SAVA-X uses address domains to support finer interdomain validation [59,60]. UniSAV supports implementation and experimentation across mechanisms, while EZ-SAVE studies routing based policies under traffic engineering [8,12]. The field consequently needs a common vocabulary for guarantees and assumptions as much as it needs additional algorithms.

Table 1. Research lineage. Dates denote publication eras, not the start or end of a technique’s relevance.

Era	Main question	Representative contributions	Persistent qualification
1996–2000	Where can forged sources be stopped?	RFC 2267 and BCP 38 [1,2]	Local policy and complete attachment coverage are required.
2001–2004	What can routers infer about incoming sources?	DPF, SAVE, HCF, Pi, BCP 84 [3,15,34,35,36]	Reverse paths and legitimate forward paths can differ.
2005–2011	Can a subset of networks gain protection?	SPM, IDPF, BASE, Passport, SAVA, comparative evaluation [18,31,37,38,39,40]	A guarantee depends on placement, scope, and participating parties.
2012–2018	How can binding and deployment be made practical?	SAVI, FaaS, mutual protection, SDN, RISP [27,48,49,51,61]	Operational authority and incentives remain separate design problems.
2019–2023	What is deployed, and what changes it?	Spoofer longitudinal study, IXP analysis, inbound probes, RCT, iVantage [6,9,28,55,62]	Observation and causation require different evidence.
2024–2026	How can guarantees and evaluations be aligned?	UniSAV, ICMP_Sonar, 6in4, OSAVRoute, EZ-SAVE, SAVNET [7,8,10,11,12,13]	Broader coverage and realistic models still have explicit boundaries.

Table 1. Research lineage. Dates denote publication eras, not the start or end of a technique’s relevance.

Era	Main question	Representative contributions	Persistent qualification
1996–2000	Where can forged sources be stopped?	RFC 2267 and BCP 38 [1,2]	Local policy and complete attachment coverage are required.
2001–2004	What can routers infer about incoming sources?	DPF, SAVE, HCF, Pi, BCP 84 [3,15,34,35,36]	Reverse paths and legitimate forward paths can differ.
2005–2011	Can a subset of networks gain protection?	SPM, IDPF, BASE, Passport, SAVA, comparative evaluation [18,31,37,38,39,40]	A guarantee depends on placement, scope, and participating parties.
2012–2018	How can binding and deployment be made practical?	SAVI, FaaS, mutual protection, SDN, RISP [27,48,49,51,61]	Operational authority and incentives remain separate design problems.
2019–2023	What is deployed, and what changes it?	Spoofer longitudinal study, IXP analysis, inbound probes, RCT, iVantage [6,9,28,55,62]	Observation and causation require different evidence.
2024–2026	How can guarantees and evaluations be aligned?	UniSAV, ICMP_Sonar, 6in4, OSAVRoute, EZ-SAVE, SAVNET [7,8,10,11,12,13]	Broader coverage and realistic models still have explicit boundaries.

5. Validation Mechanisms

5.1. A Taxonomy Based on Evidence

The most useful division between SAV mechanisms is the evidence that supplies the acceptance rule. We distinguish five families: local allocation and attachment state; routing information; explicit source information exchange; cryptographic source or path evidence; and learned traffic behavior. A system can combine several families. The taxonomy therefore classifies the validation decision rather than forcing every implementation into one exclusive category. Table 2 summarizes the principal tradeoffs.

We compare mechanisms along six axes: authority, granularity, enforcement location, update trigger, cooperation requirement, and failure mode. Authority identifies who can assert that an address is valid. Granularity states whether the assertion covers a host, prefix, AS, or path. Enforcement identifies where a packet is checked. Update triggers include lease changes, routing events, protocol messages, and observation. Cooperation distinguishes a local configuration from a change requiring other networks. Failure mode asks what happens when evidence is incomplete, stale, forged, or unavailable. This decomposition prevents an implementation convenience from being mistaken for a security guarantee.

5.2. Local Prefix Lists and Address Bindings

Static prefix lists exploit a simple administrative relationship. A provider can permit the prefixes assigned to a directly attached customer and reject other sources arriving from that customer. A customer can apply the equivalent restriction before transmission. BCP 38 describes this operational principle [2]. Its precision is bounded by the accuracy and granularity of the list. An unrecorded allocation change creates false rejection; an obsolete permit creates residual spoofing opportunity. The list also needs an explicit exception policy for cases such as infrastructure addresses and encapsulated traffic.

SAVI brings the authority boundary closer to the host. Its framework binds an address to an attachment anchor and enforces that binding on the data path [27]. FCFS SAVI handles locally assigned IPv6 addresses through observation and binding state [42]. DHCP SAVI derives bindings from address assignment exchanges [44]. SEND SAVI uses the Secure Neighbor Discovery setting, while RFC 8074 addresses coexistence when more than one assignment method operates on a link [43,45]. These mechanisms address host impersonation inside a prefix that a border filter would already accept.

The attachment anchor is part of the security model. A binding to a shared or spoofable attribute is weaker than a binding to a controlled port or authenticated attachment. Changes in host location, switch topology, or assignment method require binding migration or removal. A restart can leave the device without complete state, and a delayed control message can recreate obsolete state. The threat scope document identifies why a SAVI implementation must consider both local attackers and its trusted components [63]. Filtering correctness cannot be evaluated solely after all bindings have stabilized.

Programmable networks make binding installation more flexible but create new state synchronization obligations. The SIGCOMM short paper on source validation in software defined networks introduces this implementation direction [51]. D-SAVI develops a dynamic framework intended to reduce resource overhead in an SDN setting [64]. The controller still needs authoritative address information, and switches still need safe behavior while updates are pending. A faster rule distribution channel cannot repair an incorrect binding supplied to it. Evaluation should separate control channel delay, switch update delay, and rule correctness.

5.3. Reverse Path and Routing Based Filtering

Strict unicast reverse path forwarding (uRPF) accepts a packet only when its incoming interface is consistent with the qualifying reverse route to its source. This is attractive because the forwarding system already maintains routing state. It works naturally where the topology and policy align source traffic with reverse reachability. It fails under legitimate asymmetry when the selected return path differs from the arrival path. RFC 3704 explains this limitation in multihomed environments [3]. Strictness is therefore a property of the acceptance predicate, not a universal measure of security quality.

Loose uRPF trades interface discrimination for reachability. It checks whether the source has a qualifying route, subject to the implementation’s handling of default and other route types. It can reject unrouted source space while admitting a forged address from a routed prefix. This is a useful but narrower guarantee than source authorization. A study that tests only unrouted or private addresses can consequently report successful filtering even when routed address spoofing remains possible. Evaluations must specify which source classes the test covers.

Feasible path uRPF broadens the permitted incoming interfaces beyond the selected best route. Its effectiveness depends on which alternative routes the router learns and retains. Enhanced feasible path uRPF (EFP-uRPF) uses additional associations among customer routes and origin ASes to accommodate cases where conventional feasible path checks are incomplete [4]. The relevant comparison is the resulting allowed set under an explicit export policy. A label such as “feasible” does not guarantee that every legitimate forwarding path is represented in the available control plane state.

DPF and IDPF make the routing information problem explicit. DPF evaluates the potential of placing route based filters within an AS graph [34]. IDPF uses the constraints implicit in BGP updates and export policies to infer permissible incoming neighbors [17,18]. Its correctness argument is conditional on the routing policy model. If a legitimate commercial arrangement violates that model, an arrival can appear impossible even though the network intentionally carries it. Policy assumptions must therefore accompany any reported filtering gain.

AS relationship information improves interpretation only to the extent that it represents the actual forwarding context. Customer cones can help constrain sources on a customer facing interface, but a provider facing interface can carry traffic from a much broader set. Trusted seed and semisupervised relationship inference, including the INFOCOM 2026 work by Teng et al., addresses the quality of inferred relationship data [24]. We include that work as an input quality connection. Its title and publication record do not establish the accuracy of a downstream SAV system, and inferred relationships remain different from explicit authorization.

BAR-SAV combines BGP updates with ASPA and ROA information to construct validation policy [65]. Its significance is the attempt to supplement observed routing with authenticated resource and provider information. ROAs authorize origins, while provider authorization constrains a different relationship; neither should be interpreted as a direct certificate for an individual packet’s physical path. The draft specifies how those inputs contribute to the policy. Missing objects, inconsistent objects, and incomplete coverage still require defined behavior. EZ-SAVE’s evaluation provides evidence within its modeled topology and traffic engineering settings, rather than a proof for arbitrary policies [12].

5.4. Explicit Source Information Exchange

Explicit signaling addresses the information that destination routing does not provide. SAVE propagates source validity information so that routers can maintain incoming tables, and its extended study develops the learning of valid incoming directions [15,16]. A key benefit is the ability to reason about source paths without assuming that the selected reverse route is the correct arrival direction. The cost is a separate control mechanism whose correctness, authentication, and convergence must be evaluated.

Feedback and incremental designs explore how that information can be acquired without immediate universal adoption. BASE frames a mechanism around deployability, while Umbrella explicitly uses routing choice feedback [38,47]. The work on realizing a source authentic Internet extends the discussion of incrementally available source information [66]. These proposals should be compared by what a nonparticipating region hides, whether evidence can traverse that region, and what a participating boundary does when no source information exists. Missing participation cannot be silently converted into a definitive rejection rule.

SAVNET revisits explicit source information in both intra and interdomain settings. Its problem statements focus on reducing improper permits while avoiding improper blocks, and its architecture drafts separate the generation of source validation information from enforcement [13,14,67,68]. Within one operator, administrative control can simplify trust establishment and deployment sequencing. Across operators, authority, confidentiality, and partial adoption require additional treatment. The same protocol message format cannot by itself remove that difference in trust.

Hierarchical networks require a correspondence between validation scope and operator structure. RFC 5210’s SAVA architecture already distinguishes access, intra-AS, and inter-AS validation [39]. The title and author record of 3L-SAV identify a later framework aimed at hierarchical operator networks [23]. Because its full paper was not retrieved, we do not assign particular functions to its three layers or claim an evaluation result. The defensible comparison is its stated deployment setting and the broader need to coordinate local bindings with domain boundary rules.

5.5. Cryptographic and Packet-Carried Evidence

Cryptographic evidence changes the question from whether a source is plausible to whether a trusted participant produced the required proof. SPM associates temporary keys with ordered AS pairs and tags traffic for validation at the receiving side [37]. Passport uses symmetric cryptography to allow participating ASes to validate source AS information, with key establishment integrated into its routing design [31]. These mechanisms require accounting for key distribution, renewal, packet overhead, and the behavior of paths that include nonparticipants. An authenticated assertion has value only when the asserting party is authoritative for the claimed scope.

Authentication at the network boundary does not establish which host generated a packet. A compromised participant can still originate claims within the scope it controls, and a host may spoof another host in the same accepted AS unless finer checks exist. SAVAH instead applies the Host Identity Protocol at an access router to support local source validation [69]. The deployable inter-AS approach by Liu et al. also treats incremental deployment as a first class design requirement [46]. Cross paper comparisons need to preserve whether the protected identity is a host or an administrative domain.

Some related designs combine source evidence with protection against reflection or path misuse. RAD distinguishes local and core deployment of message authentication code based protection [70]. LOT addresses spoofing and flooding together [71]. OPT and EPIC address source authentication alongside path validation [32,33]. AIP changes the addressing architecture around accountability [72]. These systems inform the stronger guarantees that an Internet architecture can offer, but their adoption and packet format requirements differ from those of an existing router’s ingress filter.

SAVA-X uses an address domain abstraction to obtain finer granularity than treating an entire AS as a single validation unit [60]. This is relevant when one operator contains independently managed allocations or when a prefix level relationship better captures authorization. SAV6 takes a different approach by incorporating AS information into IPv6 addresses and checking its correspondence with announced prefixes [59]. Structured addresses can expose information useful for validation, but their benefit depends on the protocol’s complete rules, allocation assumptions, and migration behavior. Address structure alone is not proof that the sender possesses an authorized identity.

5.6. Observed Behavior and Packet Marking

Behavioral evidence can support local filtering without a new universal trust infrastructure. Hop count filtering learns expected distance information and tests whether an arriving packet is consistent with it [35,73]. A TTL based observation is not a cryptographic credential: an attacker controls the initial TTL, and legitimate paths can change. Its security claim is therefore detection under the tested traffic and attacker assumptions, not authentication of every packet. The journal extension should be read as part of the same mechanism lineage rather than as an independent architecture.

Path marking supplies a different source independent feature. Pi embeds path information so that a destination can associate packets that traverse similar paths; StackPi develops additional marking and filtering mechanisms [36,74]. Such evidence can help filter attack traffic despite forged sources. It does not necessarily authorize a claimed source address, and partial deployment changes the information preserved in a mark. A comparison must distinguish identifying an attack path from proving address ownership.

RESECT combines expected route information with a sender’s response to selected drops and learns filtering behavior as routes change [75]. This is attractive where static route assumptions are insufficient. Its interpretation depends on traffic behavior: a response attributed to a legitimate sender must remain distinguishable from an attacker’s imitation or unrelated loss. Learned state also needs safeguards against poisoning. Behavioral methods are best evaluated as conditional decision systems, with explicit adaptation time and collateral loss, rather than as replacements for all forms of address authority.

6. Measuring Validation in the Internet

6.1. What an Observation Establishes

SAV measurement is an inference problem with unequal evidence for success and failure. If a controlled receiver obtains a packet with a deliberately unauthorized source, the tested path permits that forgery. If the receiver obtains nothing, filtering is only one possible cause. A test needs controls for reachability, endpoint behavior, transmission capability, and response observation before assigning a filtering label. Even a correct label applies to the tested source class and path at the measurement time, not automatically to an entire AS.

We use three outcome labels: permissive, filtering inferred, and inconclusive. “Permissive” requires a positive observation of the tested forgery or its validated consequence. “Filtering inferred” requires the method’s control conditions to hold and its alternative explanations to be addressed. “Inconclusive” preserves unresolved cases. Removing the third category can inflate either apparent deployment or apparent vulnerability, depending on which binary label absorbs the missing observations. Table 3 compares the main methods using these semantics.

6.2. Cooperative Active Measurement

The Spoofer project tests packet transmission from participating hosts and provides direct evidence about those hosts’ network paths [5,76]. A cooperative client can vary source classes and work with controlled receivers. This makes it possible to examine both whether spoofing succeeds and where filtering behavior changes. Its main sampling constraint is participation: networks without willing or reachable clients are not a random subset of the Internet. Additional clients can improve coverage while still leaving adoption bias.

The 2009 study demonstrates the importance of source granularity. Among clients able to test their provider’s filtering, 31% could spoof an arbitrary routable source; among clients otherwise unable to spoof, 77% could forge a source within their own /24 [41]. These are historical, conditional client results. They show that blocking external prefixes can coexist with permissive behavior inside an accepted subnet. They do not estimate the fraction of all present day networks with either property.

Longitudinal cooperative data adds temporal evidence without eliminating selection effects. In the year ending August 2019, the Spoofer study found that at least a quarter of tested ASes allowed outbound spoofing, and at least two thirds allowed tested inbound sources that claimed to be internal [28]. Its NAT observations also show that address translation is not a substitute for SAV. Crowdsourcing marketplaces provide another way to recruit measurement locations, but introduce recruitment and participant selection questions of their own [77]. Repeated tests and broader geography must be reported separately from representativeness.

6.3. Remote Inbound Inference

DNS based measurement exploits a resolver’s observable action after receiving a probe. A query that appears to originate inside the target network can cause a resolver to contact an authoritative server controlled by the researcher. The resulting request provides evidence that the forged query reached a useful target. The PAM and ANRW studies develop this approach, and the Closed Resolver journal study extends its treatment across IPv4 and IPv6 [6,19,20]. The available outcomes depend on the resolver’s configuration and on suitable comparison queries; an absent authoritative request alone is not proof of filtering.

Closed resolver behavior is security relevant even when the resolver does not answer arbitrary external clients. A source forged to resemble an internal client can cross an address based access boundary if inbound validation is missing. Deccio et al. examine this interaction between spoofing and apparent DNS isolation [56]. The lesson is that an application access list relying on internal source addresses needs a network boundary that enforces those addresses. Application closure and network source authenticity are separate properties.

Side channels extend inference beyond DNS resolver populations. SMap observes global IP identification behavior to determine whether spoofed traffic reaches suitable IPv4 systems [57]. Its observable population is constrained by the required counter behavior. iVantage uses ICMP rate limiting to obtain remote observations in IPv6, where the IPv4 header’s IPID mechanism does not apply in the same way [9]. Its paper reports approximately 50% coverage of IPv6 ASes and approximately 79% vulnerability among the measured ASes. Those figures describe that method’s campaign and eligibility conditions, not an address family wide census.

ICMP based inference also uses changes in protocol state as an observable effect. ICMP_Sonar employs crafted ICMP messages to infer inbound SAV and expands the population observable by its method [10]. The question for cross study comparison is which routers or hosts respond in a usable way and which alternative causes can produce the measured change. A protocol side effect is evidence only after validating the causal chain from arrival of the spoofed message to the response that the scanner sees.

Identifying a filter’s implementation requires stronger inference than identifying a filtering outcome. The PAM 2024 work by Schulmann and Zhao uses predictive analysis of global IPID counters to investigate SAV implementation, including ACL and uRPF behavior [78]. The distinction matters operationally because two filters can reject the same initial probe and react differently to a route change. An inferred implementation category must retain the experiment’s discrimination assumptions; externally indistinguishable configurations cannot be uniquely identified from an identical response.

6.4. Remote Outbound Inference

Remote outbound measurement needs traffic to emerge from the tested network without placing a cooperative client inside it. DNS proxy observations and traceroute loops provide such opportunities in particular configurations [52,53]. Transparent forwarders are especially relevant because forwarding can preserve an original source while changing the destination [79]. These techniques give useful positive evidence of permissive behavior, but an inability to find an eligible device or loop does not demonstrate that the network filters outbound traffic.

OSAVRoute uses transparent forwarding behavior and path observations to distinguish packet generation from subsequent propagation [7]. Its reported validation accuracy is 99.4%, and it finds absent outbound SAV in 84.2% of its tested ASes. It also examines blocking depth and granularity. The scope qualifier is essential: eligible forwarders, observable paths, and the study’s validation set define those numbers. They should not be combined with older voluntary client estimates to claim a global increase in spoofing.

Tunnels couple two address families and create another observation opportunity. Guo et al. use 6in4 tunnels to measure IPv4 inbound SAV and IPv6 outbound SAV [11]. The author record reports observations from 12,417 and 2,104 ASes respectively. A tunnel is both an enabling instrument and a sampling filter: only networks exposing the required behavior are observable. The outer IPv4 boundary and the inner IPv6 boundary must be tracked separately. Otherwise a rejection on one layer can be misattributed to a policy on the other.

6.5. Passive Observation at Exchange Points

An IXP provides broad traffic visibility but not automatic knowledge of source authorization. Lichtblau et al. classify observed interdomain traffic using source addresses and routing context [54]. Mueller et al. subsequently show why business relationship semantics matter for deciding whether traffic falls outside an expected source set [55]. In particular, traffic from a provider to a customer can legitimately have a source far outside the provider’s customer cone. A classifier that applies the wrong directional expectation can label legitimate transit as spoofing.

Passive measurements answer a different question from active permissiveness tests. They estimate properties of traffic actually observed at a particular location and time. They cannot establish that a network would block a source that never appears in the captured sample. A network can have permissive configuration without carrying a visible attack during the observation interval. Conversely, a small number of networks can contribute a large traffic volume. Traffic weighted, address weighted, and AS weighted results should therefore remain separate.

Table 3. Measurement capability and inferential boundary. “Conditional” means that controls and method specific assumptions are required; silence alone is insufficient.

Method	Direction	Required observation resource	Evidence produced	Principal interpretation limit
Spoofer [5,41]	Out/in	Client and controlled measurement infrastructure	Permissiveness; conditional filtering; selected granularity/path tests	Volunteer population; tested attachment and source classes
DNS forwarders [52,79]	Out	Eligible transparent forwarding behavior	Positive evidence of permissiveness	No eligible forwarder does not imply filtering
Traceroute loops [53]	Out	Eligible loops in route observations	Positive evidence under validated loop interpretation	Addressing conventions and path ambiguity
IXP analysis [54,55]	Traffic crossing IXP	Traffic records and appropriate routing context	Observed traffic inconsistent with expected source set	Transit relationships; missing routes; no test of unseen traffic
Closed resolver [6]	In	Resolver behavior and authoritative DNS observation	Permissiveness; conditional filtering for testable targets	Resolver policy and reachable comparison queries
SMap / SAVscan [57,78]	In	Eligible IPID counter behavior	Arrival inference; selected implementation characteristics	Counter eligibility, background traffic, model error
iVantage [9]	In, IPv6	Observable ICMP rate limiting side channel	Conditional packet arrival inference	Rate limiter implementation and remote path effects
ICMP_Sonar [10]	In	Observable effect of crafted ICMP messages	Conditional inbound validation inference	Protocol state eligibility and confounding effects
6in4 [11]	IPv4 in / IPv6 out	Eligible tunnel behavior	Validation outcomes across encapsulation boundary	Tunnel population; attribution to inner versus outer layer
OSAVRoute [7]	Out	Transparent forwarding and path observation	Conditional presence/absence, depth, granularity	Eligibility, response visibility, local validation conditions

Table 3. Measurement capability and inferential boundary. “Conditional” means that controls and method specific assumptions are required; silence alone is insufficient.

Method	Direction	Required observation resource	Evidence produced	Principal interpretation limit
Spoofer [5,41]	Out/in	Client and controlled measurement infrastructure	Permissiveness; conditional filtering; selected granularity/path tests	Volunteer population; tested attachment and source classes
DNS forwarders [52,79]	Out	Eligible transparent forwarding behavior	Positive evidence of permissiveness	No eligible forwarder does not imply filtering
Traceroute loops [53]	Out	Eligible loops in route observations	Positive evidence under validated loop interpretation	Addressing conventions and path ambiguity
IXP analysis [54,55]	Traffic crossing IXP	Traffic records and appropriate routing context	Observed traffic inconsistent with expected source set	Transit relationships; missing routes; no test of unseen traffic
Closed resolver [6]	In	Resolver behavior and authoritative DNS observation	Permissiveness; conditional filtering for testable targets	Resolver policy and reachable comparison queries
SMap / SAVscan [57,78]	In	Eligible IPID counter behavior	Arrival inference; selected implementation characteristics	Counter eligibility, background traffic, model error
iVantage [9]	In, IPv6	Observable ICMP rate limiting side channel	Conditional packet arrival inference	Rate limiter implementation and remote path effects
ICMP_Sonar [10]	In	Observable effect of crafted ICMP messages	Conditional inbound validation inference	Protocol state eligibility and confounding effects
6in4 [11]	IPv4 in / IPv6 out	Eligible tunnel behavior	Validation outcomes across encapsulation boundary	Tunnel population; attribution to inner versus outer layer
OSAVRoute [7]	Out	Transparent forwarding and path observation	Conditional presence/absence, depth, granularity	Eligibility, response visibility, local validation conditions

6.6. Combining Measurements Without Overclaiming

Multiple instruments improve diagnosis when their disagreements are preserved. A cooperative client might find filtering at one attachment while a remote method finds permissive behavior at another. That result need not mean either instrument is wrong. The network can have mixed deployment, different source classes, or policy changes between observations. A joint dataset should retain the original observations before deriving a summary label. If an AS has at least one demonstrated permissive interface, the correct summary is evidence of partial vulnerability, not a claim that every interface lacks SAV.

Measurement fusion should use a shared observation schema. At minimum it should record time, address family, tested source prefix, destination, direction relative to a named network, vantage point, target eligibility, control results, and outcome confidence. Route and interface mapping versions are also necessary when attributing a result to an AS. Publishing only a binary AS list discards the evidence needed to reconcile contradictory studies. A confidence field must describe a validated inference procedure rather than a decorative score.

Responsible measurement protects both validity and operational trust. Probe rates, target exclusion, contact information, retained identifiers, and data release policies should be documented. Tests should minimize unintended protocol state changes and avoid treating incidental third parties as attack recipients. These practices do not strengthen a weak inference by themselves, but they determine whether an experiment can be repeated and whether operators can investigate its results. This survey reviews published experiments and performs no active spoofing measurement.

7. An Evaluation Contract for SAV

7.1. Correctness Requires a Defined Traffic Universe

Filtering accuracy is meaningful only relative to a stated legitimate and adversarial workload. Let L and S be legitimate and spoofed packet sets under a declared authorization policy. For nonempty sets, define

$$\begin{array}{cc}\hfill \mathrm{FRR}& ={\displaystyle \frac{\left|\right\{p\in L:V\left(p\right)=0\left\}\right|}{\left|L\right|}},\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill \mathrm{FAR}& ={\displaystyle \frac{\left|\right\{p\in S:V\left(p\right)=1\left\}\right|}{\left|S\right|}}.\hfill \end{array}$$

(3)

FRR is the false rejection rate and FAR is the false acceptance rate. If either denominator is zero, the corresponding rate is undefined and should not be reported as zero. The workload must identify whether a packet represents an actual traffic sample, a uniformly selected prefix pair, an AS pair, or a synthetic attack opportunity.

Weighting changes the claim made by an error rate. A packet weighted rate estimates effects under a traffic distribution. A prefix weighted rate gives equal importance to prefixes regardless of traffic. An AS weighted rate gives equal importance to networks of very different size. No one weighting replaces the others. A low average FRR can hide a complete outage for a small customer; a low average FAR can hide a large reachable reflector population. Reporting per class outcomes and worst affected groups makes these failure patterns visible.

The adversary’s allowed choices should be part of the benchmark specification. A malicious host may be limited to one egress route, while a malicious AS may choose among several neighbors. Source classes should include routed external addresses, unrouted addresses, addresses inside the attacker’s own permitted prefix, and addresses associated with the destination network. A benchmark restricted to one class cannot establish protection for the others. Comparative work already distinguishes several dimensions of protection; newer studies should retain that discipline when adding new mechanisms [40].

7.2. Time and Update Safety

Steady state correctness is insufficient when routing and assignment change. Let $A_t$ and ${\widehat{A}}_t$ denote actual and implemented authorization sets. We propose measuring the duration and extent of their disagreement during an event, rather than reporting convergence time alone. An update can converge quickly after temporarily rejecting all traffic; another can converge slowly while keeping legitimate traffic available. These outcomes have different operational costs even if their final rules are identical.

Update experiments should include withdrawal, failover, new allocation, host movement, controller restart, and delayed or reordered messages. The observer needs a timeline for the source of truth, rule generation, rule installation, and packet behavior. A routing event time is not necessarily the time at which the new forwarding path becomes active. Measuring only control message arrival can miss a data plane inconsistency. This is particularly relevant when a centralized application computes rules but several devices apply them at different times.

Safe updates involve a tradeoff between temporary permission and temporary rejection. An implementation that installs newly valid sources before removing obsolete permissions favors availability but creates a temporary acceptance window. Reversing that order can reduce the acceptance window while dropping legitimate traffic. Neither choice should be hidden behind an average latency. A benchmark should state the update policy, bound the exposure where possible, and test rollback after incomplete installation. These are proposed evaluation requirements, not established guarantees of the systems reviewed here.

7.3. Topology and Traffic Engineering

A topology model must represent the policies that affect source arrival. The running example in Section 3 requires selective prefix export and asymmetric forwarding; a model that always announces every prefix to every provider removes the difficult case. Partial transit, sibling networks, backup links, route servers, and anycast introduce further distinctions. A synthetic AS graph without these semantics can measure an algorithm precisely while answering the wrong operational question.

EZ-SAVE provides a recent example of evaluating routing based policies with traffic engineering in the model [12]. Its results favor BAR-SAV among the evaluated designs under those assumptions. The general lesson is methodological: rankings can depend on which legitimate policies the simulator allows. The result should not be restated as universal optimality, particularly when the attack model excludes control plane manipulation. Authors should release the topology snapshot, policy generator, routing state, source selection, and implementation of every compared acceptance predicate.

Inferred AS relationships are another source of uncertainty. Treating every inferred edge label as ground truth can make a filtering policy appear more precise than it is. A useful sensitivity analysis deliberately changes uncertain labels or hides selected routing observations, then measures resulting false rejection and false acceptance. Better relationship inference can reduce an input error, but it does not establish that an operator authorizes every path predicted by that inferred model [24]. Authorization and inference should be evaluated separately before their combined effects are reported.

7.4. Implementation and Resource Cost

Implementation benchmarks should separate rule computation from packet processing. Computation cost depends on prefix count, relationships, update rate, and the amount of retained alternate state. Packet processing cost depends on the lookup representation, cache behavior, hardware pipeline, packet size, and any cryptographic work. A result reported only as packets per second is incomplete without traffic mix and hardware information. A result reported only as rule generation time is incomplete without the time needed to install and activate those rules.

Memory cost should include both steady state tables and transient update state. A mechanism that keeps several rule generations during safe replacement can consume more memory than its final rule count suggests. A compressed representation may save space while increasing update work or broadening accepted prefixes. A programmable implementation may use resources shared with forwarding and other security functions. The relevant question is whether the router can sustain validation together with its normal responsibilities, not whether a standalone microbenchmark fits in a laboratory device.

UniSAV and its SAV Open Playground artifact support a common implementation environment for comparing mechanisms [8,80]. Such an environment reduces accidental differences in plumbing, traffic generation, and rule installation. It cannot make an incorrect policy model realistic, and it does not replace testing on representative hardware. Emulation, simulation, and deployment experiments answer complementary questions. Reproducibility improves when the same policy semantics can be exercised across those settings without silently changing the predicate.

Table 4. Minimum reporting contract proposed by this survey. A missing item limits the claim that an evaluation can support.

Dimension	Required disclosure	Failure exposed
Authorization	Who authorizes which source, at which interface, context, and time	Confusion between route reachability and source entitlement
Workload	Legitimate/forged labels; packet, prefix, or AS weighting; source classes	High accuracy caused by an easy or narrow test distribution
Attacker	Host/AS control; neighbor choice; routing manipulation; credential access	Security claim that exceeds tested adversary power
Topology/policy	Snapshot, relationships, selective export, TE, tunnels, route servers	False rejection hidden by an oversimplified routing model
Dynamics	Event sequence, installation timing, loss, stale permits, rollback behavior	Correct final tables masking unsafe transitions
Resources	Hardware, table size, CPU, memory, throughput, latency, update churn	Isolated microbenchmark masking system bottlenecks
Partial deployment	Placement, adopter benefit, nonadopter benefit, bypass paths	Adoption percentage masking ineffective filter placement
Measurement validation	Eligibility, controls, ground truth, inconclusive outcomes	Nonresponse interpreted as proof of filtering
Reproducibility	Code/version, configuration, input data, random seeds, exclusions	Numerical result that cannot be independently reconstructed

Table 4. Minimum reporting contract proposed by this survey. A missing item limits the claim that an evaluation can support.

Dimension	Required disclosure	Failure exposed
Authorization	Who authorizes which source, at which interface, context, and time	Confusion between route reachability and source entitlement
Workload	Legitimate/forged labels; packet, prefix, or AS weighting; source classes	High accuracy caused by an easy or narrow test distribution
Attacker	Host/AS control; neighbor choice; routing manipulation; credential access	Security claim that exceeds tested adversary power
Topology/policy	Snapshot, relationships, selective export, TE, tunnels, route servers	False rejection hidden by an oversimplified routing model
Dynamics	Event sequence, installation timing, loss, stale permits, rollback behavior	Correct final tables masking unsafe transitions
Resources	Hardware, table size, CPU, memory, throughput, latency, update churn	Isolated microbenchmark masking system bottlenecks
Partial deployment	Placement, adopter benefit, nonadopter benefit, bypass paths	Adoption percentage masking ineffective filter placement
Measurement validation	Eligibility, controls, ground truth, inconclusive outcomes	Nonresponse interpreted as proof of filtering
Reproducibility	Code/version, configuration, input data, random seeds, exclusions	Numerical result that cannot be independently reconstructed

7.5. Partial Deployment and Composable Protection

Deployment percentage is not a complete description of protection. Ten percent of networks selected by degree can cover a different set of paths from ten percent selected uniformly or by customer count. A single filter on a frequently used path can matter more than many filters outside the attacker’s available paths. Evaluation should report filter placement, the traffic or source set protected, and the protection received by participating and nonparticipating networks. This connects the technical comparison to the incentive question.

Composing filters changes errors asymmetrically. Along a fixed path with serial filters, a packet is accepted only if every filter accepts it:

$$V_{\mathrm{path}}\left(p\right)={\displaystyle \prod _{j=1}^m}{V}_j\left(p\right).$$

(4)

Under that fixed path assumption, adding a filter cannot enlarge the accepted packet set. It can still increase false rejection. In a network with alternate paths, the attacker may exploit a path whose filters permit the forgery. A composition result for one path therefore does not automatically establish network wide coverage. This distinction helps explain why local correctness, path coverage, and Internet scale effectiveness require separate evidence.

8. Deployment, Incentives, and Operations

8.1. Who Pays and Who Receives Protection?

Outbound SAV creates a deployment externality. The operator pays for configuration, verification, and the risk of a mistake, while much of the benefit accrues to destinations that no longer receive forged traffic. Inbound filtering can provide a more direct benefit by blocking traffic that impersonates internal sources, but it covers a different threat set. A deployment argument must identify the protected party rather than assume that a social benefit automatically motivates an individual operator.

Research on incremental protection attempts to alter that distribution of benefits. FaaS treats filtering as a service, and work on incentivizing deployment and distributed collaboration explores mutual protection across ASes [48,49,50]. iSAP frames protection of a network’s own source space as a deployment incentive; RISP uses an RPKI based trust foundation for inter-AS source protection [61,81]. These proposals make the incentive explicit. Their economic argument still depends on service value, participant behavior, and enforceable relationships, not just the fraction of packets a filter rejects.

pSAV further separates service subscribers, providers, and auditors, using a blockchain based control plane and programmable data plane in its prototype [58]. That division gives a concrete place to represent payment and service verification. It also introduces questions about whether an audit demonstrates actual filtering, how disputes are resolved, and whether the control system reflects changing network state. SAV-D explores a distributed defense architecture designed to gain protection with incremental deployment [82]. Neither a service transaction nor participation in an architecture should be treated as proof that every relevant interface enforces the intended policy.

8.2. Notification, Association, and Causation

An observed improvement after notification is not by itself an estimate of notification effectiveness. Networks can change for reasons unrelated to the message, and networks that respond are not necessarily representative of those that do not. The randomized control trial by Lone et al. finds no significant improvement from its tested notification treatments relative to its control group [62]. That result concerns those treatments and that study population. It does not prove that every possible operational intervention fails.

Longitudinal observational studies and randomized interventions serve different purposes. The former reveal persistence, mixed deployment, and remediation events; the latter can estimate the effect of a specified intervention under a controlled design. The Spoofer longitudinal study supplies evidence of continuing deployment gaps and the difficulty of remediation [28]. A useful followup study would distinguish lack of awareness from lack of resources, lack of configuration authority, and fear of connectivity loss. These explanations call for different interventions.

Routing security studies offer relevant operational comparisons without replacing SAV evidence. Qin et al. examine partial ROV deployment, operator constraints, and notifications in the context of MANRS Action 1 [25]. SAV involves packet filtering and has a separate operational action. We use the ROV study to motivate attention to interface placement and economic constraints, not to transfer its measured remediation rate or technical recommendation to SAV. Similarly, a correlation between community participation and SAV observations does not establish that membership caused filtering.

8.3. A Deployment Procedure Derived from the Literature

An operator should begin by identifying the authority behind each permitted source. For customer boundaries, this includes assigned prefixes and any delegated or separately originated space. For host access, it includes address assignment and attachment information. For tunnels and virtual networks, it includes the distinction between inner and outer addresses and between routing instances. An inventory of configured interfaces is insufficient if it omits the reason that each source is allowed. This procedure is our synthesis, not a measured best performing rollout strategy.

Observation before enforcement helps expose policy mismatches. A candidate rule set can record the packets it would reject while forwarding remains active. Operators can then classify those observations against routing changes, legitimate asymmetry, address migration, and actual misuse. An observation interval does not prove that every future legitimate path has been seen. It does provide a concrete basis for correcting known mismatches before enforcement and for documenting the residual assumptions.

Deployment should proceed with rollback and verification at each boundary. An operator can start where allocation authority and attachment are well understood, then expand to more complex transit or multihomed cases. Verification should test permitted sources, unauthorized sources, and relevant changes in routing or assignment. Monitoring must distinguish a drop caused by SAV from a drop caused by unrelated policy. If the system cannot explain a drop, incident response may disable a correct control to restore service.

IPv6 requires its own operational inventory and tests. Multiple addresses per interface, privacy addresses, address lifetime changes, and transition mechanisms affect the mapping from hosts to valid sources. IPv6 operational guidance discusses the broader security context in which these features operate [83]. A successful IPv4 SAV audit does not establish IPv6 enforcement, and an IPv6 tunnel can cross a boundary whose outer address policy differs from its inner address policy. Dual stack reporting should retain two sets of results and their relationship.

8.4. Cloud, Virtualization, and Administrative Boundaries

Virtualization multiplies the contexts in which an address can be valid. A virtual machine or container can move without changing its IP address. A virtual router can share hardware with another routing instance whose allowed sources differ. Service chaining and direct server return can make the observed path differ from a simple host to gateway topology. The validation key therefore needs enough context to distinguish tenants and encapsulation, as represented by c in Equation (1).

An interface level SAV design can transfer to virtual environments only after its anchor is defined. A physical port may carry several tenants; an overlay identifier may be controlled by the same sender that supplies the source address. The verifier needs an authenticated or administratively controlled association between the context and the permitted sources. Rule updates should follow migration and failover events with explicit ordering. These requirements extend the binding and update problems already visible in access SAVI, rather than creating an unrelated spoofing problem.

9. Standardization and Implementation Interfaces

9.1. Established Standards and Their Scope

The RFC lineage separates basic practice from fine grained access binding. RFC 2267 establishes early ingress filtering guidance and is superseded by RFC 2827. RFC 3704 treats multihoming and reverse path alternatives, and RFC 8704 updates it with enhanced feasible path validation [1,2,3,4]. These documents form the operational baseline for source prefix filtering. They do not imply that an operator has correctly configured every customer interface merely because a router supports the named feature.

The SAVI RFCs specify complementary access functions. RFC 6959 defines the threat scope, RFC 7039 supplies the framework, and RFCs 6620, 7219, 7513, and 8074 address different assignment environments [27,42,43,44,45,63]. RFC 5210 is an experimental architecture and deployment experience document, not the same type of normative object as a Best Current Practice [39]. A survey should retain these status differences when discussing what an implementer can rely on.

9.2. The SAVNET Snapshot

SAVNET focuses attention on the gaps between existing information and desired source validation behavior. Its intra and interdomain problem statements distinguish their deployment environments and requirements [13,14]. At the retrieved 22 October 2026 snapshot, the intradomain statement is in the RFC Editor queue, and the interdomain statement is in IESG evaluation. Neither status should be rewritten as a published RFC number that the retrieved record does not provide. Table 5 records the versions used in this review.

The architecture and capability drafts are work in progress with separate lifecycles. The intradomain architecture revision is active, whereas the retrieved interdomain architecture revision is expired [67,68]. Expiration describes the state of that draft version; it does not demonstrate that its research idea has failed. The general capabilities work concerns the data plane representation and handling of SAV information [84]. A flexible enforcement interface is useful because several control mechanisms can supply rules, but it cannot by itself certify the origin or completeness of those rules.

BAR-SAV, Bicone, and traffic origin authorization work illustrate different approaches to source permission information [65,85,86]. They should be evaluated according to their versioned semantics and adoption status, not grouped under an undifferentiated label of standardized SAV. In particular, a draft that proposes an update to an RFC does not update that RFC merely by declaring the intention. New authorizations also need a clearly identified signer, covered resource, receiver interpretation, expiration behavior, and treatment of absent information.

9.3. Separating Policy Generation from Enforcement

A reusable SAV implementation should preserve evidence provenance through rule installation. A rule should identify the source of its authorization, its scope, its generation time, and the event that invalidates it. This supports diagnosis when a routing table, an address assignment service, and an explicit source protocol disagree. Simply merging all permissions can hide a weak authority behind a stronger one. Simply intersecting them can disconnect legitimate sources when one data source is incomplete. The conflict policy must be explicit.

Telemetry should report both policy decisions and the context needed to interpret them. Useful records include the rule that matched, the applicable interface or routing instance, the source class, and the rule version. Aggregate drop counters alone cannot determine whether a rise reflects a successful defense, a configuration mistake, or a legitimate topology change. An implementation interface that exposes this information makes operational validation more feasible and gives measurement researchers a stronger basis for controlled ground truth.

10. Open Problems and Research Agenda

10.1. Authorization Beyond Reachability

The central open problem is obtaining source authorization that remains valid under operational routing diversity. A forwarding table answers where a router sends traffic toward a destination. An authorization object answers which sources may arrive in a given context. These answers can overlap, but neither is a complete substitute for the other. Future designs should state the relationship formally and identify precisely which routing assumptions make their transformation sound.

A useful research direction is a hierarchy of explicit authority. An address holder could delegate a prefix to a customer, the customer could delegate it to an internal domain, and that domain could associate addresses with attachments. The research challenge is not merely defining signed objects. It is managing revocation, overlapping delegation, address leasing, multiple legitimate origins, and temporary exceptions without admitting unauthorized claims. Any proposal should test missing and conflicting objects as normal operating cases rather than rare error conditions.

Authorization also needs a confidentiality model. Detailed source topology or customer mappings can reveal business relationships and internal structure. Aggregation can reduce exposure while weakening precision. Cryptographic proofs can change what is disclosed but add verification and key management cost. A design should identify the minimum information each validator needs and test whether withholding the rest changes false rejection or residual spoofability. Privacy and correctness are coupled through the granularity of the assertion.

10.2. Correctness During Change

Dynamic safety deserves an explicit specification rather than an implementation note. A future system should define what packets remain valid during address movement, link failure, routing convergence, and controller recovery. It should also distinguish temporary uncertainty from a definitive denial of authorization. A validator with no current evidence should not be described as correct merely because its policy for admitting or rejecting packets under uncertainty is simple.

Versioned rules and coordinated activation offer one promising direction. The system could associate forwarding and source validation state with compatible epochs, retain a bounded transition policy, and expose which epoch handled each packet. The hard cases include devices with unequal update speed, failed transactions, and inconsistent observations of the event. Formal state machines and adversarial event schedules would make these cases reproducible. The relevant success criterion is bounded harm during transition together with eventual correctness, not final table equality alone.

10.3. Measurement with Calibrated Uncertainty

Remote measurements need a stronger account of what their negative results mean. A research artifact should specify the alternative explanations for each observation and the controls that eliminate them. Where several explanations remain, the output should retain an inconclusive state. Publishing confidence intervals is useful only when the statistical model reflects target selection and correlated observations. Repeated probes to the same kind of device do not create independent coverage of a heterogeneous AS.

Ground truth collaborations should deliberately include difficult networks. Multihoming, partial deployment, mixed IPv4 and IPv6 policy, tunnels, and nonuniform customer attachments are more informative than a testbed with one fully filtered and one fully permissive router. Operators could disclose controlled configuration snapshots and event traces without publishing customer identities. Comparing several remote methods against the same ground truth would reveal whether disagreement comes from different observables or incorrect inference.

Longitudinal deployment claims need stable populations as well as expanding coverage. A repeated panel of testable attachments can support change analysis, while a newly discovered population can support a separate coverage result. Mixing those two populations can make discovery look like deterioration or remediation. Future observatories should publish both panels, along with eligibility changes and the time at which each target entered or left the sample. This would make cross year comparisons more defensible.

10.4. Verification of Protection as a Service

Service based SAV requires evidence that purchased protection is actually enforced. A contract can state a source set, traffic direction, enforcement boundary, and update obligation. An audit must then distinguish filtering at that boundary from incidental filtering elsewhere on the path. It must also prevent a provider from satisfying a small, recognizable probe set while leaving ordinary traffic permissive. The challenge connects service incentives to measurement inference rather than treating them as independent problems.

Selective disclosure could make operational evidence more useful. A provider might publish verifiable summaries of tested interfaces, policy versions, and conformance to a declared source policy without revealing all customer details. The resulting assurance should remain bounded: a tested configuration is not proof of all future packet behavior. Studies should examine audit cost, manipulation resistance, and operator workload alongside detection capability. A technically precise assurance that no operator can maintain is unlikely to change deployment.

10.5. Reproducible Comparisons and Shared Artifacts

The field needs benchmark suites that preserve difficult legitimate traffic. A shared suite should include selective prefix export, asymmetric paths, route servers, multihoming, anycast, tunnels, tenant mobility, and incomplete authorization data. Each scenario should supply a source of truth for permitted arrivals and a trace of expected state changes. Mechanisms could then be compared against the same semantic contract rather than against workloads optimized for their own assumptions.

Simulation and emulation should share a machine readable acceptance predicate. A common model would describe which evidence a mechanism consumes and which source contexts it permits. The simulator could evaluate reach across large topologies, while the emulator checks update behavior and implementation feasibility. A hardware experiment would then evaluate packet and update rates without changing the security semantics. UniSAV and recent routing policy evaluation provide complementary starting points for this separation [8,12].

Table 6. Research questions and concrete evaluation artifacts proposed by this survey. These are future work, not completed experiments.

Question	Proposed artifact	What would constitute useful evidence?
Can authorization survive routing diversity?	Versioned prefix/interface policies with legitimate alternate paths	No unjustified rejection across declared policy cases; bounded residual permits
Can updates avoid outages?	Event traces for failover, mobility, restart, and reordered messages	Packet level loss and stale permission windows measured against event truth
Can remote inference identify partial deployment?	Shared operator ground truth with several instruments	Calibrated outcomes per interface/source class, including inconclusive cases
Can a SAV service be audited?	Explicit contract, boundary probes, and manipulation tests	Evidence tied to the purchased boundary and resilient to selective treatment
Can results transfer between environments?	Common policy semantics in simulation, emulation, and hardware	Consistent decisions and disclosed causes of performance differences
Can an intervention change adoption?	Preregistered treatment and comparison population	Sustained verified deployment change with costs and selection effects reported

Table 6. Research questions and concrete evaluation artifacts proposed by this survey. These are future work, not completed experiments.

Question	Proposed artifact	What would constitute useful evidence?
Can authorization survive routing diversity?	Versioned prefix/interface policies with legitimate alternate paths	No unjustified rejection across declared policy cases; bounded residual permits
Can updates avoid outages?	Event traces for failover, mobility, restart, and reordered messages	Packet level loss and stale permission windows measured against event truth
Can remote inference identify partial deployment?	Shared operator ground truth with several instruments	Calibrated outcomes per interface/source class, including inconclusive cases
Can a SAV service be audited?	Explicit contract, boundary probes, and manipulation tests	Evidence tied to the purchased boundary and resilient to selective treatment
Can results transfer between environments?	Common policy semantics in simulation, emulation, and hardware	Consistent decisions and disclosed causes of performance differences
Can an intervention change adoption?	Preregistered treatment and comparison population	Sustained verified deployment change with costs and selection effects reported

10.6. Evaluating Adoption as a Technical Outcome

Deployment studies should measure sustained protection rather than message delivery or expressed intention. An intervention could provide configuration assistance, monitoring, or remediation tools, then verify whether the promised source policy persists through subsequent operational changes. The experimental design should identify who controls the configuration and whether the intervention reaches that party. A randomized design can estimate an intervention effect when feasible; other designs should make their causal limitations explicit.

The practical research objective is reducing the cost of correct operation. A mechanism that slightly improves spoof rejection but creates difficult outages can lose operator support. A tool that explains a false rejection, identifies its authority mismatch, and supports a reversible repair can make existing controls more usable. Such tooling should be evaluated with task completion, diagnosis accuracy, and sustained policy correctness. These outcomes connect the literature’s security goals to the conditions under which networks actually maintain them.

11. Conclusions

Source address validation is a problem of authorization, observation, and operation. Local bindings, routing based filters, explicit source signaling, packet authentication, and learned behavior offer different evidence about a claimed source. Their guarantees depend on scope, topology, timing, and trust. A meaningful comparison therefore begins with the authorization being enforced and the legitimate paths that must remain available.

Measurement has expanded from participating clients to remote protocol effects and passive traffic analysis. This progress increases visibility but does not remove the need to distinguish successful spoofing, conditional filtering inference, and inconclusive outcomes. Historical prevalence figures remain tied to their populations and observation periods. Deployment evidence also needs to distinguish correlation from the effect of a specific intervention.

The path forward requires explicit source semantics, safe updates, shared evaluation workloads, and operational evidence that identifies where protection holds. The literature supports treating access, intradomain, and interdomain validation as complementary boundaries. Progress at one boundary should be measured in its own terms and then tested for composition with the others. That discipline makes both research claims and deployment decisions more reliable.

Appendix A.1. Artifact Organization

The accompanying source package contains the LaTeX manuscript, BibTeX bibliography, a machine readable literature catalog, retained search outputs, and compilation checks. The local working archive also retains retrieved public papers and extracted text; the portable source package provides retrieval links and scripts. Each catalog entry records its key, year, title, authors, venue, type, analytical role, source URL, and evidence level. Search discovery records and final included records remain separate. An unsuccessful metadata lookup is not converted into a verified citation.

The review distinguishes three main evidence levels. Extracted full text supports checking the method and its qualifications. A primary record or abstract supports only the claims visible there. An author publication listing supports bibliographic existence and stated topic, while leaving detailed mechanisms and results unverified. Draft records form a fourth category because their revision and status are essential to interpretation. A local full text flag records availability, not an assertion that every line of that paper has been exhaustively reviewed.

Appendix A.2. Recent Work and Adjacent Evidence

Recent SAV and routing security contributions have different roles in the synthesis. OSAVRoute is a measurement paper, UniSAV is a framework and evaluation contribution, and 3L-SAV addresses hierarchical intradomain validation [7,8,23]. The trusted seed relationship inference paper concerns an input relevant to routing based analysis [24]. The ROV deployment paper supplies an adjacent operational comparison, and Themis concerns route origin hijacking [25,26]. None of the latter three is presented as direct evidence of SAV deployment or SAV filtering performance.

The INFOCOM 2026 relationship paper and the APNOMS 2025 3L-SAV contribution have both publisher metadata and an author publication listing. Their full texts were not retrieved in this review. The 3L-SAV record is marked as a poster presentation. These publication records establish the authorship, venue, and stated topic, while leaving algorithmic details and performance claims outside the evidence available here.

Appendix A.3. Extending the Review

A full database audit would complement the present search. Such an extension should export query results from bibliographic databases, retain exact query syntax and dates, deduplicate by DOI and normalized title, and record a screening decision for every exported item. It should expand Chinese language retrieval beyond the papers reached through existing surveys. It should also check new records after the cutoff and update draft status without rewriting the historical status used for the present analysis.

An extension should preserve version relationships and negative decisions. A journal extension can add a result without creating an independent observation of deployment. A retracted paper should not support a positive technical claim. An inaccessible item should remain in a candidate or metadata only category until its claims can be checked. These controls make the corpus useful for continued research while keeping the scope of the current synthesis visible.