Alan H. Karp HP Labs

1. Lessons from If you’re not on the CUSP, you’re missing the point! Alan H. Karp HP Labs

2. A Brief History of E-speak • Research started as Client Utility in October 1995 • First prototype and demo July 1996 • Open Services Operation started November 1998 • First public disclosure and customer May 1999 • Official release of Beta version December 1999 • Re-architected version for B2B ready April 2000 • E-speak Operation Shut down June 2001 • Fifth customer live May 2002 Lessons from E-speak

3. What was E-speak? An open services platform for the • creation, • composition, • mediation, • virtualization, • management, and • accessing of Internet-based services. Sounds a lot like Web Services Lessons from E-speak

4. Requests E-speak Core Kernel Kernel Kernel Applications OperatingSystem PhysicalResources e.g., CPU time slice, disk E-speak in Perspective Services Lessons from E-speak

5. Lessons Lessons from E-speak

6. The Good • Platitudes • Don’t put policy into architecture • Think about security early and often • Avoid special cases • Less obvious rules • People who never interact shouldn’t have to agree • Think about naming early and often • Plan for delegation and revocation • Don’t authenticate when you want to authorize • Support voluntary oblivious compliance • Design for consistency under merge Lessons from E-speak

7. Consistency under Merge • People will make private versions of a global system • They will merge with each other or the global version • Problems if anyone has to make changes • Notable failures • Merging DCE cells • UDDI private repositories • E-speak was consistent under merge Lessons from E-speak

8. Voluntary Oblivious Compliance • Can’t prevent misuse of a valid authority • DPWYCP • Help those who want to follow the rules • Rules are complex • Rules change all the time • Don’t make everyone know the rules to be good • Let infrastructure make sure rules are enforced • E-speak supported VOC Lessons from E-speak

9. Security • First prototype • Knew that authentication would be important • Didn’t know how it would be done • Built an authenticate module that returned an ID • All calls in place when authentication added Lessons from E-speak

10. The Bad • We listened to the experts when we knew better • We sacrificed an important architectural principle • We invented instead of optimizing • We didn’t control feature explosion Lessons from E-speak

11. Unnecessary Invention • First prototype used conventional c-lists • Metadata rich • Switched to split capabilities • Some advantages • Change security models by configuration • Add/remove user relatively easily • Some disadvantages • Unfamiliar • Confused deputy attack easier Lessons from E-speak

12. The Ugly • We sometimes let implementation drive architecture • We made the easy way the insecure way • We didn’t give adequate attention to end-to-end issues • We didn’t pay enough attention to performance Lessons from E-speak

13. Wrong Thing Easy • Wanted to have revocable CUkeys • Introduced key rings • Give you name for key ring but no name for CUkeys • You can’t remove or copy CUKeys • Revoke by removing key ring repository entry • People put all their keys on one key ring • Subjected themselves to confused deputy attack • Lost advantages of fine-grained access control • Later realized we could clone a key Lessons from E-speak

14. The Uglier • We couldn’t explain the system • We required a new mental model • We were too proud of our technology • We ignored the development environment • We didn’t build an open source community • We were resource starved • We were too far from HP’s mainline products Lessons from E-speak

15. New Mental Model • Team from NTT developing a travel portal demo • Got stuck for a month dealing with changes • Designing a database for reservation • Suggested creating a “trip” service • Changes easy to handle • Send message to “trip” resource when flight changes • “Trip” informs hotel and rental car • No database needed to manage changes • Finished in two days Lessons from E-speak

16. Wrap-up • Proved our scalability and reliability claims • 10,000,000 resources • 4,000 seats • 60 machines • Service never off line in 18 months • Service never violated security rules • Five happy customers weren’t enough • Parts of the technology survive in other systems • E-speak vocabularies may take on a new life • Web services scalability problems revived interest Lessons from E-speak

17. Thank You (I have another 18 slides with the details.) Lessons from E-speak

18. E-speak Beta 2.2 Overview Lessons from E-speak

19. System Structure • Federation of Logical Machines • Logical Machine • Active entity - Core • Passive component - Repository • Mailbox metaphor for requests to Core Lessons from E-speak

20. Key Abstractions • Everything is a resource • Naming • Only way to reference a resource • All names are private • Security • Separate control of names and access rights • Description • Customizable vocabularies (XML schema) • Management • Every access mediated Lessons from E-speak

21. Evaluation • The Good • No central point of failure • Can build synchronous messaging on asynchronous • Many benefits of uniform resource model • Rich description, powerful discovery • Fine-grained access control • The Bad • Names have no meaning out of band • Separating designation from authorization • The Ugly Lessons from E-speak

22. Fundamentals • Every resource’s metadata registered with Core • Tasks access resources by name • Core associates name with resource metadata Lessons from E-speak

23. Registry Entry Repository Handle Owner – Protection domain Handler – Inbox Contract – Application API Security Fields Repository entry permissions – (L,P)* Resource permissions – (L,P)* Visibility – Allow (L)*/Deny (L)* Discovery Fields (Vocabulary/description)* Resource specific data Public Private Lessons from E-speak

24. Use Model • Each task has an outbox connected to the Core • Outgoing message has envelope and payload • Each task has zero or more inboxes • Incoming message has envelope and payload • Core-related data in envelope • Application data in payload Lessons from E-speak

25. Outbox Message Format Header Version msgID replyID Key rings Primary resource Callback resource Exception resource Secondary resources Payload Application API Lessons from E-speak

26. Monitor Naming Permission Router Single Machine View Event Distributor Client Resource Handler Core Protection Domain Protection Domain Repository Host OS Lessons from E-speak

27. Evaluation • The Good • Mediation • Can’t hurt what you can’t name • Trusted path between clients • Separation of core-related and application data • The Bad • Extra context switches • Lots of metadata • The Ugly • Poor handling of names in Inbox • Key rings • One key ring per message Lessons from E-speak

28. Protection Domain Default name frame Mandatory key ring Quotas Lessons from E-speak

29. Naming • Private name space per client • Name space divided into frames • Frame contains bindings of strings to a • repository handle • list of repository handles • lookup request • Bindings can be to other frames • /foo/bar/qux Lessons from E-speak

30. Evaluation • The Good • Use of name frames very powerful • Rich bindings hid some complexity from application • The Bad • Management of name spaces unfamiliar • The Ugly Lessons from E-speak

31. Connecting Logical Machines • Machines can publish a “connection object” • Means to identify machine • Means to contact it – IP address, IR channel, phone number • Present to Connection Manager • Authenticates other machine • Establishes Protection Domain • Starts proxy • Proxy • Makes connection • Exports resource descriptions • Imports resources listing itself as the handler Lessons from E-speak

32. Using a Remote Resource Lessons from E-speak

33. Evaluation • The Good • Authentication/policy enforcement in trusted component • Proxy prevents many attacks, including some DoS • Only proxy knows about the wire • The Bad • Access is path dependent (but can introduce) • The Ugly • Unification problem • Identification problem Lessons from E-speak

34. Changes for E-speak Product Lessons from E-speak