SAVE: Source Address Validity Enforcement Protocol

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

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 X X X X X X X X X X X X X X X X A A A A A A A A A A A A A A A A 3 1 4 2 6 5 X AB X 4 SAVE update Y 3 7 8 J 3 AB 5 A 1 B 2 Incoming table Forwarding table 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 10 3 1 9 11 13 14 4 2 12 Y Y AB AB X 4 Y 3 J 3 AB 9 AB 13 A 1 B 2 Forwarding table A B Y X

9. Example P 10 3 1 9 11 13 14 4 2 12 Y Y ABP AB AB 9 ABP 13 A B Y X

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

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

12. Handling Routing Changes A B C A C 1 D 3 2 D C 1 3 d=D, s=C d=D, s=B,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. 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

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) 80000 70000 60000 50000 40000 storage cost (kilobytes) 30000 20000 10000 0 10 20 30 40 50 60 70 80 90 # of routers forwarding table built by RIP incoming table built by SAVE optimized incoming table built by SAVE

21. Storage Cost (multiple domains) 80000 70000 60000 50000 40000 storage cost (kilobytes) 30000 20000 10000 0 12 24 32 40 52 64 70 80 90 # of routers forwarding table built by BGP incoming table built by SAVE optimized incoming table built by SAVE

22. Implementation in Linux ROUTING PROTOCOL SAVE SAVEd ZEBRAd FTABLE ITABLE ITREE INTMAP BGPd OSPFd RIPd NETLINK INTERFACE FORWARDING TABLE FIREWALL IP NEIGHBOR MAP KERNEL

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

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

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

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