View
218
Download
1
Embed Size (px)
Citation preview
1
University of Washington Computing & Communications
The Indeterminate InternetDenial isn’t just a river…
Terry Gray
University of Washington
Reconnections Workshop
25 October 2005
2
University of Washington Computing & Communications
Part I
“It Takes A Worried Man (to sing a troubled song)”
- Kingston Trio
My job: AVP, IT Angst
3
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & Communications
End of Part I
“It Takes A Worried Man (to sing a troubled song)”
Any questions?
22
University of Washington Computing & Communications
Part II
The Way Forward
“If you don’t know where you’re going, any road will take you there.”
23
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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
University of Washington Computing & 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?