Anti-spoofing at the Edge – the SAVI WG at IETF

The anti-spoofing mechanisms first outlined in BCP38 have seen low adoption rates for two main reasons: (1) lack of a business case and (2) the fact that proposed mechanisms become more fragile and less effective the more you move away from the source of the forged packet.

It seems that the IETF Working Group on Source Address Validation Improvements (SAVI) may address both of the problems: it is based on a clearer business case and it provides IP source address validation at the maximally fine granularity of individual IP addresses and as close to the source as possible. SAVI’s objective is to prevent hosts attached to the same link from spoofing each other’s IP addresses.

Creating a business case for anti-spoofing in the global context has been challenging: preventing spoofing on internetwork interfaces does not necessarily make your own network less vulnerable to the spoofed attacks, e.g. DNS amplification attacks, it just ensures that your network is not used as a launch pad for such attacks. The situation might be different when spoofing is considered as a local problem, for instance, spoofing of an address of a neighbor computer on a local Ethernet network. In broadband access networks, spoofing may be used to gain access to services or to disrupt services to other customers. Not surprisingly, a mechanism for validating source IP addresses became mandatory in Data-Over-Cable Service Interface Specifications version 3 (DOSCIS 3.0) several years ago.

Preventing spoofing locally, as close to the host as possible is more robust and limits the scope of a possible attack. Implementing anti-spoofing in a local network segment makes possible application of more reliable and fine-grained filters, or bindings, like (IP address)-(MAC address)-(switch port), as opposed to (address range)-(router interface) in the case of traditional ingress filtering.

SAVI takes a similar approach to the DOCSIS source address verification mechanism and extends it on all kinds of network topologies and technologies, not only broadband cable networks. The proposed mechanisms are purely network based and don’t depend on supporting functionality in connected hosts.

The working group has recently published an RFC outlining the general framework and deployment considerations and is working on specifications for specific validation mechanisms. I hope the business case is convincing enough and future implementations are seamless and robust enough to facilitate wide deployment in edge networks.