New Research Challenge: Design for Resiliency. Lixia Zhang UCLA Computer Science Dept

Transcription

1 New Research Challenge: Design for Resiliency Lixia Zhang UCLA Computer Science Dept November, 2003

2 The Internet Continues to Grow! More users More applications Larger traffic volume Bigger routing tables 11/12/03 2

3 Growth in size also brings Higher failure frequency, higher dynamics Q: how many routing changes per min on the Internet backbone? Q: How do different protocols interact with each other? Ever increasing system complexity Q: how many protocols implemented in a router? Q: How many new protocols being added each year? Wide range of heterogeneity r 11/12/03 3

4 Wider Ranger of heterogeneity? IP was designed to handle orders of magnitude difference in BW, delay, even losses But how about various brands of vendor products? various levels of operations expertise? various communities of users crossing all walks of the society with diverse interests and conflicting 11/12/03 4

5 Various brands of vendor products One example: UWisc offers public NTP service A month later: volume continued going up! 11/12/03 5

6 Operational challenges 20~30 years ago, this was operated by BBN network Today, this network is operated by thousands of ISPs The cause for major outages so far: Operational errors If a problem has no solution, it may not be a problem, but a fact, not to be solved, but to be coped with over time 11/12/03 6

7 But the biggest challenge Diverse interest of users malicious attacks Worms spread at higher speed Code Red took ~13 hours to spread worldwide Sapphire 10 minutes (June 03 NANOG Security BOF): as of 01 June 2003 Hacked hosts 423,262 Abused proxies 19,2608 Compromised routers 5,410 DDoS attacks through compromised hosts Attacks directly against network infrastructure 11/12/03 7

8 Wasn t the Internet designed for robustness? Yes! against physical failures Great historical papers by Paul Baran 1. On Distributed Communications Networks 2. "Some Perspectives on Networks -- Past, Present and Future Growing large >> growth in magnitude (speed, # of nodes, volume of traffic) Everything else changed too 11/12/03 8

9 "On Being the Right Size" (a short essay published by Haldane in 1928, Scaling in Biological Systems consider a giant man sixty feet high... These monsters were not only ten times as high as Christian, but ten times as wide and ten times as thick, so that their total weight was a thousand times his... Unfortunately the cross sections of their bones were only a hundred times those of Christian, so that every square inch of giant bone had to support ten times the weight borne by a square inch of human bone. 11/12/03 9

10 From Small to Big in Bio Systems A typical small animal, say a microscopic worm or rotifer, has a smooth skin through which all the oxygen it requires can soak in, a straight gut with sufficient surface to absorb its food, and a single kidney. Increase its dimensions tenfold in every direction, it will need a thousand times as much food and oxygen per day... 11/12/03 10

11 Size, Weight, Strength For every type of animal there is a most convenient size, and a large change in size inevitably carries with it a change of form. Is today s Internet "bone strong enough to carry its newly gained weight? How to make the Internet go through this change of form? 11/12/03 11

12 Up until now Functionality-Oriented Protocol Design Protocol design: minimal set of bits necessary for the intended function Explicitly enumerates all possible physical failures Node failure: fail stop Link failure: disconnect Data failures: bit error, out-of-order, loss, dup. Implicitly assumes that Every component follows the rules No faults other than physical failures listed above Experience has shown that the above list is rather incomplete 11/12/03 12

13 When unexpected faults occur? Unexpected faults system-wide failure ARPANET old distance-vector routing protocol: blackhole due to router advertising distance 0 to certain destination B ARPANET new link-state routing protocol: LSA update storm due to sequence number fault In the good old days Such unexpected faults were rare Damage was limited A 0 distance to B 11/12/03 13

14 But today Unexpected faults have become the norm rather than the exception Damage: $$$$$$$$$$$$$$$$$$$$$ 11/12/03 14

15 What should we do? DDoS attack detection and push back! Limitations of Fault-Driven Enhancements The potential space of faults/attacks is unlimited After each enhancement, infinite set of unexpected faults still remain that can disable the system. 11/12/03 15

16 Add security! What should we do? (II) 11/12/03 16

17 David Cheriton, SIGCOMM 03 keynote 11/12/03 17

18 Size change design change The Internet's large change in size calls for a fundamental change in network protocol design considerations. Designing for resiliency: How to add resiliency into the Internet to make it withstand both expected and unexpected faults? 11/12/03 18

19 Resiliency-Oriented Design Designing resiliency into network protocols Identify fundamental invariance in protocols & systems Add rigorous validity checking into each step of protocol operation Add additional information & verification procedures into protocol designs as needed to serve the verification purpose 11/12/03 19

20 Very Preliminary results as proof of evidence Started with routing protocol 2 examples Add fault-detection to RIP Add fault-detection to BGP routing announcement 11/12/03 20

21 Can RIP Detect False Updates? RIP provides very limited information Each node only knows the distance to its immediate neighbors Take this difficult example to test feasibility Is it possible to check update validity with such a constrained protocol design? Fault detection by assertions RIP protocol invariance: Shortest path routing triangle theorem holds true A 11/12/03 21 B C AB + BC AC

22 RIP-TP (RIP with Triangle checking and Probing) A R B When R receives update from A MinDist(A, I), Check-I: MinDist(R,I) MinDist(R, A) + MinDist(A, I) Check-II: MinDist(B,I) MinDist(A, B) + MinDist(A, I) Triangle theorem violation can be due to either transient following a topology change, or invalid update message. To verify: send probe message with TTL=Dist(A,I)+1 For more detail in Pei, et al, GLOBECOM 2003 I 11/12/03 22

23 How effective is RIP-TP? Recall that ARPANET outage from ~30 years ago: B A 0 distance to B RIP-TP checking could have easily detected that fault Why wasn t RIP designed with such detection built in? The design assumption: fail-stop 11/12/03 23

24 Another example: prevent traffic hijacking Internet routing: each AS announces its own prefixes to neighbor ASes Multiple Origin AS (MOAS): the same prefix announced by more than one origin AS 11/12/03 24

25 MOAS Conflicts Do Exist Max: (11357 from a single AS) Max: (9177 from a single AS) year Median number increase rate #BGP table entries increase rate % % % % % % 11/12/03 25

26 A simple detection of False Announcements /8 AS58 AS59 Example configuration: 18/8, PATH<58>, MOAS{58,59} 18/8, PATH<59>, MOAS{58,59} AS52 router bgp 59 neighbor remote-as 52 neighbor send-community neighbor route-map setcommunity out route-map setcommunity match ip address /8 set community 59:MOAS 58:MOAS additive 18/8, PATH<52>, MOAS{52, 58} 18/8, PATH<4>, MOAS{4,58,59} 11/12/03 26

27 What to Carry Away Scaling up the Internet has more profound implications beyond bigger numbers/tables It is time we start a proactive, systematic approach to Internet resiliency Design for resiliency Unknown road, lots challenges ahead How to identify the fundamental invariants in each protocol? How much overhead to pay? How to evaluate the effectiveness?... Our goal: building a resilient Internet infrastructure in a fault-pervasive environment 11/12/03 27

28 Thanks! Quesitons/comments Send to 11/12/03 28