SAVE: Source Address Validity Enforcement Protocol

1
SAVE Source Address Validity Enforcement Protocol

• Jun Li, Jelena Mirkovic, Mengqiu Wang,
• Peter Reiher and Lixia Zhang
• UCLA Computer Science Dept
• 10/04/2001
• lijun, sunshine, wangmq, reiher,
  lixia_at_cs.ucla.edu

2
Outline

• Motivation
• The Idea
• Handling Routing Changes
• Security and Deployment
• Simulation and Implementation
• Related Work
• Ongoing Work
• Conclusions

3
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 . .
  .

4
The Idea

• Build an incoming table at a router that
  specifies valid incoming interfaces for address
  spaces
• Cannot be derived from forwarding table due to
  routing asymmetry
• Cannot 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?

5
Desired Properties of SAVE

• Routing protocol independence
• Immediate response to routing changes
• Security
• Incremental deployment
• Low overhead

6
Architecture
incoming table
forwarding table
SAVE updates
updating incoming tree
generating SAVE updates
SAVE updates
final stop?
forwarding SAVE updates
no
yes
end
7
Example

A
B
Y
But the green incoming table says messages from A
come on interface 5, not interface 6
The green router now knows that messages from A
and B should arrive on interface 5
X
8
Example

A
B
Y
X
9
Example

A
B
Y
X
10
Handling Routing Changes
C
1
D
2
3
dD, sA,C
2
D
C
1
3
dD, sA
dD, sB
A
B
11
Handling Routing Changes
C
1
D
2
3
2
D
C
1
3
dD, sC
dD, sC,B
A
B
12
Handling Routing Changes
C
1
D
3
2
D
C
1
3
dD, sC
dD, sB,C
A
B
13
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

14
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
• . . . . . .

15
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

16
Simulation Goals

• Effectiveness - are all spoofing packets
  successfully detected and dropped?
• Correctness - are some valid packets dropped
  erroneously?
• Transient behavior
• Cost

17
Effectiveness and Correctness

• 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

18
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

19
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

20
Storage Cost (single domain)
21
Storage Cost (multiple domains)
22
Periodic Bandwidth (single domain )
2.5
2
1.5
periodic bandwidth ratio
SAVE/RIP
1
0.5
0
10
20
30
40
50
60
70
80
90
of routers
23
Periodic Bandwidth (multiple domains)
0.7
0.6
0.5
0.4
bandwidth ratio
SAVE/(BGPRIP)
0.3
0.2
0.1
0
12
24
32
40
52
64
70
80
90
of routers
24
Triggered Bandwidth (multiple domains)
1.2
1
0.8
SAVE/(BGPRIP)
triggered bandwidth ratio
0.6
0.4
0.2
0
1
2
3
4
5
6
7
8
9
of failed links
25
Implementation in Linux
ROUTING PROTOCOL
SAVE
SAVEd
ZEBRAd
FTABLE
ITABLE
ITREE
INTMAP
BGPd
OSPFd
RIPd
NETLINK INTERFACE

FORWARDING TABLE
FIREWALL
IP NEIGHBOR MAP
KERNEL
26
Related Work

• Cryptographic Methods
• High computation overhead of cryptographic
  operations
• Forwarding-table-based filtering
• Routing asymmetry leads to erroneous packet
  dropping

27
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 distributed
• Reactive, not preventive

28
On-going Work

• Cooperation with Purdue University on partial
  deployment investigation
• Implementation
• IXP router implementation
• Cisco router implementation
• Testing
• FTN testbed
• Utah testbed
• IETF draft

29
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