SAVE: Source Address Validity Enforcement Protocol Jun Li, Jelena Mirković, Mengqiu Wang, Peter Reiher and Lixia Zhang UCLA Computer Science Dept 10/04/2001 {lijun, sunshine, wangmq, reiher,

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

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 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?

Desired Properties of SAVE  Routing protocol independence  Immediate response to routing changes  Security  Incremental deployment  Low overhead

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

A B Y X The green router now knows that messages from A and B should arrive on interface 5 XAXA XAB SAVE update AB5 Incoming table XAXAXAXAXAXAXAXAXAXAXAXAXAXA But the green incoming table says messages from A come on interface 5, not interface 6 X4X4 Y3Y3 J3J3 A1A1 B2B2 Forwarding table Example

A B Y X X4X4 Y3Y3 J3J3 A1A1 B2B2 Forwarding table YAB AB AB13 YAB Example

A B Y X ABP13 YABP P YAB AB9 Example

A C B D d=D, s=A C A d=D, s=A,C D CA d=D, s=B B Handling Routing Changes

A C B D C A d=D, s=C,B D CA d=D, s=C B Handling Routing Changes

A C B D C A d=D, s=B,C D d=D, s=C B Handling Routing Changes C A

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

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

# of routers storage cost (kilobytes) forwarding table built by RIP incoming table built by SAVE optimized incoming table built by SAVE Storage Cost (single domain)

# of routers storage cost (kilobytes) forwarding table built by BGP incoming table built by SAVE optimized incoming table built by SAVE Storage Cost (multiple domains)

# of routers periodic bandwidth ratio SAVE/RIP Periodic Bandwidth (single domain )

# of routers bandwidth ratio SAVE/(BGP+RIP) Periodic Bandwidth (multiple domains)

# of failed links triggered bandwidth ratio SAVE/(BGP+RIP) Triggered Bandwidth (multiple domains)

Implementation in Linux FORWARDING TABLE FIREWALL IP NEIGHBOR MAP KERNEL BGPdOSPFdRIPd ZEBRAd ROUTINGPROTOCOL NETLINK INTERFACE SAVEd FTABLEITABLEITREEINTMAP SAVE

Related Work  Cryptographic Methods  High computation overhead of cryptographic operations  Forwarding-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 distributed  Reactive, not preventive

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

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