View
222
Download
0
Tags:
Embed Size (px)
Citation preview
SAVE: Source Address Validity Enforcement Protocol
Jun Li, Jelena Mirković, Mengqiu Wang, Peter Reiher and Lixia Zhang
UCLA Computer Science Dept10/04/2001
{lijun, sunshine, wangmq, reiher, lixia}@cs.ucla.edu
Outline
MotivationThe IdeaHandling Routing ChangesSecurity and DeploymentSimulation and ImplementationRelated WorkOngoing WorkConclusions
Motivation
Provide routers with information on the valid incoming interface for a given source address
Filter out packets with invalid source addresses
Would be helpful for Many security issues Building multicast trees Network problem debugging Services relying on accurate source addresses . . .
The Idea
Build an incoming table at a router that specifies valid incoming interfaces for address spacesCannot be derived from forwarding table due to
routing asymmetryCannot be designed by reversing routing
protocol• Should be designed to inform routers about the path
that has ALREADY been chosen
Cannot augment routing updates to carry SAVE info
So, how?
Desired Properties of SAVE
Routing protocol independence Immediate response to routing
changesSecurity Incremental deploymentLow overhead
Architecture
nofinal stop?
yes
generating SAVE updates
forwarding SAVE updates
SAVE updates
SAVE updates
incoming table
updatingincomingtree
end
forwarding table
1
2
3
4
A
B
Y
X
5
7
6
8
The green router now knows that messages from A and B should arrive on
interface 5
X A
X A
X AB
SAVE update
AB 5
Incoming table
X AX AX AX AX AX AX AX AX AX AX AX AX AX A
But the green incoming table says messages
from A come on interface 5, not
interface 6
X 4Y 3J 3A 1B 2
Forwarding table
Example
1
2
3
4
A
BY
X
X 4Y 3J 3A 1B 2
Forwarding table
Y AB
AB 9
9
10
11
12
1314
AB 13
Y AB
Example
1
2
3
4
A
BY
X
9
10
11
12
1314
ABP 13
Y ABP
P
Y AB
AB 9
Example
A
C
B
D
d=D, s=A
C
A d=D, s=A,CD
C
A
d=D
, s=B
B
Handling Routing Changes
1
2
3
1 2 3
A
C
B
D
C
A
d=D
, s=C
,B
D
C
A
d=D, s=C
B
Handling Routing Changes
1 2 3
1
2
3
A
C
B
D
C
A
d=D
, s=B
,C
D
d=D, s=C
B
Handling Routing Changes
1
2
3
1 3
C
A
Security of SAVE itself
Essentially the same problem as securing routing protocol
RequirementsSAVE updates must only be exchanged
between routers, excluding hostsTrust relationship between routers must be
established beforehandSAVE updates must be signed or encryptedProcessing of SAVE updates must be
lightweight
Deployment
Can only be incremental Have to deal with legacy routers Incoming table will not cover the whole Internet Deployment at different location has different
impact
Some real issues Mobile IP Tunnelling Multipath routing . . . . . .
Simulation
All routers run SAVE protocol + routing protocols
Transit-stub topology generated using GT-ITM
BGP as inter-domain routing protocol RIP as intra-domain routing protocol Some asymmetric routes
Simulation Goals
Effectiveness - are all spoofing packets successfully detected and dropped?
Correctness - are some valid packets dropped erroneously?
Transient behavior Cost
Each packet source generates both valid and spoofing packets
Spoofing source addresses randomly chosen from a pool of all source addresses in the network
Every router is under an average load condition
Results: In all scenarios all spoofing packets were detected
and dropped Without routing changes no valid packets were
dropped
Effectiveness and Correctness
Transient Behavior
Route changes introduce a transient period for SAVE to adjust every incoming table along the new route
During this period valid packets can be dropped on new route
Assuming that SAVE packets have same propagation delay as data packets, inconsistency occurs if: data packet is sent out on new route BEFORE new
SAVE update validating this route data packet is filtered at a router on the path
BEFORE new SAVE update is processed
Cost of SAVE
Compared cost of SAVE with costs of routing protocols (BGP and RIP)
Bandwidth cost:compared bandwidth consumed by SAVE
updates with that consumed by routing updates
Storage cost:compared the size of incoming table with
the size of forwarding table
0
10000
20000
30000
40000
50000
60000
70000
80000
10 20 30 40 50 60 70 80 90
# of routers
stor
age
cost
(ki
loby
tes)
forwarding table built by RIPincoming table built by SAVEoptimized incoming table built by SAVE
Storage Cost (single domain)
0
10000
20000
30000
40000
50000
60000
70000
80000
12 24 32 40 52 64 70 80 90
# of routers
stor
age
cost
(ki
loby
tes)
forwarding table built by BGPincoming table built by SAVEoptimized incoming table built by SAVE
Storage Cost (multiple domains)
Implementation in Linux
FORWARDING
TABLEFIREWALL
IP NEIGHBORMAP
KERNELKERNEL
BGPdOSPFd RIPd
ZEBRAd
ROUTINGROUTINGPROTOCOLPROTOCOL
NETLINK INTERFACENETLINK INTERFACE
SAVEd
FTABLE ITABLE ITREE INTMAP
SAVESAVE
Related Work
Cryptographic MethodsHigh computation overhead of
cryptographic operationsForwarding-table-based filtering
Routing asymmetry leads to erroneous packet dropping
Related Work
Ingress and egress filtering Very ineffective if partially deployed
Packet tracing Complex and expensive Ineffective when the volume of attack
traffic is small or the attack is distributedReactive, not preventive
On-going Work
Cooperation with Purdue University on partial deployment investigation
Implementation IXP router implementationCisco router implementation
TestingFTN testbedUtah testbed
IETF draft
Conclusions
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
Implementation is under way