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