国外优秀计算机类博士答辩ppt-thesisakuzma.ppt

Ph.D. Thesis Presentation Aleksandar Kuzmanovic,Edge-based Inference, Control, and DoS Resilience for the Internet,The Internet,1969,The system of astonishing scale and complexity,2004,Internet Design Principles,Network as a black-box,End-to-end argument Clark84 The core is simple Intelligence at the endpoints,Implications Easy to upgrade the network Easy to incrementally deploy new services,Why End-Point Approach Today?,Scalability e2e scalability Deployability IP and network core are not extensible and are slowly evolving: IPv6 (10 years) IP Multicast (domain dependent),Goal: Improve network performance right here right now!,Network Performance,Internet traffic HTTP (web browsing) FTP (file transfer) Fact: 95% of the traffic today is TCP-based Performance QoS differentiation Net win for both HTTP and FTP flows End-point-based two-level differentiation scheme Denial of Service DoS attacks can demolish network performance Prevent DoS attacks via a robust end-point protocol design,End-Point Service Differentiation,TCP-Low Priority Utilizes only the excess network bandwidth Key mechanism Early congestion indications: one-way packet delay Performance Can improve the HTTP file transfers for more than 90% when FTP flows use TCP-LP Deployability no changes in the network core sender side modification of TCP High-speed version developed in cooperation with SLAC tested over Gb/s networks in US /networks/TCP-LP,Denial of Service,A malicious way to consume resources in a network, a server cluster or in an end host, thereby denying service to other legitimate users Example Well-known TCPs vulnerability to high-rate non-responsive flows,Design Principles - Revisited,Design Principles Intelligence at the endpoints The core is simple Trust and cooperation among the endpoints,Implications Easy to incrementally implement new services,. Easy to upgrade the network,. Large-scale system,Implement more intelligence at routers? Scalability issue Detect misbehaving flows in routers is a hard problem Needle in a haystack,Design Principles - Revisited,Design Principles Intelligence at the endpoints The core is simple Trust and cooperation among the endpoints,Implications Malicious clients may misuse the intelligence,. Easy to upgrade the network,. Large-scale system,Implement more intelligence at routers? Scalability issue Detect misbehaving flows in routers is a hard problem Needle in a haystack,Design Principles - Revisited,Design Principles Intelligence at the endpoints The core is simple Trust and cooperation among the endpoints,. Hard to detect endpoint misbehavior,. Large-scale system,Malicious clients may misuse the intelligence,Implications,Implement more intelligence at routers? Scalability issue Detect misbehaving flows in routers is a hard problem Needle in a haystack,Design Principles - Revisited,Design Principles Intelligence at the endpoints The core is simple Trust and cooperation among the endpoints,. Hard to detect endpoint misbehavior,. Large-scale system,Malicious clients may misuse the intelligence,Implications,Implement more intelligence at routers? Scalability issue Detect misbehaving flows in routers is a hard problem Needle in a haystack,End-Point Protocol Design,Performance vs. Security End-point protocols are designed to maximize performance, but ignore security 95% of the Internet traffic is TCP traffic Can have catastrophic consequences DoS-resilient protocol design Jointly optimize performance and security Outperforms the core-based solutions,Remaining Outline,End-point protocol vulnerabilities Low-rate TCP-targeted DoS attacks Receiver-based TCP stacks with a misbehaving receiver Limitations of network-based solutions DoS-resilient end-point protocol design,Low-Rate Attacks,TCP is vulnerable to low-rate DoS attacks,TCP: a Dual Time-Scale Perspective,Two time-scales fundamentally required RTT time-scales (10-100 ms) AIMD control RTO time-scales (RTO=SRTT+4*RTTVAR) Avoid congestion collapse Lower-bounding the RTO parameter: AllPax99: minRTO = 1 sec to avoid spurious retransmissions RFC2988 recommends minRTO = 1 sec,The Low-Rate Attack,The Low-Rate Attack,At a random initial time A short burst (RTT) sufficient to create outage Outage event of correlated packet losses that forces TCP to enter RTO mechanism The impact of outage is distributed to all TCP flows,The Low-Rate Attack,The outage synchronizes all TCP flows All flows react simultaneously and identically backoff for minRTO The attacker stops transmitting to elude detection,The Low-Rate Attack,Once the TCP flows try to recover hit them again Exploit protocol determinism,The Low-Rate Attack,And keep repeating RTT-time-scale outages inter-spaced on minRTO periods can deny service to TCP traffic,Low-Rate Attacks,TCP is vulnerable to low-rate DoS attacks,Vulnerability of Receiver-Based TCP to Misbehaviors,Sender-based TCP Control functions given to the sender,Receiver-Based TCP,Receiver decides how much data can be sent, and which data should be sent by the sender DATA ACK communication becomes REQ - DATA Example protocols TFRC RFC3448, WebTP, and RCP,Why Receiver-Based TCP?,Example: Busy web server Receiver-based TCP distributes the state management across a large number of clients Generally Whenever a feedback is needed from the receiver, receiver-based TCP has advantage over sender-based schemes due to the locality of information Benefits RCP03 Performance Functionality - Loss recovery - Seamless handoffs - Congestion control - Server migration - Power management for - Bandwidth aggregation mobile devices - Web response times - Network-specific congestion control,Vulnerability,Receivers decide which packets and when to be sent Receivers remotely control servers Receivers have both means and incentive to manipulate the congestion control algorithm Means: open source OS Incentive: faster web browsing & file download,Receiver-Induced DoS Attacks,Request flood attack A misbehaving receiver floods the server with requests, which replies and congests the network Goals Evaluate network-based schemes Develop end-point solutions,Remaining Outline,End-Point protocol vulnerabilities Limitations of network-based solutions Low rate attacks Misbehaving receivers DoS-resilient end-point protocol design,Random Early Detection with Preferential Dropping,RED-PD MFW01 designed to detect and thwart non-responsive flows Monitors only a subset of flows at the router and compares their rates to the targeted bandwidth (TB) TB is computed as a TCP-fair throughput for Observed Ploss & RTT=40ms If Ti TB = flow i malicious Key questions Can algorithms intended to find high-rate attacks detect low-rate attacks? Could we tune the algorithms to detect low-rate attacks without having too many false alarms?,The Time-Scale Issue,Scenario: 9 TCP Sack flows with RED and RED-PD RED-PD detects high bandwidth flows DoS inter-burst period 500 ms,The Time-Scale Issue,Scenario: 9 TCP Sack flows with RED and RED-PD RED-PD detects high but fails to detect low-rate attacks bandwidth flows DoS inter-burst period 500 ms DoS inter-burst period 500 ms,CHOKe,CHOKe PPP00 controls misbehaving flows by preventing a flow to monopolize buffer resources,Question: Why dont we use CHOKe against low-rate attacks?,Flow Filtering Scenario,Heterogeneous RTT environment: Short-RTT flows are the most vulnerable to low-rate attacks,Implications: Long-RTT flows collaborate in the attack Less-than bottleneck rates needed to attack short-RTT flows,CHOKe and Flow Filtering,DoS flow utilizes only 3.3% of the bottleneck capacity CHOKe fails to throttle the low-rate attack against short-RTT flows,Request Flooding DoS Attack,Pushback RFC3168 Network nodes coordinate efforts to detect a malicious (flooding) node But in the request flooding scenario, the flooding machine is not malicious moreover, it is a victim,Bandwidth Stealing,Fact Network-based schemes lack the exact knowledge of end-point parameters Example RED-PD doesnt know about RTT: TB=f(Ploss, RTT=40ms) Implication Clients with RTT 40 ms can exploit this vulnerability Algorithmic misbehavior We generalized the TCP formula T=f(Ploss, RTT, a, b) Our algorithm tells how to re-tune AIMD parameters to steal bandwidth, yet elude detection,Summary of Limitations,Low rate attacks RED-PD: issue of time-scales CHOKe: flow filtering Misbehaving receivers Pushback: No distinction of causes and effects RED-PD: No knowledge of endpoint parameters Can we do better from the endpoints? End-point parameter randomization End-point TCP-fairness verification,End-point minRTO Randomization,Observe: Low-rate attacks exploit protocol determinism minRTO=1sec Question: Can minRTO randomization alleviate the problem? Approach: Randomize the minRTO parameter Insight: The most vulnerable time-scale is T=b Wait for flows to recover and then hit them again,End-point minRTO Randomization,TCP throughput formula on T=b time-scale of the low-rate attack,End-point minRTO Randomization,TCP throughput formula on T=b time-scale of the Shrew attack Randomizing the minRTO parameter shifts and smoothes TCPs null time-scales Fundamental tradeoff between TCP performance and vulnerability to low-rate DoS attacks remains,An End-Point Solution,Sender-side verification: Ping Agent: Measures RTT without a cooperation from the receiver TFRC Agent: Computes “TCP-fair” rate Control Agent: Enforces the sending rate,Evaluation,Scenarios: with behaving receiver (to study false positives) with misbehaving receivers (to study detection),End-point scheme is able to detect even very moderate misbehaviors,Slight inaccuracy for higher packet loss ratios (due to TFRC conservatism),Summary,Denial of Service attacks represent a fundamental threat to todays Internet Network-based solutions are necessary, yet are quite often very limited End-point protocols optimized for performance, not security DoS-resilient protocol design Parameter randomization Ability to control the other end-point,Conclusions,Improve network performance via End-point QoS differentiation DoS-resilient protocol design QoS differentiation Developed, implemented, and tested