The Indeterminate Internet Denial isn’t just a river…

1. The Indeterminate InternetDenial isn’t just a river… Terry Gray University of Washington Reconnections Workshop 25 October 2005

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

3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. The Seeds of our DestructionPutting 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. 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. 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. 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. 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. 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. 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. End of Part I“It Takes A Worried Man (to sing a troubled song)” Any questions?

22. Part IIThe Way Forward “If you don’t know where you’re going, any road will take you there.”

23. 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. 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. 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. 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. 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. Best Buz-Phrase of the Meeting Trust-mediated Directory-enabled Active Networking