TRUST:Team for Research in Ubiquitous Secure Technologies Secure Information Management Software Tools Ken Birman (lead) Anantharam, Bajcsy, Karsai, Lee, McFadden, Samuelson, Sastry, Schmidt, Sztipanovits, Weber, Wicker NSF STC Review September 13th 2004

The Need: Better Tools TRUST Software developers depend on complex platforms, and increasingly work by extending or customizing with extra code Web Services, J2EE, CORBA Even Microsoft .NET The quality of these platforms and “tools” is a direct determinant of the quality of their applications and solutions 2 NSF STC Review September 13th 2004

Existing Platforms are Inadequate TRUST Existing Platforms are Inadequate But existing platforms Scale poorly and can “melt down” under stress Are insecure; child’s play to disrupt or intrude Are human intensive to deploy, configure Are hard to repair when disruption occurs Are costly to own and operate Example: publish-subscribe scalability issues within Yahoo, Amazon, other big data centers 3 NSF STC Review September 13th 2004

Why don’t platforms scale? TRUST Why don’t platforms scale? Prevailing client-server communications model, combined with strong reliability goals, impose O(N) delays and O(N2) performance degradation New technologies offer hope Based on peer-to-peer interaction styles Substitute probabilistic objectives for classic deterministic ones 4 NSF STC Review September 13th 2004

Map nodes to affinity groups Kelips Map nodes to affinity groups Affinity Groups: peer membership thru consistent hash 1 2 1 N - 110 N 230 202 members per affinity group 30

110 knows about other members – 230, 30… Kelips 110 knows about other members – 230, 30… Affinity group view Affinity Groups: peer membership thru consistent hash id hbeat rtt 30 234 90ms 230 322 30ms 1 2 1 N - 110 N 230 202 members per affinity group 30 Affinity group pointers

202 is a “contact” for 110 in group 2 Kelips 202 is a “contact” for 110 in group 2 Affinity group view Affinity Groups: peer membership thru consistent hash id hbeat rtt 30 234 90ms 230 322 30ms 1 2 1 N - 110 Contacts N 230 202 members per affinity group group contactNode … 2 202 30 Contact pointers

Gossip protocol replicates data cheaply “cnn.com” maps to group 2. So 110 tells group 2 to “route” inquiries about cnn.com to it. Kelips Affinity group view Affinity Groups: peer membership thru consistent hash id hbeat rtt 30 234 90ms 230 322 30ms 1 2 1 N - 110 Contacts N 230 202 members per affinity group group contactNode … 2 202 30 Resource Tuples Gossip protocol replicates data cheaply resource info … cnn.com 110

Gossip protocol replicates data cheaply Kelips Lookup is routed by a contact node in group 2, then handled by node 110 Affinity Groups: peer membership thru consistent hash 1 2 1 N - 110 N 230 202 members per affinity group 30 Gossip protocol replicates data cheaply

Astrolabe: Scalable Monitoring Infrastructure Astrolabe: Scalable Monitoring Infrastructure. Captures system state hierarchically, using P2P protocol that “assembles a puzzle” without any servers Dynamically changing query output is visible system-wide SQL query “summarizes” data Name Avg Load WL contact SMTP contact SF 2.6 123.45.61.3 123.45.61.17 ITH 1.8 127.16.77.6 127.16.77.11 Paris 3.1 14.66.71.8 14.66.71.12 Name Load Weblogic? SMTP? Word Version … swift 2.0 1 6.2 falcon 1.5 4.1 cardinal 4.5 6.0 Name Load Weblogic? SMTP? Word Version … gazelle 1.7 4.5 zebra 3.2 1 6.2 gnu .5 Ithaca San Francisco

Our team has many ideas like the two you’ve seen TRUST Our team has many ideas like the two you’ve seen We’re challenging assumptions industry accepts as dogma (like client-server structure) Building real solutions that really work And finding ways to apply them in critical infrastructure settings For example, we’ve worked with EPRI to explore applications of Astrolabe and Kelips to monitoring the electric power grid Poor monitoring contributed to ’03 blackout 11 NSF STC Review September 13th 2004