Source Address Validation (SAV)

What Source Address Validation Does

Source address validation checks whether a packet’s claimed source address is plausible on the interface or network where it arrives. It is a basic anti-spoofing control that helps separate legitimate traffic from packets pretending to come from elsewhere.

In practice, SAV matters because spoofed source addresses are often the first ingredient in reflection attacks, some fraud patterns, and traffic meant to disguise its origin. When that check is weak or absent, defenders lose an important signal about where traffic really came from.

How SAV Works in Networks

SAV is usually implemented as ingress filtering, egress filtering, or both. Ingress filtering blocks packets that should not be arriving from a given direction, while egress filtering prevents an organisation’s own networks from emitting traffic with invalid source addresses.

The value of the control is not perfect provenance, but practical plausibility. A network does not need to know the true origin of every packet to reject obviously impossible ones, such as traffic claiming to be from an internal range that should never appear on an external-facing link.

Because routing is not always symmetric, operators also have to account for legitimate traffic paths that do not follow a simple return route. Poorly designed filtering can drop valid traffic, so SAV must be aligned with the actual routing architecture rather than applied as a blunt rule.

Why Source Spoofing Becomes Dangerous

Spoofed source addresses are dangerous because they weaken trust in network metadata that many services still rely on for rate limiting, abuse handling, logging, and incident analysis. They also let attackers shift blame away from the real origin of traffic and make downstream correlation harder.

Reflection attacks are the clearest example: the attacker forges a victim’s address, sends requests to third-party systems, and causes the replies to flood the victim. SAV reduces that abuse by making spoofed packets harder to inject in the first place. CISA Industrial Control Systems is also useful context where network trust boundaries and traffic directionality are especially sensitive.

Operationally, the weakness is not only volumetric abuse. If a network accepts obviously implausible source addresses, it can also complicate fraud detection, mislead monitoring, and hide the true path of malicious or anomalous traffic.

Deploying and Verifying SAV

The practical question is whether filtering matches real traffic patterns. Operators should compare SAV policy against their address plan, routing design, multihoming, and any asymmetric paths before turning on strict enforcement.

Verification normally starts with an accurate asset and routing view, then moves to testing on edge devices and upstream links. Teams should confirm that ingress and egress rules block spoofed traffic without breaking legitimate services that depend on nonstandard routing. Authoritative implementation guidance is often clearer in vendor and standards material than in generic summaries, so readers should cross-check against the relevant network guidance and the RFC 8707: Resource Indicators for OAuth 2.0 style of audience-bound trust reasoning only as an analogy for how precise scope boundaries should be.

Where full deployment is not yet possible, partial SAV coverage is still better than none. Border enforcement, upstream coordination, and selective filtering on the highest-risk links can materially reduce spoofing opportunities even before every path is covered.

Risk and Threat Considerations

SAV failures create direct exposure to spoofed traffic, which can be used to amplify attacks, obscure attribution, and bypass controls that assume source addresses are trustworthy. The biggest risk is not one broken packet, but a network posture that makes hostile traffic easier to launch and harder to investigate.

Failure mechanism: If ingress and egress validation are absent or misaligned with routing, attackers can inject packets with falsified source addresses and exploit third-party reflectors or hide their real origin behind forged metadata.

Impact: Organisations can face larger denial-of-service events, weaker abuse tracing, degraded monitoring fidelity, and false confidence in the provenance of traffic they are accepting or emitting.

Practitioner Guidance

What to watch for: Treat asymmetric routing, multihoming, and exceptions for temporary network changes as the main operational risks when rolling out SAV. These are the places where a well-intentioned filter is most likely to block good traffic or leave a spoofing path open.

Practitioner takeaway: SAV works best when it is treated as an ongoing routing-and-policy control, not a one-time edge setting. The control should be revalidated whenever network paths, address ranges, or upstream relationships change.

Related resources from NHI Mgmt Group

• What happens when security teams let AI agents produce recommendations without strong source validation and output review?
• What happens when source to target validation is missing during data movement?
• Why does non-document verification still need strong source validation?
• What happens when a token validation flow trusts the wrong identity source?