faculty of electrical engineering, technion fudico ii g. badishi & i. keidar towards...

Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo IIG. Badishi & I. KeidarG. Badishi & I. Keidar

Towards Survivability of Towards Survivability of Application-Level MulticastApplication-Level Multicast

Towards Survivability of Towards Survivability of Application-Level MulticastApplication-Level Multicast

Gal Badishi, Idit Keidar, Roie Gal Badishi, Idit Keidar, Roie MelamedMelamed

Gal Badishi, Idit Keidar, Roie Gal Badishi, Idit Keidar, Roie MelamedMelamed

G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II

OutlineOutlineOutlineOutline

• Threats and problemsThreats and problems

• Application-level multicastApplication-level multicast– Robust gossip - DrumRobust gossip - Drum– Robust overlay - AraneolaRobust overlay - Araneola

• Challenges and future directionsChallenges and future directions

• Threats and problemsThreats and problems

• Application-level multicastApplication-level multicast– Robust gossip - DrumRobust gossip - Drum– Robust overlay - AraneolaRobust overlay - Araneola

• Challenges and future directionsChallenges and future directions


The Net as a WarzoneThe Net as a WarzoneThe Net as a WarzoneThe Net as a Warzone

• Crash failures, message lossCrash failures, message loss

• Rapid dynamic changes – churnRapid dynamic changes – churn– Can cause denial of serviceCan cause denial of service

• Denial of Service (DoS)Denial of Service (DoS)

• Uncooperative usersUncooperative users

• Forgery/spoofingForgery/spoofing

• PenetrationPenetration

• Crash failures, message lossCrash failures, message loss

• Rapid dynamic changes – churnRapid dynamic changes – churn– Can cause denial of serviceCan cause denial of service

• Denial of Service (DoS)Denial of Service (DoS)

• Uncooperative usersUncooperative users

• Forgery/spoofingForgery/spoofing

• PenetrationPenetration


Denial of ServiceDenial of ServiceDenial of ServiceDenial of Service

• Unavailability of serviceUnavailability of service– Exhausting resourcesExhausting resources

• Remote attacksRemote attacks– Network levelNetwork level

•Solutions do not solve all application Solutions do not solve all application problemsproblems

– Application levelApplication level•Got little attentionGot little attention•Quantitative analysis of impact on application Quantitative analysis of impact on application

and identification of vulnerabilities neededand identification of vulnerabilities needed

• Unavailability of serviceUnavailability of service– Exhausting resourcesExhausting resources

• Remote attacksRemote attacks– Network levelNetwork level

•Solutions do not solve all application Solutions do not solve all application problemsproblems

– Application levelApplication level•Got little attentionGot little attention•Quantitative analysis of impact on application Quantitative analysis of impact on application

and identification of vulnerabilities neededand identification of vulnerabilities needed


DoS - ChallengesDoS - ChallengesDoS - ChallengesDoS - Challenges

• Quantify the effect of DoS at the Quantify the effect of DoS at the application levelapplication level

• Expose vulnerabilitiesExpose vulnerabilities

• Find effective DoS-mitigation Find effective DoS-mitigation techniquestechniques– Prove their usefulness using the found Prove their usefulness using the found

metricmetric

• Multicast as an exampleMulticast as an example

• Quantify the effect of DoS at the Quantify the effect of DoS at the application levelapplication level

• Expose vulnerabilitiesExpose vulnerabilities

• Find effective DoS-mitigation Find effective DoS-mitigation techniquestechniques– Prove their usefulness using the found Prove their usefulness using the found

metricmetric

• Multicast as an exampleMulticast as an example


Application-Level MulticastApplication-Level MulticastApplication-Level MulticastApplication-Level Multicast

• Tree-basedTree-based– Single points of failureSingle points of failure

• Gossip-basedGossip-based

• Overlay networksOverlay networks

• Tree-basedTree-based– Single points of failureSingle points of failure

• Gossip-basedGossip-based

• Overlay networksOverlay networks


Gossip-Based MulticastGossip-Based MulticastGossip-Based MulticastGossip-Based Multicast

• Progresses in roundsProgresses in rounds

• Every roundEvery round– Choose random partners Choose random partners – Send (push) or receive (pull) messagesSend (push) or receive (pull) messages– Discard old msgs from bufferDiscard old msgs from buffer

• Probabilistic reliabilityProbabilistic reliability

• Uses redundancy to achieve Uses redundancy to achieve robustnessrobustness

• Progresses in roundsProgresses in rounds

• Every roundEvery round– Choose random partners Choose random partners – Send (push) or receive (pull) messagesSend (push) or receive (pull) messages– Discard old msgs from bufferDiscard old msgs from buffer

• Probabilistic reliabilityProbabilistic reliability

• Uses redundancy to achieve Uses redundancy to achieve robustnessrobustness


Effects of DoS on GossipEffects of DoS on GossipEffects of DoS on GossipEffects of DoS on Gossip

• Surprisingly, we show that naïve Surprisingly, we show that naïve gossip is vulnerable to DoS attacksgossip is vulnerable to DoS attacks

• Attacking a process in pull-based Attacking a process in pull-based gossip may prevent it from gossip may prevent it from sendingsending messagesmessages

• Attacking a process in push-based Attacking a process in push-based gossip may prevent it from gossip may prevent it from receivingreceiving messagesmessages

• Surprisingly, we show that naïve Surprisingly, we show that naïve gossip is vulnerable to DoS attacksgossip is vulnerable to DoS attacks

• Attacking a process in pull-based Attacking a process in pull-based gossip may prevent it from gossip may prevent it from sendingsending messagesmessages

• Attacking a process in push-based Attacking a process in push-based gossip may prevent it from gossip may prevent it from receivingreceiving messagesmessages


Drum Drum [DSN 04][DSN 04]Drum Drum [DSN 04][DSN 04]

• A new gossip-based ALM protocolA new gossip-based ALM protocol• DoS-mitigation techniques:DoS-mitigation techniques:

– Using random one-time ports to Using random one-time ports to communicatecommunicate

– Combining both push and pullCombining both push and pull– Separating and bounding resourcesSeparating and bounding resources

• Eliminates vulnerabilities to DoSEliminates vulnerabilities to DoS• Proven robust using formal analysis Proven robust using formal analysis

and empirical measurementsand empirical measurements

• A new gossip-based ALM protocolA new gossip-based ALM protocol• DoS-mitigation techniques:DoS-mitigation techniques:

– Using random one-time ports to Using random one-time ports to communicatecommunicate

– Combining both push and pullCombining both push and pull– Separating and bounding resourcesSeparating and bounding resources

• Eliminates vulnerabilities to DoSEliminates vulnerabilities to DoS• Proven robust using formal analysis Proven robust using formal analysis

and empirical measurementsand empirical measurements


Random PortsRandom PortsRandom PortsRandom Ports

• Any request necessitating a reply Any request necessitating a reply contains a random port numbercontains a random port number– ““Invisible” to the attacker (e.g., Invisible” to the attacker (e.g.,

encrypted)encrypted)

• The reply is sent to that random portThe reply is sent to that random port

• Assumption: Network withstands loadAssumption: Network withstands load

• Any request necessitating a reply Any request necessitating a reply contains a random port numbercontains a random port number– ““Invisible” to the attacker (e.g., Invisible” to the attacker (e.g.,

encrypted)encrypted)

• The reply is sent to that random portThe reply is sent to that random port

• Assumption: Network withstands loadAssumption: Network withstands load


Combining Push and PullCombining Push and PullCombining Push and PullCombining Push and Pull

• Attacking push cannot prevent Attacking push cannot prevent receiving messages via pull (random receiving messages via pull (random ports)ports)

• Attacking pull cannot prevent Attacking pull cannot prevent sending via pushsending via push

• Each process has some control over Each process has some control over the processes it communicates withthe processes it communicates with

• Attacking push cannot prevent Attacking push cannot prevent receiving messages via pull (random receiving messages via pull (random ports)ports)

• Attacking pull cannot prevent Attacking pull cannot prevent sending via pushsending via push

• Each process has some control over Each process has some control over the processes it communicates withthe processes it communicates with


Bounding ResourcesBounding ResourcesBounding ResourcesBounding Resources

• Prevent resource exhaustionPrevent resource exhaustion

• Separate resources for orthogonal Separate resources for orthogonal operationsoperations

• Prevent resource exhaustionPrevent resource exhaustion

• Separate resources for orthogonal Separate resources for orthogonal operationsoperations


Evaluation: Staged DoS Evaluation: Staged DoS AttacksAttacks

Evaluation: Staged DoS Evaluation: Staged DoS AttacksAttacks

• Increasing strength Increasing strength – shows trend under DoSshows trend under DoS

• Fixed strength Fixed strength – exposes vulnerabilitiesexposes vulnerabilities

• Source is always attackedSource is always attacked

• Analysis, simulations, measurementsAnalysis, simulations, measurements

• Increasing strength Increasing strength – shows trend under DoSshows trend under DoS

• Fixed strength Fixed strength – exposes vulnerabilitiesexposes vulnerabilities

• Source is always attackedSource is always attacked

• Analysis, simulations, measurementsAnalysis, simulations, measurements


Analysis – Increasing Analysis – Increasing StrengthStrength

Analysis – Increasing Analysis – Increasing StrengthStrength

• Assume static group, strict subset is Assume static group, strict subset is attackedattacked

• Lemma 1Lemma 1: : Drum’s propagation time is Drum’s propagation time is bounded from above by a constant bounded from above by a constant independent of the attack rateindependent of the attack rate

• Lemma 2Lemma 2: : The propagation time of Push The propagation time of Push grows at least linearly with the attack rategrows at least linearly with the attack rate

• Lemma 3Lemma 3: : The propagation time of Pull The propagation time of Pull grows at least linearly with the attack rategrows at least linearly with the attack rate

• Assume static group, strict subset is Assume static group, strict subset is attackedattacked

• Lemma 1Lemma 1: : Drum’s propagation time is Drum’s propagation time is bounded from above by a constant bounded from above by a constant independent of the attack rateindependent of the attack rate

• Lemma 2Lemma 2: : The propagation time of Push The propagation time of Push grows at least linearly with the attack rategrows at least linearly with the attack rate

• Lemma 3Lemma 3: : The propagation time of Pull The propagation time of Pull grows at least linearly with the attack rategrows at least linearly with the attack rate


0 20 40 60 80 100 120 1400

5

10

15

20

25

30

Attack Rate

# ro

un

ds

Expected Propagation Time, 10% Attacked

Push, n = 1000Push, n = 120Pull, n = 1000Pull, n = 120Drum, n = 1000Drum, n = 120


0 20 40 60 80 100 120 1400

5

10

15

20

25

30Expected Propagation Time, 10% Attacked (of 1000)

Attack Rate

# ro

un

ds

Drum - Known PortsDrum - Random Ports


0 20 40 60 80 100 120 1400

2

4

6

8

10

12

Attack Rate

# ro

un

ds

Expected Propagation Time, 10% Attacked (of 50)

Drum - Shared BoundsDrum - Separate Bounds


Analysis – Fixed StrengthAnalysis – Fixed StrengthAnalysis – Fixed StrengthAnalysis – Fixed Strength

• Lemma 4Lemma 4: : For strong enough attacks, For strong enough attacks, Drum’s expected propagation time is Drum’s expected propagation time is monotonically increasing as the monotonically increasing as the percentage of attacked processes percentage of attacked processes increasesincreases

• Lemma 4Lemma 4: : For strong enough attacks, For strong enough attacks, Drum’s expected propagation time is Drum’s expected propagation time is monotonically increasing as the monotonically increasing as the percentage of attacked processes percentage of attacked processes increasesincreases


0 10 20 30 40 50 60 70 80 900

10

20

30

40

50

60

70

80

90

100#

rou

nd

s

% attacked processes

Expected Propagation Time, Fixed Strength (c = 10)

Push, n = 120Push, n = 500Pull, n = 120Pull, n = 500Drum, n = 120Drum, n = 500


General PrinciplesGeneral PrinciplesGeneral PrinciplesGeneral Principles

• Network-level DoS mitigation necessary Network-level DoS mitigation necessary but not sufficient: application needs but not sufficient: application needs consideration too!consideration too!

• DoS-mitigation techniques: DoS-mitigation techniques: – random portsrandom ports– neighbor-selection by local choicesneighbor-selection by local choices– separate resource boundsseparate resource bounds

• Design goal: eliminate vulnerabilities Design goal: eliminate vulnerabilities – The most effective attack is a broad oneThe most effective attack is a broad one

• Analysis and quantitative evaluation of Analysis and quantitative evaluation of impact of DoSimpact of DoS

• Network-level DoS mitigation necessary Network-level DoS mitigation necessary but not sufficient: application needs but not sufficient: application needs consideration too!consideration too!

• DoS-mitigation techniques: DoS-mitigation techniques: – random portsrandom ports– neighbor-selection by local choicesneighbor-selection by local choices– separate resource boundsseparate resource bounds

• Design goal: eliminate vulnerabilities Design goal: eliminate vulnerabilities – The most effective attack is a broad oneThe most effective attack is a broad one

• Analysis and quantitative evaluation of Analysis and quantitative evaluation of impact of DoSimpact of DoS


Further ChallengesFurther ChallengesFurther ChallengesFurther Challenges

• Not bandwidth-optimizedNot bandwidth-optimized– Reliability is achieved at the cost of high Reliability is achieved at the cost of high

redundancyredundancy

• Rapid change in communication Rapid change in communication partners makes diagnosis of partners makes diagnosis of neighbors’ correct operation difficultneighbors’ correct operation difficult– Hard to incentivize cooperationHard to incentivize cooperation

• Not bandwidth-optimizedNot bandwidth-optimized– Reliability is achieved at the cost of high Reliability is achieved at the cost of high

redundancyredundancy

• Rapid change in communication Rapid change in communication partners makes diagnosis of partners makes diagnosis of neighbors’ correct operation difficultneighbors’ correct operation difficult– Hard to incentivize cooperationHard to incentivize cooperation


AraneolaAraneolaAraneolaAraneola

• Overlay-based application-level multicastOverlay-based application-level multicast

• Bandwidth efficiency:Bandwidth efficiency:– Basic overlay: random links, low degrees for Basic overlay: random links, low degrees for all all

nodesnodes– Add local links according to available bandwidthAdd local links according to available bandwidth

• Robustness to link & node failuresRobustness to link & node failures

• Cheap maintenanceCheap maintenance– Amortize join/leave costsAmortize join/leave costs– Can handle high churnCan handle high churn

• Overlay-based application-level multicastOverlay-based application-level multicast

• Bandwidth efficiency:Bandwidth efficiency:– Basic overlay: random links, low degrees for Basic overlay: random links, low degrees for all all

nodesnodes– Add local links according to available bandwidthAdd local links according to available bandwidth

• Robustness to link & node failuresRobustness to link & node failures

• Cheap maintenanceCheap maintenance– Amortize join/leave costsAmortize join/leave costs– Can handle high churnCan handle high churn


Basic (Random) OverlayBasic (Random) OverlayBasic (Random) OverlayBasic (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


Overhead for Dealing with Join/Leave Operations

Overhead for Dealing with Join/Leave Operations


Impact of Edge Failures Impact of Edge Failures on Connectivityon Connectivity

Impact of Edge Failures Impact of Edge Failures on Connectivityon Connectivity


Impact of Node Failures Impact of Node Failures on Connectivityon Connectivity

Impact of Node Failures Impact of Node Failures on Connectivityon Connectivity


Further ChallengesFurther ChallengesFurther ChallengesFurther Challenges

• Does not currently deal with Does not currently deal with – DoSDoS– uncooperative usersuncooperative users– non-random link/node failuresnon-random link/node failures

• Does not currently deal with Does not currently deal with – DoSDoS– uncooperative usersuncooperative users– non-random link/node failuresnon-random link/node failures


Future DirectionsFuture DirectionsFuture DirectionsFuture Directions

• Can we get the best of all worlds? Can we get the best of all worlds? – BW/latency efficient, churn/DoS resistant, detects BW/latency efficient, churn/DoS resistant, detects

incorrect nodes, overcomes adversarial failures…incorrect nodes, overcomes adversarial failures…

• Test neighbors for cooperativenessTest neighbors for cooperativeness– Communicate with same neighbors for long periods 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 insteadUse pseudo-random ports instead– Challenge: agree upon seeds without exposing themChallenge: 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 BW/latency efficient, churn/DoS resistant, detects

incorrect nodes, overcomes adversarial failures…incorrect nodes, overcomes adversarial failures…

• Test neighbors for cooperativenessTest neighbors for cooperativeness– Communicate with same neighbors for long periods 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 insteadUse pseudo-random ports instead– Challenge: agree upon seeds without exposing themChallenge: agree upon seeds without exposing them

faculty of electrical engineering, technion fudico ii g. badishi & i. keidar towards...

Documents

application problems

survivability of application

dos challenges

effect of dos

level multicast gal

example multicast

problems threats

metric multicast