faculty of electrical engineering, technion fudico ii g. badishi & i. keidar towards...
Post on 20-Dec-2015
221 views
TRANSCRIPT
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
Overhead for Dealing with Join/Leave Operations
Overhead for Dealing with Join/Leave Operations
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
Impact of Edge Failures Impact of Edge Failures on Connectivityon Connectivity
Impact of Edge Failures Impact of Edge Failures on Connectivityon Connectivity
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
Impact of Node Failures Impact of Node Failures on Connectivityon Connectivity
Impact of Node Failures Impact of Node Failures on Connectivityon Connectivity
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II
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
G. Badishi & I.KeidarG. Badishi & I.Keidar Faculty of Electrical Engineering, TechnionFaculty of Electrical Engineering, Technion FuDiCo IIFuDiCo II