1. Faculty of Electrical Engineering, Technion FuDiCo II G. Badishi & I. Keidar Towards Survivability of Application-Level Multicast Gal Badishi, Idit Keidar, Roie Melamed

2. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II OutlineOutline Threats and problems Threats and problems Application-level multicast Application-level multicast –Robust gossip - Drum –Robust overlay - Araneola Challenges and future directions Challenges and future directions Threats and problems Threats and problems Application-level multicast Application-level multicast –Robust gossip - Drum –Robust overlay - Araneola Challenges and future directions Challenges and future directions

3. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II The Net as a Warzone Crash failures, message loss Crash failures, message loss Rapid dynamic changes – churn Rapid dynamic changes – churn –Can cause denial of service Denial of Service (DoS) Denial of Service (DoS) Uncooperative users Uncooperative users Forgery/spoofing Forgery/spoofing Penetration Penetration Crash failures, message loss Crash failures, message loss Rapid dynamic changes – churn Rapid dynamic changes – churn –Can cause denial of service Denial of Service (DoS) Denial of Service (DoS) Uncooperative users Uncooperative users Forgery/spoofing Forgery/spoofing Penetration Penetration

4. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Denial of Service Unavailability of service Unavailability of service –Exhausting resources Remote attacks Remote attacks –Network level Solutions do not solve all application problems Solutions do not solve all application problems –Application level Got little attention Got little attention Quantitative analysis of impact on application and identification of vulnerabilities needed Quantitative analysis of impact on application and identification of vulnerabilities needed Unavailability of service Unavailability of service –Exhausting resources Remote attacks Remote attacks –Network level Solutions do not solve all application problems Solutions do not solve all application problems –Application level Got little attention Got little attention Quantitative analysis of impact on application and identification of vulnerabilities needed Quantitative analysis of impact on application and identification of vulnerabilities needed

5. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II DoS - Challenges Quantify the effect of DoS at the application level Quantify the effect of DoS at the application level Expose vulnerabilities Expose vulnerabilities Find effective DoS-mitigation techniques Find effective DoS-mitigation techniques –Prove their usefulness using the found metric Multicast as an example Multicast as an example Quantify the effect of DoS at the application level Quantify the effect of DoS at the application level Expose vulnerabilities Expose vulnerabilities Find effective DoS-mitigation techniques Find effective DoS-mitigation techniques –Prove their usefulness using the found metric Multicast as an example Multicast as an example

6. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Application-Level Multicast Tree-based Tree-based –Single points of failure Gossip-based Gossip-based Overlay networks Overlay networks Tree-based Tree-based –Single points of failure Gossip-based Gossip-based Overlay networks Overlay networks

7. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Gossip-Based Multicast Progresses in rounds Progresses in rounds Every round Every round –Choose random partners –Send (push) or receive (pull) messages –Discard old msgs from buffer Probabilistic reliability Probabilistic reliability Uses redundancy to achieve robustness Uses redundancy to achieve robustness Progresses in rounds Progresses in rounds Every round Every round –Choose random partners –Send (push) or receive (pull) messages –Discard old msgs from buffer Probabilistic reliability Probabilistic reliability Uses redundancy to achieve robustness Uses redundancy to achieve robustness

8. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Effects of DoS on Gossip Surprisingly, we show that naïve gossip is vulnerable to DoS attacks Surprisingly, we show that naïve gossip is vulnerable to DoS attacks Attacking a process in pull-based gossip may prevent it from sending messages Attacking a process in pull-based gossip may prevent it from sending messages Attacking a process in push-based gossip may prevent it from receiving messages Attacking a process in push-based gossip may prevent it from receiving messages Surprisingly, we show that naïve gossip is vulnerable to DoS attacks Surprisingly, we show that naïve gossip is vulnerable to DoS attacks Attacking a process in pull-based gossip may prevent it from sending messages Attacking a process in pull-based gossip may prevent it from sending messages Attacking a process in push-based gossip may prevent it from receiving messages Attacking a process in push-based gossip may prevent it from receiving messages

9. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Drum [DSN 04] A new gossip-based ALM protocol A new gossip-based ALM protocol DoS-mitigation techniques: DoS-mitigation techniques: –Using random one-time ports to communicate –Combining both push and pull –Separating and bounding resources Eliminates vulnerabilities to DoS Eliminates vulnerabilities to DoS Proven robust using formal analysis and empirical measurements Proven robust using formal analysis and empirical measurements A new gossip-based ALM protocol A new gossip-based ALM protocol DoS-mitigation techniques: DoS-mitigation techniques: –Using random one-time ports to communicate –Combining both push and pull –Separating and bounding resources Eliminates vulnerabilities to DoS Eliminates vulnerabilities to DoS Proven robust using formal analysis and empirical measurements Proven robust using formal analysis and empirical measurements

10. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Random Ports Any request necessitating a reply contains a random port number Any request necessitating a reply contains a random port number –“Invisible” to the attacker (e.g., encrypted) The reply is sent to that random port The reply is sent to that random port Assumption: Network withstands load Assumption: Network withstands load Any request necessitating a reply contains a random port number Any request necessitating a reply contains a random port number –“Invisible” to the attacker (e.g., encrypted) The reply is sent to that random port The reply is sent to that random port Assumption: Network withstands load Assumption: Network withstands load

11. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Combining Push and Pull Attacking push cannot prevent receiving messages via pull (random ports) Attacking push cannot prevent receiving messages via pull (random ports) Attacking pull cannot prevent sending via push Attacking pull cannot prevent sending via push Each process has some control over the processes it communicates with Each process has some control over the processes it communicates with Attacking push cannot prevent receiving messages via pull (random ports) Attacking push cannot prevent receiving messages via pull (random ports) Attacking pull cannot prevent sending via push Attacking pull cannot prevent sending via push Each process has some control over the processes it communicates with Each process has some control over the processes it communicates with

12. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Bounding Resources Prevent resource exhaustion Prevent resource exhaustion Separate resources for orthogonal operations Separate resources for orthogonal operations Prevent resource exhaustion Prevent resource exhaustion Separate resources for orthogonal operations Separate resources for orthogonal operations

13. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Evaluation: Staged DoS Attacks Increasing strength Increasing strength –shows trend under DoS Fixed strength Fixed strength –exposes vulnerabilities Source is always attacked Source is always attacked Analysis, simulations, measurements Analysis, simulations, measurements Increasing strength Increasing strength –shows trend under DoS Fixed strength Fixed strength –exposes vulnerabilities Source is always attacked Source is always attacked Analysis, simulations, measurements Analysis, simulations, measurements

14. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Analysis – Increasing Strength Assume static group, strict subset is attacked Assume static group, strict subset is attacked Lemma 1: Drum’s propagation time is bounded from above by a constant independent of the attack rate Lemma 1: Drum’s propagation time is bounded from above by a constant independent of the attack rate Lemma 2: The propagation time of Push grows at least linearly with the attack rate Lemma 2: The propagation time of Push grows at least linearly with the attack rate Lemma 3: The propagation time of Pull grows at least linearly with the attack rate Lemma 3: The propagation time of Pull grows at least linearly with the attack rate Assume static group, strict subset is attacked Assume static group, strict subset is attacked Lemma 1: Drum’s propagation time is bounded from above by a constant independent of the attack rate Lemma 1: Drum’s propagation time is bounded from above by a constant independent of the attack rate Lemma 2: The propagation time of Push grows at least linearly with the attack rate Lemma 2: The propagation time of Push grows at least linearly with the attack rate Lemma 3: The propagation time of Pull grows at least linearly with the attack rate Lemma 3: The propagation time of Pull grows at least linearly with the attack rate

15. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II

16. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II

17. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II

18. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Analysis – Fixed Strength Lemma 4: For strong enough attacks, Drum’s expected propagation time is monotonically increasing as the percentage of attacked processes increases Lemma 4: For strong enough attacks, Drum’s expected propagation time is monotonically increasing as the percentage of attacked processes increases

19. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II

20. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II General Principles Network-level DoS mitigation necessary but not sufficient: application needs consideration too! Network-level DoS mitigation necessary but not sufficient: application needs consideration too! DoS-mitigation techniques: DoS-mitigation techniques: –random ports –neighbor-selection by local choices –separate resource bounds Design goal: eliminate vulnerabilities Design goal: eliminate vulnerabilities –The most effective attack is a broad one Analysis and quantitative evaluation of impact of DoS Analysis and quantitative evaluation of impact of DoS Network-level DoS mitigation necessary but not sufficient: application needs consideration too! Network-level DoS mitigation necessary but not sufficient: application needs consideration too! DoS-mitigation techniques: DoS-mitigation techniques: –random ports –neighbor-selection by local choices –separate resource bounds Design goal: eliminate vulnerabilities Design goal: eliminate vulnerabilities –The most effective attack is a broad one Analysis and quantitative evaluation of impact of DoS Analysis and quantitative evaluation of impact of DoS

21. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Further Challenges Not bandwidth-optimized Not bandwidth-optimized –Reliability is achieved at the cost of high redundancy Rapid change in communication partners makes diagnosis of neighbors’ correct operation difficult Rapid change in communication partners makes diagnosis of neighbors’ correct operation difficult –Hard to incentivize cooperation Not bandwidth-optimized Not bandwidth-optimized –Reliability is achieved at the cost of high redundancy Rapid change in communication partners makes diagnosis of neighbors’ correct operation difficult Rapid change in communication partners makes diagnosis of neighbors’ correct operation difficult –Hard to incentivize cooperation

22. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II AraneolaAraneola Overlay-based application-level multicast Overlay-based application-level multicast Bandwidth efficiency: Bandwidth efficiency: –Basic overlay: random links, low degrees for all nodes –Add local links according to available bandwidth Robustness to link & node failures Robustness to link & node failures Cheap maintenance Cheap maintenance –Amortize join/leave costs –Can handle high churn Overlay-based application-level multicast Overlay-based application-level multicast Bandwidth efficiency: Bandwidth efficiency: –Basic overlay: random links, low degrees for all nodes –Add local links according to available bandwidth Robustness to link & node failures Robustness to link & node failures Cheap maintenance Cheap maintenance –Amortize join/leave costs –Can handle high churn

23. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Basic (Random) Overlay For k ≥ 3, approximate k-regular random graph: – –each node has either k or k+1 random neighbors – –logarithmic diameter – –k-connected – –expander, remains highly connected following random removal of large subsets of edges or nodes Cheap maintenance: each join or leave operation incurs sending only a total of about 3k messages For k ≥ 3, approximate k-regular random graph: – –each node has either k or k+1 random neighbors – –logarithmic diameter – –k-connected – –expander, remains highly connected following random removal of large subsets of edges or nodes Cheap maintenance: each join or leave operation incurs sending only a total of about 3k messages

24. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Multicasting on the Overlay Each process gossips about recent message identifiers with overlay neighbors Each process gossips about recent message identifiers with overlay neighbors –instead of random processes –identifiers flooded –messages sent to those who miss them Converges much faster than basic gossip-based protocol with the same fan-out Converges much faster than basic gossip-based protocol with the same fan-out –unlike gossip, 100% reliability without sending identifiers more than once Each process gossips about recent message identifiers with overlay neighbors Each process gossips about recent message identifiers with overlay neighbors –instead of random processes –identifiers flooded –messages sent to those who miss them Converges much faster than basic gossip-based protocol with the same fan-out Converges much faster than basic gossip-based protocol with the same fan-out –unlike gossip, 100% reliability without sending identifiers more than once

25. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Araneola vs Gossip, 1000 Nodes

26. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Overhead for Dealing with Join/Leave Operations

27. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Impact of Edge Failures on Connectivity

28. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Impact of Node Failures on Connectivity

29. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Further Challenges Does not currently deal with Does not currently deal with –DoS –uncooperative users –non-random link/node failures Does not currently deal with Does not currently deal with –DoS –uncooperative users –non-random link/node failures

30. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II Future Directions Can we get the best of all worlds? Can we get the best of all worlds? –BW/latency efficient, churn/DoS resistant, detects incorrect nodes, overcomes adversarial failures… Test neighbors for cooperativeness Test neighbors for cooperativeness –Communicate with same neighbors for long periods Can we eliminate well-known ports altogether? Can we eliminate well-known ports altogether? –Use pseudo-random ports instead –Challenge: agree upon seeds without exposing them Can we get the best of all worlds? Can we get the best of all worlds? –BW/latency efficient, churn/DoS resistant, detects incorrect nodes, overcomes adversarial failures… Test neighbors for cooperativeness Test neighbors for cooperativeness –Communicate with same neighbors for long periods Can we eliminate well-known ports altogether? Can we eliminate well-known ports altogether? –Use pseudo-random ports instead –Challenge: agree upon seeds without exposing them

31. G. Badishi & I.KeidarFaculty of Electrical Engineering, TechnionFuDiCo II