Spoofer: 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.

The packets in the tracefilter test explicitly set their TTL. With TTLs, the network ensures that routing loops do not result in infinite packet circulation. The IP packet header's TTL is decremented by each router that forwards the packet. When the TTL reaches zero, the TTL is said to ``expire'' and the router will generate an ICMP TTL exceeded message back to the source of the packet ootnote{Some routers disable the diagnostic functionality ICMP messages afford due to specific or anticipated attacks.}. 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 high-level operation is to send spoofed packets with specially crafted TTLs. If the packet generates an ICMP TTL exceeded message from a router along the path, we know the portion of the path up to that router is not blocking the spoofed packet ootnote{The idea for tracefilter germinated from an insightful conversation with John Curran.}.

Figure 1. Tracefilter test determines where along a client to server path anti-spoofing filtering is enabled: 1) Client sends a spoofed packet with a TTL of 2, source IP address of the server and destination address of another host on the same network as the server. 2) If no filtering is in place along the first two hops, the packet's TTL will expire, generating an ICMP TTL exceeded message sent to the server. 3) For each originating TTL, the server records which spoofed packets are received. The largest originating TTL received indicates the filtering point. The client tests the entire path to server by repeating with TTLs from 1 through the IP hop path length.

Recall that 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 of the tested path. The server communicates this distance $d$ to the client over the TCP connection who then generates spoofed UDP packets with TTLs from $1\le ttl \le 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. We use this destination address to avoid the pathological situation of a packet with the same source and destination addresses. 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 ootnote{While we use tracefilter as a diagnostic, a malicious party could spoof in this way as an ICMP DoS technique.}.

ICMP TTL exceeded messages include only the first 28 bytes of the original packet, i.e. just the IP and UDP headers of the packet that caused the ICMP message. The TTL of the packet which generates the ICMP TTL exceeded message is by definition zero. Therefore, since the payload of the original packet is not included in the ICMP message, we must encode the originating TTL value in the UDP packet header. We pad the payload of the original packet so that the UDP length field encodes the originating TTL value. Our server then recovers the originating TTL of the packet that generates the ICMP TTL exceeded message by examining the UDP length field contained within the ICMP message body. By recording the largest received TTL from a client, the server can infer the number of hops along the path from the client to our server where spoofing filtering is employed.

Published