The Problem IP Spoofing CS 239 Existing Internet protocols and - PDF document

The Problem IP Spoofing CS 239 • Existing Internet protocols and Advanced Topics in Network infrastructure allow forgery of some IP Security packet header fields Peter Reiher • In particular, the source address field can often be forged April 7, 2004 Lecture 2 Lecture 2 Page 1 Page 2 CS 239, Spring 2004 CS 239, Spring 2004 Why Is That a Problem? Limitations of the Problem • If attacker forges source address in • Can’t trust where packets came from packet, probably won’t see the • If packet causes trouble, can’t response determine its true source • So spoofing only useful when attacker • Particularly important for distributed doesn’t care about response denial of service attacks –Usually denial of service attacks –But relevant for other situations • This point is not universally true Lecture 2 Lecture 2 Page 3 Page 4 CS 239, Spring 2004 CS 239, Spring 2004 Types of Spoofing Combating Spoofing • General spoofing • Basic approaches: – Attacker chooses a random IP address for 1. Authenticate address source address 2. Prevent delivery of packets with • Subnet spoofing spoofed addresses – Attacker chooses an address from the 3. Trace packets with spoofed addresses subnet his real machine is on to their true source – With suitable sniffing, can see responses 4. Deduce bogosity from other packet header information – Harder for some types of filtering Lecture 2 Lecture 2 Page 5 Page 6 CS 239, Spring 2004 CS 239, Spring 2004 1

Preventing Delivery of Spoofed Authenticate Address Packets • Probably requires cryptography • Somehow recognize that address is spoofed • Can be done with IPSec –Usually based on information about • Incurs cryptographic costs network topology and addresses • Only feasible when crypto • Simple version is ingress filtering authentication is feasible • More sophisticated methods are • Could we afford to do this for all possible packets? Lecture 2 Lecture 2 Page 7 Page 8 CS 239, Spring 2004 CS 239, Spring 2004 Ingress Filtering Example Diagram for Detection Approaches I A 95.113.27.12 56.29.138.2 B J C H My network shouldn’t be creating packets with this D G source address F E 128.171.192.* Lecture 2 Lecture 2 Page 9 Page 10 CS 239, Spring 2004 CS 239, Spring 2004 Potential Problems With Approaches Packet Tracing Requiring Infrastructure Support • Figure out where the packet really came • Issues of speed and cost from • Issues of trustworthiness • Generally only feasible if there is a • Issues of deployment continuing stream of packets • Will be discussed in more detail in later –Why will it be deployed at all? class –How will it work partially deployed? • Challenges when there are multiple sources of spoofed addresses Lecture 2 Lecture 2 Page 11 Page 12 CS 239, Spring 2004 CS 239, Spring 2004 2

Using Other Packet Header Info Diagram for Using TTL 32 32 • Packets from a particular source IP address I 31 A have stereotypical header info 29 30 28 27 – E.g., for given destination, TTL probably B is fairly steady J A 27 A 27 • Look for implausible info in such fields B 27 30 C H D 26 • Could help against really random spoofing E 58 F 27 G 26 • Attacker can probably deduce many H 30 D plausible values I 30 G F E • There aren’t that many possible values Lecture 2 Lecture 2 Page 13 Page 14 CS 239, Spring 2004 CS 239, Spring 2004 Open Questions • Are there entirely different families of approaches? • How can you actually build tables for detection approaches? • Can detection approaches work in practical deployments? • Are crypto approaches actually feasible? Lecture 2 Page 15 CS 239, Spring 2004 3