2. 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, lixia}@cs.ucla.edu

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

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

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

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

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

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

9. 1 2 3 4 A B Y X X4X4 Y3Y3 J3J3 A1A1 B2B2 Forwarding table YAB AB9 9 10 11 12 13 14 AB13 YAB Example

10. 1 2 3 4 A B Y X 9 10 11 12 13 14 ABP13 YABP P YAB AB9 Example

11. 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 1 2 3 1 2 3

12. A C B D C A d=D, s=C,B D CA d=D, s=C B Handling Routing Changes 1 2 3 1 2 3

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

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

15. 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 ......

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

17. Simulation Goals  Effectiveness - are all spoofing packets successfully detected and dropped?  Correctness - are some valid packets dropped erroneously?  Transient behavior  Cost

18.  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

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

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

21. 0 10000 20000 30000 40000 50000 60000 70000 80000 102030405060708090 # 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)

22. 0 10000 20000 30000 40000 50000 60000 70000 80000 122432405264708090 # 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)

23. 0 0.5 1 1.5 2 2.5 102030405060708090 # of routers periodic bandwidth ratio SAVE/RIP Periodic Bandwidth (single domain )

24. 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 122432405264708090 # of routers bandwidth ratio SAVE/(BGP+RIP) Periodic Bandwidth (multiple domains)

25. 0 0.2 0.4 0.6 0.8 1 1.2 123456789 # of failed links triggered bandwidth ratio SAVE/(BGP+RIP) Triggered Bandwidth (multiple domains)

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

27. Related Work  Cryptographic Methods  High computation overhead of cryptographic operations  Forwarding-table-based filtering  Routing asymmetry leads to erroneous packet dropping

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

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

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