the next generation internet unsafe at any speed n.
Skip this Video
Loading SlideShow in 5 Seconds..
The Next Generation Internet: Unsafe at any Speed? PowerPoint Presentation
Download Presentation
The Next Generation Internet: Unsafe at any Speed?

The Next Generation Internet: Unsafe at any Speed?

171 Views Download Presentation
Download Presentation

The Next Generation Internet: Unsafe at any Speed?

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. The Next Generation Internet: Unsafe at any Speed? Ken Birman Dept. of Computer Science Cornell University

  2. Convergent Trends • Existing Internet exhibiting brownouts, security and quality-of-service problems • Talk of a “next generation Internet” offering 10 to 100-fold performance improvements • A new generation of networked applications includes large numbers of “critical” ones

  3. Typical Critical Applications • Medical monitoring and clinical databases. Community health information networks. Remote home care and Remote telesurgery • Integrated modular avionics systems. Air traffic control. Free flight, 4-D navigation

  4. Medical Networks • Contacted a number of technical and business people in this field (HP Careview, EMTEK, Hospital for Sick Children) • Asked: • What are the trends? • How are networks changing healthcare? • How are these systems made secure & reliable? • Got any good stories for me?

  5. An ICU Computer System Doctor’soffice Bedside LaboratoriesPharmacy Clinical data serverDigital library and online PDR

  6. … a field in transition • During 1980’s, hospitals used largely dedicated systems • Client-server architectures now becoming dominant, but trend is a recent one • Systems ran in physical isolation and had limited, mission-specific functionality

  7. Important distinction • Medical monitoring equipment, computer controlled “devices” • These “practice medicine” • FDA regulated, like a drug • Software subjected to extreme verification methods, safety certification is costly and hard • Extends to the IEEE “medical information bus” for connecting bedside devices

  8. Important distinction • Medical monitoring equipment, computer controlled “devices” • Clinical data systems • By definition, not considered safety critical • Maintain the legally binding “patient record” • Think of a database system. Human checks all entries, even data obtained directly from devices or lab reports.

  9. Traditional Approach • Each runs as a separate network • Developed completely independently • No interconnection of any kind

  10. Networking technology? • Monitoring network is increasingly a dedicated “real-time” LAN, this permits configuration flexibility, remote telemetry, even adjustment of monitoring devices • Clinical database system increasingly connected to laboratories, community health information networks (CHIN’s), physician’s office, insurance and HMO’s

  11. Platform choices? • Overwhelming trend is to introduce standard PC’s and workstations, standard Internet technologies • Forced migration from dedicated platforms to shared, standard network platforms • Web access now common from PC’s that run clinical database software

  12. … bluring the distinction • Increasingly, see monitoring network cross-connected to the clinical data network • Some physical isolation: not yet common to see an IV perfusion drip controllable over an internet within a hospital • “Perimeter” security using passwords, firewalls. But medical security needs are unusual; mismatched to standard solutions.

  13. Creep of “critical” role • Technically, clinical data system is non-critical • But increasingly, the system actually is critical: doctors and nurses depend upon the • Accuracy and timeliness of reporting • Correct data for lab results, vitals, medications • FDA is simply late to catch up with trends • Moreover, already seeing Windows 95 and MS Access as basis for such systems

  14. Consumer / society “pull” • Intensive and growing cost pressures • Desire for freedom from medical system, home care • Consolidation of hospitals • HMO’s want to control care plan • … create trend towards remote telemedicine, even robot telesurgery, CHIN’s

  15. Vision: A Virtual Private Network Application shares the network with untrusted agents but is isolated from them.

  16. Reality? • Current VPN support approximates this, but configuration potentially awkward, slow • Many CHIN’s won’t use VPN’s • By running over the Internet, CHIN’s are exposed to bandwidth fluctuations and denial of service from many causes

  17. Good stories? • Many cases of security or privacy violations (EMTEK has a good one). • HP told me that some hackers accidently disrupted a cardiac monitor in the Boston area a few years ago (trying to track this down) • Nutty nursing aide in Britain changed orders, discharged patients, scheduled tests… • HP Careview, starved for bandwidth, flickers on and offline in some critical care units...

  18. Broad picture? • Application trends outstripping technology • Decision making is by societal consensus, cost pressures, reflects HMO needs. • Hospital executives insisting on “standards” • Hospital network of future: PC’s, off-the-shelf Internet software, standard Web stuff. Critical or not, like it or not, it’s happening!

  19. What about aviation? • Much use of computer technologies • Flight management system (controls airplane) • Flaps, engine controls (critical subsystems) • Navigational systems • TCAS (collision avoidance system) • Air traffic control system on ground • In-flight, approach, international “hand-off” • Airport ground system (runways, gates, etc)

  20. What about aviation? • Much use of computer technologies • Flight management system (controls airplane) • Flaps, engine controls (critical subsystems) • Navigational systems • TCAS (collision avoidance system) • Air traffic control system on ground • In-flight, approach, international “hand-off” • Airport ground system (runways, gates, etc)

  21. ATC system components Onboard Radar Controllers X.500 Directory Air Traffic Database(flight plans, etc)

  22. … similar turmoil • On-board systems moving to COTS, integrated modular avionics • Boeing 777 SafeBus a success story • Unlikely it could be replicated with standard O/S and standard ATM or LAN hardware • Emergence of “4-D navigation” (free flight) systems: ground network penetrates level-A critical cockpit components.

  23. Free flight Transponder and GPS On-board conflict alert and resolution system Ground system

  24. Future avionics systems • Ground systems rely increasingly on automation, have form of a highly available, highly critical network. Built using standard PC’s, software tools • Ground network becomes critical to flight safety • On-board avionics are basically a dedicated real-time LAN built with standard PC’s but perhaps non-standard O/S. One platform, many apps. • Safety validation of components replaces current validation of system. Think “plug ‘n play”

  25. The list goes on • Disaster warning and response coordination • Power management (grid control) • Banking, stock markets, trading systems • Computer-controlled vehicles • Military intelligence, command and control • Critical business applications

  26. Commercial Off The Shelf • Build using “COTS” • Standard components • Buy off the shelf, then harden them • Intended to be cheaper, easier to maintain • As a practical matter, there is nothing else on the shelf! • Roll-your-own solutions abandon powerful tools that make modern computing great!

  27. Technology Mountain COTS

  28. Reliable Technology Mountain COTS

  29. Next Generation Internet • Current Internet looks frail • Only government investment can address security, reliability, scalability and performance problems of the Internet • Expectation is that we’ll build it quickly, hence that we “basically” know how today

  30. Next Generation Internet • Concrete details? • Seeks 10 to 100-fold performance improvement • Originally expected to provide IP-v6 interface • Originally expected to implement • Long IP addresses • IPSec, DNSec • Quality of Service options “over” some form of Diffsrv (or RSVP) mechanism

  31. Reality check • Both IPv6 and RSVP now uncertain due to resistance from mainstream IPv4 crowd • RSVP resource use on routers grows as O(n2) • IPv6 would outmode a huge existing investment • How likely is it that the NGI will solve the practical problems identified earlier? • How does one build a “secure, reliable, scalable, high performance” network application, anyhow? • Do we in fact know how to do this?

  32. Glimpse of the IPv4 crowd • They gave us TCP/IP, core internet services, stuff on which we run email, web • They elevate the end-to-end argument to a religion (basically: “packets, not circuits”) • Little experience with critical applications

  33. What about QoS? • Best scheme: Diffsrv • Uses an edge-classification of packets; routers look at just a byte or two • But routers distort flow dynamics • You send 50 packets per second… • … but within the network, a router might see a burst of 100, then a second of silence • Consequence is that Diffsrv will be at best stochastic (and it also can’t handle routing changes)

  34. … a troubling implication • It seems unlikely that the NGI will easily support isolation of critical subsystems with the range of properties required • More likely: a tool for building virtual circuits (one-one connections) that run at very high speeds • Missing “connection” is the step from the network to the robust application

  35. What do we need? • Isolation of functions • Critical functionality compartmentalized • Components only interact through well-defined interfaces with well-defined semantics • Developer “proves” that implementation respects interface definition and semantics • On the other hand, adequate performance is fundamental to providing robustness

  36. Evidence for these claims? • This is how modern avionics modules are built (wing flap and engine control, flight management system, inertial navigation) • Process is extremely costly and works only for very small pieces of software • SafeBus on Boeing 777 allows such software to share platform by creating very strong firewalls between components

  37. Agenda emerges • Find ways to divide and conquer • Transform big nasty system into smaller independent modules • Run them in an environment that has strong properties, which the modules exploit • Resulting system has strong properties too • Can we apply this to familiar distributed computing problems?

  38. Philosophy • Imagine a network as an abstract data type • An “Overlay Network” or ON • We can instantiate it multiple times, “condition” each copy with desired quality properties: • A Virtual Overlay Network or VON • How to introduce properties? • Mixture of resource reservation at routers, on a per-ON basis, and management actions at edges

  39. A VON • Looks like a dedicated Internet, although hosted on a shared infrastructure • Supports guarantees of properties such as • Bandwidth • Noise level • Security and freedom from denial of service • Treated as an aggregate,not a set of pt-to-pt connections!

  40. Making Vision a Reality 1) NGI needs to give us the ON mechanism 2) We need to implement VONs using fairly standard protocols over the base ONs 3) Must be able to produce specialized solutions for reliability/security needs 4) Solutions amenable to selective use of formal tools

  41. NGI hooks? • Diffsrv and RSVP won’t do it • Creates an O(n2) resource reservation problem • Problem is that both schemes are fundamentally connection oriented, and VON concept is fundamentally multipoint in nature • Hence these point-to-point QoS mechanisms are not suitable for supporting VONs • Any other options?

  42. Switches supporting “flows” already exist • MCI, Sprint, AT&T already sell each other dedicated bandwidth with isolation • This is on a scale of perhaps 10’s of flows and hence classification is easy • VONs might mean that a switch would see thousands, but such scaling seems well within technical feasibility

  43. Router understands flows Looks likethis

  44. Router understands flows Flow 1 Flow 2 Flow 3 Everything else Looks likethis Looks likethis Looks likethis Acts likethis

  45. Things to notice • A flow in this sense aggregates all the traffic for one ON – the identifier is for the ON not the endpoints • Classification task is thus much smaller and resources needed to support this are linear in number of ONs that pass through the switch, not the number of potential connections • Each ON is like a dedicated network

  46. An ON has • A bandwidth guarantee (router sets resources aside on its behalf) • Perhaps latency guarantees • Can offer isolation between flows • But not much else

  47. NGI part of the picture • NGI needs to give us “raw” ON’s but also: • Robust routing infrastructure • Naming • Ability to build an ON tolerant of “one link or router failure” • Many building blocks are already in place • But the core Internet community is balking on all forms of QoS: isolation or other guarantees seen as inconsistent with end-to-end philosophy

  48. But suppose we get our wish • Next President declares “moral equivalent of war” after continuing Internet siege shuts down his web site during election: • “Let there be Overlay Networks!” • Then what?

  49. Our new goal? • Create VONs by adding properties to Ons • User sees VON as a set of end-points with minimum guarantees, like isolation, between them • We need a way to strengthen these properties • E.g. manage security keys, manage RSVP parameters, routing, network name space • We may also need ways to reliably communicate (1-1, 1-n patterns)

  50. VONs as abstract data types