Research Abstracts - 2006

Modern Implications of IP Spoofing - Threats, Measurements and Network Architecture

Robert Beverly & Steven Bauer

Research Summary

The classic design tenants of Internet architecture produced a network capable of remarkable scalability, but relegated security to the end hosts. As a result, the Internet includes no explicit notion of authenticity and will forward packets with forged headers. Malicious users and compromised hosts capitalize on the ability to "spoof" source IP addresses for anonymity, indirection, targeted attacks and security circumvention. Ingress address filtering or unicast reverse path forwarding checks can prevent spoofing when practical. In production networks however, such techniques are limited by multi-homing, route asymmetry, filter list maintenance and router design. Despite being first exploited over two-decades ago [1], IP spoofing is a persistent problem and a continued threat [2]. In addition to spoofed-source bandwidth-based denial-of-service attacks, new exploits surface regularly; three new novel attacks utilize IP spoofing for in-window TCP connection resets, traffic amplification and even unsolicited commercial email.

Our research is an Internet-wide active measurement IP spoofing project, first detailed in [3] with continuously updated results available at: http://spoofer.csail.mit.edu. We test filtering policies, depth, specificity and the extent of spoofable adjacent address space. The contributions of our work thus far are:

• Measurements of filtering granularity and specificity demonstrating the ability to spoof large portions of adjacent address space.
• An extensive analysis, including geographic distribution, of over 1400 unique test reports showing approximately 23% of the observed netblocks, corresponding to 25% of the observed autonomous systems, allow spoofing.
• A publicly available filtering tester application actively being used as a diagnostic tool for securing networks.
• A novel "tracefilter" mechanism that finds 80% of filtering is employed at the first or second hop along the network path.
• Consideration of the architectural implications of spoofing.

This abstract presents the design of our tracefilter and outlines the tussle in designing spoofing-resistant architectures.

Tracefilter

Conventional wisdom dictates that ingress filtering is performed near the edges of the network rather than the core. In addition to the nature and extent of IP spoofing, we also seek to understand where in the network filtering is employed with a new, novel technique we call tracefilter.

Figure 1. Tracefilter test determines where along a client to server path anti-spoofing filtering is enabled.

In the same way that traceroute leverages ICMP messages, our tracefilter depends on TTL expiration and ICMP. A tracefilter run in progress is shown in Figure 1. The client sends non-spoofed UDP packets to the server to test basic reachability and measure path length. These packets are sent with a known TTL so that our server can infer the IP hop length, d of the tested path. The client generates spoofed UDP packets with TTLs from 1 < ttl < d. The spoofed packet's IP source is our server to allow it to receive and process any ICMP messages the packet generates. The packet's destination address is an IP address on the same subnetwork as our server so that we test a congruent path. If the packet expires before reaching a router that performs filtering, it will generate an ICMP TTL exceeded message destined to source of the packet. Since the source is spoofed as our server, the spoofer server receives the ICMP message. We can thus infer the location of filtering along the path [4].

Architectural Tussle

The Internet's architectural inability to prevent spoofing implies we cannot reliably anticipate or defend against the next exploit or shift in attack patterns that leverage spoofing. In addition, the nature of Internet technology and policy is slowly evolving. For instance, IPv6 introduces both challenges and opportunities for managing spoofing. In an IPv6 network a host's IPv6 addresses are assigned by its provider, thus facilitating multi-homing without bloating the global routing table. IPv6 address assignment enables providers to filter packets from outside their address range without fear of blocking an address from a legitimate downstream customer. Unfortunately, neighbor spoofing is more problematic as the space of possible neighbor addresses is many times larger than the entire IPv4 address space.

Our measurements indicate that networks today generally rely upon the edges to properly validate source information. If spoofed packets make it through the first few hops into the network, a spoofed packet is likely to travel unimpeded to the destination. Our research asks whether the core of the network may assume the validity of source information in packets. Specific architectural alternatives include validating source information based upon either an implicit or explicit property of the packet. In considering architectures for preventing spoofing, the literature on mechanism design suggests principles for design where it is in the user's interest to act truthfully. In today's networks end hosts are not negatively impacted for sending spoofed packets. Our research considers the question of whether a network architecture should include a punishment mechanism for hosts that spoof traffic.

Any realistic spoof-limiting scheme must lower the benefit or significantly increase the difficulty of spoofing such that it is no longer an attractive attack vector. Current anti-spoofing filtering techniques have proven inadequate because a provider can follow all best common practices and still receive anonymous, potentially malicious traffic from third-parties who do not properly filter. A single unfiltered ingress point on the Internet provides a means to circumvent global spoofing protection mechanisms. A successful scheme will protect parties who implement it from receiving spoofed traffic without relying on large-scale distributed coordination or cooperation.

References:

[1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. Computer Communications Review, 1989.

[2] D. Moore, C. Shannon, D. Brown, G. M. Voelker and S. Savage. Inferring Internet {Denial-of-Service} Activity. IEEE/ACM Transactions on Networking, January 2006.

[3] R. Beverly and S. Bauer. The Spoofer Project: Inferring the Extent of Source Address Filtering on the Internet. In Proceedings of USENIX Steps to Reducing Unwanted Traffic on the Internet (SRUTI) Workshop, July 2005.

[4] The idea for tracefilter germinated from an insightful conversation with John Curran.