1 university of washingtoncomputing & communications the indeterminate internet denial isn’t...

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

Post on 21-Dec-2015

218 views

Category:

Documents


1 download

TRANSCRIPT

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?

28

University of Washington Computing & Communications

Best Buz-Phrase of the Meeting

Trust-mediated

Directory-enabled

Active Networking