1. 1 University of WashingtonComputing & Communications The Indeterminate Internet Denial isn’t just a river… Terry Gray University of Washington Reconnections Workshop 25 October 2005

2. 2 University of WashingtonComputing & Communications Part I “It Takes A Worried Man (to sing a troubled song)” - Kingston Trio My job: AVP, IT Angst

3. 3 University of WashingtonComputing & Communications Premises The open Internet died in 2003 at the hands of slammer and blaster. Networking is now about selective isolation rather than pervasive connectivity. The Internet has become an impossible-to- diagnose monster. The trend toward Indeterminate Internetworking can and should be reversed.

4. 4 University of WashingtonComputing & Communications Life is Good Connectivity almost anywhere Web mostly works Email usually works We’ve got Google What’s some spam & ID theft among friends? So what’s the problem??

5. 5 University of WashingtonComputing & Communications Welcome to The New Internet "Gmail is temporarily unavailable. Cross your fingers and try again in a few minutes. We're sorry for the inconvenience.” “INBOX closed due to access error” 404.. “No, wait… it works now” Interminable hourglass/clock icon Glitchy A/V VOIP call dropped Slow FTP SMB transfer “just stops”

6. 6 University of WashingtonComputing & Communications Issues Internet dependence has increased; so has tolerance for mediocrity Some problems disappear in seconds “by themselves” some go on for years… Is this really what we meant by “Best Effort” net? What is the trend for MTBF? What about MTBG? ( G == Glitch ) What is the trend for MTTR? What are the Success Metrics for the new Internet?

7. 7 University of WashingtonComputing & Communications A Few of my Favorite Things Apps that don’t say what they’re waiting for OS’s that set max-retry count to 5 Routers that say little about dropped packets Middle-boxes that make the net look broken Redundancy that means “hidden degradation” Local caching that means “unpredictable result”

8. 8 University of WashingtonComputing & Communications This is Heisen-Stein Networking (both uncertain and relativistic*) How many PEPs in a path make the system non-deterministic? Every protocol needs a timeout, but ours fight Success factors? Time, place, policy, app… Contradiction: –Increasing dependence on Internet: expecting HA –Increasing tolerance for short-lived anomalies * except for demos, where E = kM/T**2

9. 9 University of WashingtonComputing & Communications The Curse of Success Why has the Internet become so complex? Why is MS Word so bloated? Popularity+diversity breeds complexity! Negative economy of scale as “OSFA” fails Custom needs undermine generality… Internet/marketplace democracy: –can the needs of the few be met? –at what price?

10. 10 University of WashingtonComputing & Communications First Principles Packet rather than circuit switching Complexity at the edge; Simplicity/transparency in the core The “hour glass” model –common bearer service Pervasive and symmetric connectivity Principle of least surprise

11. 11 University of WashingtonComputing & Communications Times Change Circuit switching is making a comeback The core is no longer simple nor transparent Hour glass? L2=Ethernet; L7=web and Skype Not everyone wants full connectivity Surprise? the Internet kinda/mostly works --for some value of the Internet!

12. 12 University of WashingtonComputing & Communications Needs Change More security; selective connectivity More dependability, resilience; diagnosability More scalability (phones, lights, smart dust) More performance (moving petabytes; HD conf) More autonomy (personal, group, enterprise) More “anywhere” connectivity More regulatory compliance Less $$ (especially less OpEx)

13. 13 University of WashingtonComputing & Communications Consequences Personal lambdas (Important to know WHY!) "Firewall Friendly" software; The one-port Internet More security & compliance officers; more paranoia Changing threat environment; edge-centric attacks More encryption; less useful perimeter defense More performance hacks: multicast, spoofing Architecture, and policy diversity

14. 14 University of WashingtonComputing & Communications The Seeds of our Destruction Putting the question-mark into Network Ops Traffic-Disruption Appliances (FWs, Shapers) Autonomy-Preserving Appliances (NAT) Layer-Violating Appliances (“AON”, F5, etc) These are symptoms, not root causes!

15. 15 University of WashingtonComputing & Communications That River in Egypt… (Denial) Vendors thinking: –their diagnostic tools are adequate –more complexity in the core is a Good Thing –we’ve gotten over that auto-negotiation botch IETF: wishing TDAs would just go away ARIN: guaranteeing they won’t

16. 16 University of WashingtonComputing & Communications Standards Vary The web and nothing but the web Microsoft: 18 seconds and you’re dead! Keep-alive madness NAT state timeout madness Firewall rule madness Local policy meets simplicity; simplicity loses

17. 17 University of WashingtonComputing & Communications Paradigm Lost Gone: “Network Utility Model” –Now we have config mgt for switch ports! Look at voice/data “add/move/change” costs over time… –Voice: roll truck -> SW defined net –Data: roll truck -> Utility -> SW defined net “utility” = “one service fits all” –but YMMV

18. 18 University of WashingtonComputing & Communications The Half-Life of Perimeter Defense Encryption trumps deep inspection –The bad guys will use it even if you don’t VPNs are good attack gateways –And they are hard to diagnose Deep inspection is not always transparent –IPS vs. hi-bandwidth multicast, or slammer Policy vs. technology –E.g encrypted Skype traffic in dorms (63%!) Trusted network = oxymoron –“Only the Paranoid Survive” -Andy Grove

19. 19 University of WashingtonComputing & Communications Where’s the Outrage? Do I worry more than Corp CIOs? Is R&E the harbinger of coming chaos? –Diversity of applications/svcs –Diversity of bandwidth –Diversity of devices (type & age) –Diversity of operating systems (type & age) –aggressively decentralized culture –BUT: we don’t have Sarb-Ox… yet SO: am I over-reacting? Just get over it?

20. 20 University of WashingtonComputing & Communications Review Original design principles “no longer operative” Autonomy and selective connectivity: key Users want predictable security, perf, cost, MTTR System is increasingly complex and fragile Impact on most: more glitches Impact on some: inability to work; poor MTTR Root causes are not going away Researchers’ response: personal lambdas Corporate response: nada

21. 21 University of WashingtonComputing & Communications End of Part I “It Takes A Worried Man (to sing a troubled song)” Any questions?

22. 22 University of WashingtonComputing & Communications Part II The Way Forward “If you don’t know where you’re going, any road will take you there.”

23. 23 University of WashingtonComputing & Communications Framing the Problem Stake-holders –Users, operators, administrators, vendors Standard goals –Security, reliability, cost, flexibility/function Next-Gen requirements –No silent failures (esp. if policy-induced) –Selective connectivity/isolation –Better MTBF, MTBG, MTTR –Scale to zillions of devices

24. 24 University of WashingtonComputing & Communications Federation/Isolation/Boundary Issues User view: –Set of desired collaborators (symmetric connectivity) –Set of public resources (no inbound connections) Policy-maker view: –AUP boundaries –Cost demarcs –Traffic policy enforcement points/perimeters Operator view: –Control boundary (e.g. configs, addresses) –Monitoring boundary

25. 25 University of WashingtonComputing & Communications Next-Gen Design Principles Can’t do Architecture w/o understanding Ops Diagnosability first (e.g. paranoid telemetry) Rediscover Least Surprise e.g. Policy Discovery Protocol Federations: don’t fight local autonomy Scaling usually implies sharing Sharing usually implies insecurity Trust: selective isolation for fun & profit

26. 26 University of WashingtonComputing & Communications Trust Fabrics and Virtual Networks L1 = organizational topologies via personal lambdas L2 = organizational topologies via VLANs L2.5 = organizational topologies via MPLS L3 = organizational topologies via IPSEC Ln = organizational topologies via overlay nets

27. 27 University of WashingtonComputing & Communications Key Questions Is E2E transparency dead, or just in the ICU? Will E2E encryption save it? How many network service classes are needed? Will hosts or Enet port config define service class? How many “edges” in the next Internet? How many “layers” in the next Internet? How many “ports” in the next Internet? Will organizational topologies displace geographic? Will the future be in federated ASs? Will DEN rise from the ashes? Is NAC good, bad, or indifferent?

28. 28 University of WashingtonComputing & Communications Best Buz-Phrase of the Meeting Trust-mediated Directory-enabled Active Networking