Network Fault Localization Adrian Perrig. Overview

Transcription

1 Network Fault Localization Adrian Perrig CyLab / Carnegie Mellon University Overview Fault localiza/on overview Four fault localiza/on schemes PAAI ShortMAC TrueNet DynaFL 2 1

2 What is Fault Localization? Problem defini/on Iden/fy faulty links during packet forwarding AJacker Model Drop, modify, misroute, or inject packets at data plane Challenges Selec/ve ajack: break ping, traceroute, etc High overhead Only drop node 5 s ACKs Slander & framing Got it Got it Got it Got it Got it Source Dest 3 What is Fault Localization? Challenges (cont d) AJacks against sampling Forgery ajack: break NeZlow, Bloom Filter, etc Natural packet loss 100 pkts Source is not sampled, drop it! Got 100 Got 100 Got 100 Got 100 Got Only modify packets Dest 4 2

3 Why is Fault Localization Important? The current Internet Best effort, purely end- to- end Fault localiza/on enables: Data- plane accountability Intelligent path selec/on Linear path trial Worst case: 3 vs 2 3 trials Worst case: 2 3 Source Des/na/on 5 Design Goals Security Against drop, modify, inject, and replay packets Against mul/ple colluding nodes Efficiency Low detec/on delay Low storage, communica/on and computa/on overhead Viability Handle natural packet loss Provable bounds Upper bound of damage without being detected Lower bound of forwarding correctness if no fault detected 6 3

4 General Approach Limi$ng ajacks instead of perfect detec/on Detect every misbehavior? Costly! Error- prone! Absorb low- impact ajack: tolerance threshold Trap the ajacker into a dilemma Enable probabilis/c algorithms with provable bounds AJack more? Will get caught! Stay under the threshold? Damage is bounded! Source Dest. 7 Roadmap Path- based Secure sampling PAAI Fault Localiza5on 1- hop Probabilis/c packet marking Trusted compu/ng ShortMAC TrueNet Neighborhood monitoring DynaFL 8 4

5 Fault Localiza5on 1- hop Roadmap PAAI = Probabilis)c Acknowledgement- based Adversary Iden)fica)on Secure sampling PAAI Path- based X. Zhang, A. Jain, A. Perrig, ACM CoNext 08 Probabilis/c packet marking Trusted compu/ng ShortMAC TrueNet Neighborhood monitoring DynaFL 9 Path- based Design Space Which Packets should be acknowledged Which Nodes should send the ACKs PAAI- 1 sampling non- sampling PAAI- 2 non- sampling sampling 10 5

6 Sampling packets 1) Sample? 3) If sampled, delayed probe 5) Score PAAI- 1 Overview Source p = data $mestamp probe = tag ID(p) Drop score ) Check $mestamp: if long- delayed, discard; otherwise buffer p (assume loose $me synch) 4) On receiving probe, send Onion ACKs Dest 11 Sampling nodes Every lost packet is to be acknowledged However, only one node is selected to send the ACK Anonymity and uniformity of node selec$on Score difference PAAI- 2 Overview Suspect this link! Denial- of- detec)on: drops packets if node 1 or 2 is selected big score difference Incrimina)on: drops packets if node 5 is selected Selected Drop score Source Dest

7 1) Starts a $mer for e2e ACK 2) If fails, sends probe 4) score PAAI- 2 Protocol Node 1 is Selected! A 1 = [R 1 ] K1 A 2 = [A 3 ] K2 Constant ( O(1) ) ACK size everywhere! anonymity and uniformity of node selec5on If not sampled, re- encrypts: A 3 = [A 4 ] K If sampled, generates new ACK A 4 = [R 4 ] K4 to replace A 5 p = data $mestamp 3) Roll a die based on (Z, Ki) sampled or not probe = ID(p) Z Pr(node i is sampled) = 1/(5- i+1). E.g., 1/5, 1/4, 1/3, 1/2, 1 A d =[R d ] Kd => Pr(node i is selected) = 1/5. E.g. node 4: 4/5*3/4*2/3*1/2 = 1/5 13 PAAI Summary Results and Comparison Detec5on Delay (min) Can we do bejer? Packet sampling wastes non- sampled packets An ACK only for a single packet State PAAI KB per link PAAI MB per link Sta5s5cal FL [1] B per path Example Se\ng: A path length: 6; malicious node: node 3). PAAI- 1 sampling rate: 1/36. Source sending rate: 10 6 pkts/sec. False Posi/ve/Nega/ve rate = 3% [1] B. Barak, S. Goldberg, and D. Xiao. Protocols and lower bounds for failure localiza/on in the Internet, Proceedings of EUROCRYPT,

8 Roadmap Path- based Secure sampling PAAI Fault Localiza5on 1- hop Probabilis5c packet marking Trusted compu/ng ShortMAC X. Zhang, Z.Zhou, H.Hsiao, T. Kim, A. Perrig, P. Tague, NDSS 12 TrueNet Neighborhood monitoring DynaFL 15 ShortMAC Key Insight Fault Localiza/on Packet authen/ca/on Fault Localiza/on monitor packet count and content W/ pkt authen, content count Only counts small state, low bandwidth cost Source A B Detectable! C Detectable! 16 8

9 ShortMAC Key Ideas k- bit MAC, The ShortMAC packet marking e.g., k = 1 Limi/ng instead of perfectly detec/ng fake packets Source marks each packet with k bits (with keyed PRF) K 1 K d 1 0 K 2 1 Source K 1 K 2 K d (, 1, 0, 1) K 1 K = PRF Kd (, SN, TTL d ) = PRF K2 (, SN, TTL 2, ) Forge m? 50% chance of inconsistency. Detectable! = PRF K1 (, SN, TTL 1,, ) Dest K d 17 ShortMAC Key Ideas High- level steps Each node maintains two counters (counter only!) Secure repor/ng Threshold- based detec/on robust to natural errors sends 1000 pkts bit MAC Source modifies 500 pkt Dest. 18 9

10 Analysis and Evaluation Theore/cal bounds - - the math θ =(1 T dr ) d β N. Theore/cal bounds - - the numbers e of its malicious r links without being ( ) 2+8qTin ln 2 β = Tin δ ln 2 δ q + +ln 2 δ etection threshold dr,the4q 2 ln( N = 2d δ ) ) 2 ( ( 2 Tdr ρ ) d 1 Tdr espondingly, the fraction o Protocol ShortMAC PAAI- 1 Sta5s5cal FL Delay (pkt) State (bytes) 21 per path per link 500 per path SSFNet simula/on + Click router prototyping 19 Fault Localiza5on Path- based Roadmap Secure sampling PAAI ROOM FOR IMPROVEMENT? Probabilis/c packet marking ShortMAC X. Zhang, Z.Zhou, G.Hasker, A. Perrig, V. Gligor, ICNP 11 Trusted compu5ng TrueNet 1- hop Neighborhood monitoring DynaFL 20 10

11 Revisit Path-based Approach Theore/cally proven high overhead Per- source key storage (some/mes per- path state)! Can t globally share Fault Localiza/on results Delayed failure recovery, inconsistent rou/ng tables Node 5 is malicious! Mallory Fundamental reason: Lack of trust rela/onship Alice Bob 21 How Trusted Computing can Help Bootstrapping trust of code among nodes Remote ajesta/on and isola/on code integrity Sealed storage data secrecy How? TPM, Intel TXT, AMD SVM I expect Bob to be: So store: H( ) signed H( ) R u Bob? Alice Bob Data sealed by P; accessible only when H(P) is correct 22 11

12 Opportunities and Challenges Transi/vity of verifica/on Chain of 1- hop verifica/on gives end- to- end verifica/on per- neighbor state & key storage source AJest to the en/re network stack? Command- line input and configura/on! Large Trusted Compu/ng Base (TCB)! Code isn t modified Code is bug- free Large TCB == low security dest 23 TrueNet Goals Minimize the TCB Small piece of code can be more trusted Efficient ajesta/on without compromising performance Approach Do not ajest to seman$cs (implementa$on) of network stack AJest to behavior of network stack 1- hop monitoring module (MM): monitor behavior, in TCB 24 12

13 TrueNet Overview Setup secure channel between MMs Neighboring MMs share secret keys (per- neighbor only!) Secret keys sealed to the MMs MM Opera/ons and fault localiza/on Packets go through each MM m N SA [m, N SA ]K SA m N AB SA [m, N AB SA ]K AB SA Router S Router A Auth ACK Sam Alice 1- hop Router B Bob Network Stack Network Stack Network Stack 25 Evaluation Prototype (w/ TrustVisor): lijle computa/on overhead Storage measurement and comparison Key Storage Overhead (# keys) Other Schemes TrueNet Worst TrueNet Average ATT Sprint L3 Verio VSNL Tele (India) stra I2 Storage Overhead (bytes) 1e+09 1e+08 1e+07 1e Stat. FL Monitoring State Stat FL Key Storage Overhead TruNet Overhead ATL CHI HOU KAN LA NYC SLC SEA WAS Avg 26 13

14 Roadmap Path- based Secure sampling PAAI Fault Localiza5on 1- hop Probabilis/c packet marking Trusted compu/ng Neighborhood monitoring ShortMAC TrueNet X. Zhang, C. Lan, A. Perrig, Oakland 12 DynaFL 27 (Re)Revisit Path-based Approach TrueNet s View Lack of trust rela/onship! Solu/on: hardware support, vulnerable to hardware ajacks From another perspec/ve Operate on the granularity of paths! Per- source key, per- path state! Requires sta/c path knowledge and stability! R3 inconsistent with R4. Fault! Alice R1 R2 R3 R4 R5 Rd Bob 28 14

15 Alternative: Neighborhood-based Goals Localizing fault to a 1- hop neighborhood Path- obliviousness! Dynamic path support! Constant router state O(1) key storage N(r) p N(s) i j s r q a c b N(a) 29 High-level Steps with security holes and performance issues Record! Admin Controller Check N(s): Report (AC) whether r s + t Detec/on matches s r + s s t Traffic summary r s t s r s t s r s t 30 15

16 Challenges Defend against modifica/on ajacks Authen/ca/ng packets?! Fingerprin/ng data structure, e.g., bloom filter or sketch Fingerprin/ng without different secret keys Fingerprin/ng with different secret keys Η K r 101 Η K t Who will get it? p, q, or t? Repor/ng overhead r s t p q Dilemma! 31 Synchronous epochs DynaFL Key Ideas AC K s K f K s K f r s K f r s pkt hashes crypto hash t s pkt hashes K f t s r s t s r K f s r pkt hashes s t pkt hashes K f s t 32 16

17 DynaFL Analysis Benefits and Tradeoffs Path obliviousness! Dynamic path support Per- neighbor state O(1) key storage Localiza/on precision, path diversion! Security analysis (e.g., against collusion ajacks) Evalua/on Storage: ~ 500KB per neighbor! Repor/ng bandwidth: <0.1%! Detec/on delay: ~50000 packets! 33 Summary and Comparison Performance Protocol Storage Communication Computation Deployability PAAI per-path state 3% per-packet PRF loose time sync ShortMAC per-path state < 0.1% per-packet MAC change packet header TrueNet per-neighbor state < 0.1% per-packet MAC change packet header require TPMs DynaFL per-neighbor state < 0.1% per-packet hash loose time sync Security Protocol Detection Delay Forwarding Correctness Precision Global Sharing? PAAI pkts 95% link no ShortMAC pkts 95% link no TrueNet pkts 95% link (software attack only) yes DynaFL pkts 95% 1-hop neighborhood yes 34 17

18 Conclusion Fault localiza/on plays an important role to achieve high availability Determine and localizing malicious behavior enables avoiding malicious nodes Trusted network core can assist fault localiza/on Trusted compu/ng can greatly simplify fault localiza/on Nodes can rely on trusted core for highly available forwarding Challenge: how to extend fault localiza/on to Internet scale Applicable to local networks considered in this research but generaliza/on to Internet is an open problem 35 Thanks to ARO for generous support! Research highlights from this MURI (28 papers total in my group): Key establishment MiB: Sensys 08, U.S. Patent 8,150,037 issued 3 April 2012 SAKE: DCOSS 08 Secure group key establishment GAnGS MobiCom 2008 SPATE MobiSys 2009 (best paper award) SafeSlinger Fault localiza/on Xin Zhang s thesis 4 papers described in this paper 36 18