4/17/2010
SAVE: Source Address Validity Enforcement Protocol
Jun Li, Jelena Mirković, Mengqiu Wang, Peter Reiher and Lixia Zhang
Computer Science Department
University of California, Los Angeles
1
Motivation
• To ensure all IP packets carry valid source addresses
• This is good for …
– Network security
• Prevent from forging source addresses
• Trace attackers
– Network problem diagnosis
• Locate possible sources of a problem
– Source‐based QoS services
2
1
4/17/2010
Idea
• Build a table of a valid incoming interface for a source address at routers
• Filter packets with forged source addresses
– Routers maintain information on valid incoming interface
• Incoming table
– A source address propagates to all destinations
• SAVE update
3
SAVE Overview
• Assume each router is associated with a set of source addresses
– A border router of an AS handles the source address space of the AS
– A transit router with no attached hosts handles its own IP address
• Routers set up valid coming interfaces for the associated addresses
4
2
4/17/2010
SAVE Overview (Cont’d)
• Routers for SAVE
– Build an incoming table
• Map valid incoming interfaces with specific address spaces
• Cannot use forwarding tables due to routing asymmetry
– Build an Incoming tree
• Solve a problem of stale incoming table
• Each node is a specific source address space
• Each link has a valid incoming interface between nodes
5
SAVE Overview (Cont’d)
– Advertise SAVE updates
• Routers on the path learn valid incoming interfaces for address spaces
• Generated periodically toward the destination address space in the forwarding table
• Triggered by changes in the forwarding table
• Intermediate routers can piggyback their own source address
• {Destination address space, Address Space Vector (ASV), appendable flag}
6
3
4/17/2010
SAVE Scenario #1
Malicious packet
B
SD
A
6
1
XX AA
XX AAA
X
XX AA
XX AAA
X
X A
XX AA
X4X AA
5
SA
2
{SB,<SA>,1}
SAVE update
7
SC
8
3
SB
Sour. Interface
SA
2
Incoming table
7
SAVE Scenario #2
Incoming table
Sour. Interface
SD
SA
{SC,<SA>,0}
SAVE update
1
1
6
5
SA
2
SC
8
4
3
SB
{SC,<SA>,0}
SAVE update
7
Sour. Interface
SA
7
Incoming table
Routers between the source and final destination can record the legitimate incoming interface for the 8
specified source address space
4
4/17/2010
SAVE Scenario #3
Incoming table
Sour. Interface
SD
SA
{SC,<SA>,1}
SAVE update
1
1
6
5
SA
2
8
4
3
SB
{SC,<SA,SD>,1}
SAVE update
7
SC
Sour. Interface
SA,SD 7
Incoming table
Intermediate routers piggyback source address spaces on a passing‐by SAVE update
9
Issue #1
• SAVE update accounts for all paths toward the addresses in the destination space
– Forwarded toward a destination address space, not a single IP address
• Generate two SAVE updates toward R and r, respectively
• r learns the valid path for SB
10
5
4/17/2010
Issue #2
• Routing changes
– Not all routers experience changes in the forwarding table
• Routers E and F do not change their forwarding entries to SA
• Routers E and F do not generate SAVE updates
– Router A suffers from stale information about address spaces SE and SF
11
Issue #2 Solutions
1. Send SAVE updates periodically
– Delay problem 2. Employ incoming tree
– Use address space vector
• ASV: <SF, SE, SD, SB, SA>
– Changes in a node’s incoming interface affect all its descendents
• ASV: <SD, SC, SA>
12
6
4/17/2010
Routing Changes Scenario
2
1 SC
SC
3
SC
{SD,<SA,SC>,1}
SAVE update
SA
SD
SD
SB
SA
2
1
{SD,<SA>,1}
SAVE update
SA
4
3
{SD,<SB>,1}
SAVE update
5
SB
13
Routing Changes Scenario (Cont’d)
2
1 SC
SC
SA
SD
SC
{SD,<SC>,1}
SAVE update
3
4
1
SA
SD
3
SB
SA
{SD,<SC,SB>,1}
SAVE update
5
SB
14
7
4/17/2010
Routing Changes Scenario (Cont’d)
SD
1 SC
3
SA
SB
SD
SC
SC
{SD,<SC>,1}
SAVE update
3
4
1
SA
SA
{SD,<SC,SB>,1}
SAVE update
5
SB
15
Issue #3
• Overhead control
– Should allow intermediate routers to piggyback to passing‐by SAVE updates
• Always?
– Mark SAVE updates to indicate if it is appendable
or not
• When?
16
8
4/17/2010
SAVE Protocol
• Data structures
– Incoming table
– Incoming tree
– SAVE update
17
SAVE Protocol (Cont’d)
• Generating SAVE updates
– Routers generate SAVE update for each entry in its forwarding table.
– Source address space SR, destination address space D
• <destination address space=D, ASV=<SR>, appendable=true>
– Encapsulated inside an IP datagram
• Destination address is randomly chosen from D
– Backward compatibility
18
9
4/17/2010
SAVE Protocol (Cont’d)
• Updating an incoming tree
– Routers use ASVs to maintain their incoming trees
– ASV field records an ordered list of address spaces on the path the SAVE update traversed
• Intermediate routers can append their address spaces
– ASV Format: <S1, S2, …, SN>
• Si is source address space of router Ri
• Si becomes the child node of Si+1 in incoming tree
– All nodes in a sub‐tree map to the same incoming interface
19
SAVE Protocol (Cont’d)
• Processing SAVE updates
– Used to maintain incoming tree and table
– Mark not appendable in the passing‐by update
• If the intermediate router RN has already initiated a SAVE update for the same destination address space
• R1 SAVE update’s ASV at RN: <S1, S2, …, SN>
• RN SAVE update’s ASV after RN: <SN, SN+1, …>
• Any downstream SAVE routers after RN just concatenate both
20
10
4/17/2010
SAVE Protocol (Cont’d)
• SAVE overhead control
1. Do not append to a passing‐by update’s ASV
• If an update has already been sent
2. Do not send updates
• If the address spaces are already appended to a passing‐by update’s ASV
3. Do not forward replaceable updates
• If address spaces in the update’s ASV is included in the router’s source address space
21
Security of SAVE itself
• Essentially the same problem as securing routing protocol
• Requirements
– SAVE updates must only be exchanged between routers, excluding hosts
– Trust relationship between routers must be established beforehand
– SAVE updates must be signed or encrypted
– Processing of SAVE updates must be lightweight
22
11
4/17/2010
Simulation Goals
• Effectiveness
– Generates both valid and spoofing packets
• All spoofed packets should be caught and dropped
• Valid packets should not be dropped erroneously
• Transient behavior
– Route changes introduce a period for SAVE to adjust incoming table along the new route
• Few valid packets are desired to be dropped during this period • Cost
– Compare cost of SAVE with costs of routing protocols (BGP and RIP)
• Bandwidth cost, storage cost
23
Simulation ‐ Effectiveness
• Conditions
– Spoofed source addresses are randomly chosen
– Every router is under an average load condition
– A packet can only be dropped due to address filtering or routing inconsistency
• Result
– All spoofed packets are dropped under a DDoS
attack performed from three machines
24
12
4/17/2010
Simulation – Transient Behavior
• Valid packets can be dropped erroneously
– When route changes cause a forwarding table changes,
• Before the SAVE update is generated • While incoming tree and incoming table are updated
• Result
– “No filtering drops of valid packets due to routing changes.” That’s it…
25
Simulation – Storage Cost
• Compare size of incoming table used by SAVE with that of forwarding table used by RIP or BGP
• Incoming table optimization
– Point the same address spaces if incoming interface is identical to forwarding interface for that address space
– Use flag
26
13
4/17/2010
Simulation – Storage Cost (Cont’d)
27
Simulation – Storage Cost (Cont’d)
From authors’ slide…
28
14
4/17/2010
Simulation – Bandwidth Cost
• Compared periodic bandwidth cost of SAVE with that of RIP in single‐domain topologies
– Assume SAVE and routing updates are initiated with the same frequency
• SAVE has better scalability in single‐domain topologies
29
Simulation – Bandwidth Cost (Cont’d)
• Compared SAVE bandwidth in multiple‐domain topologies with BGP and RIP combined
• SAVE uses less than 60% of the bandwidth of BGP and RIP combined in the worst case
30
15
4/17/2010
Simulation – Bandwidth Cost (Cont’d)
• Compared the bandwidth cost of triggered SAVE updates with that of triggered routing updates
• SAVE has lower triggered bandwidth cost than routing protocols in most cases
– Topology changes cause routing updates, but not all of forwarding table changes, SAVE updates are not always triggered
31
Deployment Issue
• Partial deployment
– Packets are dropped if their source addresses are not found in a incoming table
• Flag for special handling
• Deliver to an intrusion detection system
32
16
4/17/2010
Deployment Issue (Cont’d)
• Mobile IP
– A mobile host’s packets are rejected outside of its home network
• Reverse tunneling: MN→FA→ HA→CN
• IPv6’s care‐of address: FA’s IP address
33
Deployment Issue (Cont’d)
• IP tunneling
– Must perform source validation before entering the tunnel
• IP Encapsulation
– In case of ignoring routing protocol, SAVE updates at the endpoint of a tunnel • Source routing
34
17
4/17/2010
Conclusion
• Filtering improperly addressed packets is worthwhile
• Asymmetric network routing demands an incoming table
• SAVE builds incoming tables correctly with low bandwidth and storage overhead
• SAVE has demonstrated its correctness and effectiveness through simulation
35
18