1. IP Spoofing CS 236 Advanced Computer Security Peter Reiher April 29, 2008

2. Groups for This Week Golita Benoodi, Nikolay Laptev, Faraz Zahabian
Darrell Carbajal, Abishek Jain, Peter Wu
Andrew Castner, Min-Hsieh Tsai, Chen-Kuei Lee
Chia-Wei Chang, Zhen Huang, Ionnis Pefkianakis
Chien-Chia Chen, Peter Peterson, Kuo-Yen Lo
Yu Yuan Chen, Michael Hall, Hootan Nikbakht
Michael Cohen, Chieh-Ning Lien, Vishwar Goudar
Jih-Chung Fan, Jason Liu, Sean MacIntyre

3. Outline
What is IP spoofing?
What is it used for?
How do you stop it?

4. The Problem of IP Spoofing
IP header
IP payload
Now we’ll capture the desperate criminal!
Destination address
Source address
So has someone hacked Granny’s machine?
Who sent you the fatal packet?
No, someone spoofed Granny’s IP address!
Now we’re getting somewhere!

5. What Really Happened The dirty liar! 183.11.46.194 183.11.46.194
The dirty liar!

6. What Is IP Spoofing?
Existing Internet protocols and infrastructure allow forgery of some IP packet header fields
In particular, the source address field can often be forged
If packet causes trouble, can’t determine its true source
Particularly important for distributed denial of service attacks
But relevant for other situations

7. What Is Spoofing Used For?
If attacker forges source address, probably won’t see the response
So spoofing only useful when attacker doesn’t care about response
Usually denial of service attacks
This point is not universally true
If attacker can sniff the path . . .

8. IP Spoofing and Reflector Attacks
Some network sites accept remote requests and provide answers (or take actions)
E.g., DNS servers, broadcast addresses
Responses go to whoever’s in the source address of the request
If response is a lot bigger than the request, the attacker can cause more traffic at victim than attacker must send out

9. IP Spoofing and Smurf Attacks
Attack on vulnerability in IP broadcasting
Send a ping packet to an IP broadcast address
With forged IP source address of your target
Ping gets broadcast to all addresses in broadcast group
Still with forged address
Each broadcast recipient responds to the ping
Inundating the victim of the attack
Easy to fix at the intermediary
No IP broadcasts from outside your network
No good solutions for victim

10. Types of Spoofing General spoofing
Attacker chooses a random IP address for source address
Subnet spoofing
Attacker chooses an address from the subnet his real machine is on
With suitable sniffing, can see responses
Harder for some types of filtering

11. How Much of a Problem Is Spoofing?
The Spoofing Project suggests 16-25% of Internet is spoofable
Because of ingress filtering
Methodology based on limited number of volunteers running their code
Arguably the folks most likely to deploy ingress filtering
Even if they’re right, 20% is a lot

12. Combating Spoofing Basic approaches: Authenticate address
Prevent delivery of packets with spoofed addresses
Trace packets with spoofed addresses to their true source
Deduce bogosity from other packet header information
Deduce bogosity of entire data streams with shared IP addresses

13. Authenticate Address Probably requires cryptography
Can be done with IPSec
Incurs cryptographic costs
Only feasible when crypto authentication is feasible
Could we afford to do this for all packets?

14. Pushing Authentication Out
Destination node can’t afford to check authentication
Since, usually, spoofing done at high volumes
Could we push authentication out into the network?
Enlist core routers to check authentication?
Sounds crazy
They’re already busy
But maybe they can do it only when needed?
Or maybe it can be built into fast hardware?

15. Challenges for In-Network Address Authentication
Large scale authentication problem
Key management, etc.
Crypto costs
Partial deployment
Costs of updates?

16. Packet Passports A simplification of the approach
Destination sends secret stamps to sources it likes
Only packets with the right stamp get delivered
For their source address
Spoofers don’t know the stamp
So their packets get dropped
Maybe far out in the network

17. Issues for Stamping Approaches
Are stamps related to packet contents?
If not, can attackers “steal” a stamp?
How often do you change stamps?
How to you issue stamps to legitimate nodes?
Where do you put stamps?
How do you check them fast enough?

18. Detect Spoofed Addresses
Recognize that address is spoofed
Usually based on information about:
Network topology
Addresses
Simple version is ingress filtering
More sophisticated methods are possible

19. Ingress Filtering Example
My network shouldn’t be creating packets with this source address *

20. Spoofing Detection ApproachesB J C H D G F E

21. Potential Problems With Approaches Requiring Infrastructure Support
Issues of speed and cost
Issues of trustworthiness
Issues of deployment
Why will it be deployed at all?
How will it work partially deployed?

22. SAVE At each router, build table of proper “incoming” interface
For source addresses, which interface should packets arrive?
Kind of a generalization of ingress filtering
But how to get the information?
Leverage routing table

23. SAVE Protocol SAVE builds incoming table at each router through:
Generating SAVE updates
Processing and forwarding SAVE updates
Final result is that all routers build proper tables C 4 5 RE 1 2 10 RC 6 E A
B A RA 3 RD
FORWARDING
INTERFACE 11
ADDRESS RB 7 8 D C B 9
INCOMING
INTERFACE
ADDRESS D 3 E 3 A
FORWARDING TABLE
INCOMING TABLE B 23

24. SAVE Update Generation
Each SAVE router is assigned a source address space (SAS)
Range of IP addresses that use this router as an exit router for some set of destinations
Independent of the underlying routing protocol
A periodic SAVE update is generated for every entry in the forwarding table and sent to the next hop
Forwarding table change invokes the generation of triggered SAVE update for the changed entry 24

25. Updates Benefit Multiple Routers
Intermediate routers update their incoming tables C 4 5 RE 1 2 10 RC 6 E A
D A
D A RA 3
D A RD
FORWARDING
INTERFACE 11
ADDRESS RB 7 8 D C B 9 D 3
INCOMING
INTERFACE
INCOMING
INTERFACE E 3
ADDRESS
ADDRESS
FORWARDING TABLE A A B
INCOMING TABLE
INCOMING TABLE 25

26. Updates Can Be Aggregated
Intermediate router can piggyback its incoming interface information to a passing update C 4 5 RE 1 2 10 RC 6 E A
D A RA 3
D A B RD
D A B
ADDRESS
FORWARDING
INTERFACE 11 RB 7 8 D C B 9 D 3
INCOMING
INTERFACE
INCOMING
INTERFACE E 3
ADDRESS
ADDRESS
FORWARDING TABLE A
A B B
INCOMING TABLE
INCOMING TABLE 26

27. Sometimes Updates Must Be Split
Addresses in forwarding tables are highly aggregated
At some point, the paths diverge
INCOMING
INTERFACE
ADDRESS C
A B 4 5
INCOMING TABLE 1 2 10 RC 6
E AB E A
DE A RE RA 3 RD
E AB
FORWARDING
INTERFACE 11
ADDRESS RB
D AB 7 8 D C
D AB B 9 DE 3
FORWARDING TABLE
INCOMING
INTERFACE
ADDRESS
FORWARDING
INTERFACE B
ADDRESS
INCOMING
INTERFACE
ADDRESS
A B E A
INCOMING TABLE D
INCOMING TABLE
FORWARDING TABLE 27

28. Did SAVE Work? Yes, just fine In full deployment . . .
In partial deployment, update splitting is extremely challenging
Since non-deployers won’t split your updates
Thus, of academic interest

29. The iSAVE Protocol Attempt to solve SAVE’s deployment problem
Designed for partial deployment
Router proactively send updates when they’re actually sending traffic
Augmented with on-demand requests from iSAVE routers

30. Send an iSAVE update to X
iSAVE at Work
User traffic to X 1 2 3 4 A B 5 7 6 8 X AB
iSAVE update Y
Send an iSAVE update to X
AB 5 X

31. Using the Incoming TableX A A X A X A X A X A X A X A X A X A X A B X A X A X A X A 5 7 6 8 X A X A
But the incoming table says messages from A come on interface 5, not interface 6 Y
AB 5
Incoming table X

32. On-Demand iSAVE Entries
What if a router gets traffic when it doesn’t have information on the proper interface?
Might be good traffic or spoofed traffic
So ask the iSAVE router in charge of the source address for an update

33. iSAVE’s Little Flaw
It doesn’t work
Why?
Is it fixable?

34. Another Possible Approach
ASPIRE
Use BGP info to validate paths
Essentially, when path chosen, tell other routers that you chose that path
And that path is the right one for packets with these addresses

35. An ASPIRE Deployment AS 3 AS 2 AS 6 AS 1 AS 4 AS 5 ASPIRE Capable AS
Destination Prefix: d1
AS 6
AS 1
AS 6
Source Prefixes:
s1, s2, , sn
AS 4
AS 5
ASPIRE Capable AS
Legacy AS

36. When ASPIRE First Starts on AS 6
Disallow incoming packets from s1, s2, , sn to d1.
AS 3
AS 2
AS 2
Destination Prefix: d1
AS 6
AS 1
AS 6
Source Prefixes:
s1, s2, , sn
AS 4
AS 5
Initially, ASPIRE-capable ASs disallow traffic from s1, s2, , sn to d1 from any neighbour

37. AS 2 Sends a BGP Update to AS 6
AS3,AS1,AS2 d1
AS1,AS2 d1
AS2
AS 2
Destination Prefix: d1
AS 6
AS 1
AS 6
Source Prefixes:
s1, s2, , sn
AS 4
AS 5
AS 6 chooses the AS path (3, 1, 2) to route to d1

38. ASPIRE Springs Into Action!
s1-sn
AS3,AS1,AS2 d1
s1-sn
AS3,AS1,AS2 d1
s1-sn
AS3,AS1,AS2 d1
AS 6
AS 1
AS 2
Destination Prefix: d1
AS 6
Source Prefixes:
s1, s2, , sn
AS 4
AS 5

39. What Has ASPIRE Achieved Here?
WRONG!!!! d1 s1
AS 4
AS 5
Packets can now flow from s1, . . ., sn to d1 on their proper path
But all other false paths for these packets are blocked

40. ASPIRE And Partial Deployment
Non-participating Ases don’t get their traffic protected
Spoofed traffic can be introduced through non-participating AS
If it’s on the proper path

41. Why ASPIRE Can Never Work
You’ll never get full deployment
Security will kill you
PKI required . . .
The overheads will be unacceptable
These all might (or might not) be true

42. Packet Tracing Figure out where the packet really came from
Generally only feasible if there is a continuing stream of packets
Usually for DDoS
Challenges when there are multiple sources of spoofed addresses
For many purposes, the ultimate question is – so what?

43. Using Other Packet Header Info
Packets from a particular source IP address have stereotypical header info
E.g., for given destination, TTL probably is fairly steady
Look for implausible info in such fields
Could help against really random spoofing
Attacker can probably deduce many plausible values
There aren’t that many possible values

44. Using TTL To Detect Spoofing32 32 31 I A 29 30 28 27 B J A 27 A 27 B D E F G H I 26 58 30 30 C H D G F E

45. Deducing Spoofing From Data Stream Information
Streams of packets are expected to have certain behaviors
Especially TCP
Observe streams for proper behavior
Maybe even fiddle with them a little to see what happens
Obvious example:
Drop some packets from TCP stream with suspect address
Do they get retransmitted?

46. Diagram for Deducing From Data Stream Information
Packets from * have been coming in on one interface
Now packets from those addresses show up on another
Route change or spoofing?
Drop a few and see what happens

47. What If It’s Good Traffic?AS ✔ ✔
TCP to the rescue!
Receiver tells sender to retransmit “lost” packets
Since all dropped packets retransmitted, they weren’t spoofed
What about that other interface?

48. What If It’s Bad Traffic?AS
TCP to the rescue!
Receiver tells sender to retransmit “lost” packets
But “sender” never heard of those packets!
So it doesn’t retransmit
So knows this interface is wrong

49. Clouseau A system designed to do this
Allows router to independently detect spoofing
Doesn’t require crypto
No PKI!
Must deal with attempted deception
How could you deceive Clouseau?
How would Clouseau detect it?

50. Open Questions On Spoofing
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?
How do you evaluate proposed systems?