1. Architecture from the top down David D. Clark MIT CSAIL April, 2009

2. What does that mean? Reasoning from requirements to mechanism. Reasoning from the application down to the supporting mechanisms. Applications are the driver, after all.

3. In the early days… We did not give much guidance to application designers. Was not a reliable byte stream and the DNS enough? Did not seem to be part of the architecture No constraints on what the designer did. Is not architecture a form of constraint? Our view of application design was simple. Two party interaction. (Except email)

4. As things evolved Email came down with spam and viruses. Reminder of adverse interests. The Web came down with caches, proxies and Akamai. Reminder of performance concerns. Structures generally got more complex. Many of the issues that plague users arise at the application layer. Security issues. Inexplicable failure modes.

5. Today and looking forward Applications are often very complex. Composed of lots of servers and services. Web 2.0, mashups, cloud computing, huge server farms and the likes. Their structure reflects the economic (and other) incentives of the designers. We need to study the architecture of control. Application designer as power broker?

6. Issues to consider Security Availability and resilience Better management Economic viability Longevity Meet societys needs Support for tomorrows computing Exploit tomorrows networking Support tomorrows applications Fit for purpose (it works…)

7. Thesis I: Applications will need to tailor their behavior to different operating contexts. Future applications will offer a range of operating modes or communication patterns. By shifting from one pattern to another depending on context and requirements, participants will be able to adapt application behavior to their needs. Control over the selected pattern will be a point of control and tussle. The job of the network is to facilitate and enforce the patterns.

8. Security--general framework General systems like PCs will always have residual vulnerabilities, and will be targets of opportunity for application-level infiltration. We can build smaller, fixed function devices that are much more secure. Applications can achieve higher overall security be moving security-critical functions to these helper nodes. This behavior will require the involvement of applications.

9. Security--specific examples Confidentiality and integrity during communication. Shall we encrypt? Information security Is transport responsible for information integrity? How does an application maintain info integrity? A small piece of a much bigger problem: see Clark-Wilson paper. How do we track provenance? Infiltration Block unused apps (firewalls) Validate identity (if not a public server) Inspect contents (viruses, malware, etc.) Exfiltration Validate identity and authorization Availability (see next slide)

10. Availability (theory of) Replication of servers/services. Detection of failures Perhaps obvious if fail-stop. Less obvious if more subtle. May occur at end-node or along the invocation chain. Failover to different instance Who can direct or trigger failover? End-nodes? Reporting and correction of failure We dont often support this capability. (Management) (see next slide) (Security: firewall = ¬ availability, ¬diagnosis )

11. Management Performance issues Pre-positioning content near client. Selecting efficient instance of a service Detecting and restoring failed services Giving users clear information about application status. Hiding internal structural complexity. Making distributed apps easy to deploy, configure and maintain.

12. Economics Structure of applications reflects motivations of designers. Central component to maintain control IM, games, eBay, facebook, Global footprint to dominate market Akamai Changing model of value Computation is commodity, data is key. Who controls different sorts of information? Mashups mash information, not computation. Maps, social nets, reputation, identity, (Worth asking who has advantage for different data.) Is there a network-network interface for apps?

13. Social/regulatory considerations Avoid baking in rigidity in the face of variation in social and cultural norms. Allow for cultural tussle at the app level. Identify well-known tussles (e.g. spam-like behavior) and design for preferred outcomes. Deal with regulatory requirements. Logging (IM for stock traders), wiretap What is revealed and protected. Anti-logging (prevent legal discovery) Privacy issues.

14. Network service model Interactive (e.g. all the parts are there at the same time). Staged (like email, DTN, etc.) In-net conversion Application-specific reformatting, etc. Support a wide range of end-node devices with different capabilities.

15. Theories of decomposition Data-centric What I called data enclosures. Isolation of high-value information. Regions with distinct needs for assumptions about trust. Efficient positioning of interactive components. Economic decomposition. Isolation of components that require quick upgrade/enhancement. Security defenses. Isolation of components that capture cultural norms. (very abstract statement, I know…)

16. Observations The end-node is only a small part of the picture. Often just the web browser. And it is insecure. Ask: who controls what is happening? Who has choice, who has power. Power is expressed through: Selection of application design alternatives Closed protocols Data enclosure Control over the patterns of communication. Who controls this? Asymmetric tussle.

17. Power, control and choice Application designers can design in the preferred range of patterns. Initiators of operations (e.g. the invoking end- points) can attempt to pick among these alternatives. The potential for choice Network operators can control which patterns are allowed. In the end, topology trumps, but in the end, a blunt instrument. The encryption escalation.

18. Three conclusions These patterns transcend specific application objectives. They apply to broad classes of applications. Most application designers will benefit from guidance as to how to think about and implement them. What I have been calling design patterns. In many cases, the factor that will determine which pattern is preferred is assessment of which actors are most trustworthy. So management of trust, and by extension identity, must be native facilities. Trust assumptions will span applications.

19. Design options Encrypt vs. clear Clear allows inspection, allows disclosure Validate identity/authority or not. Adds overhead, complexity Use of indirection nodes Include or strip identity/authorization info. Control who can see such info. Information integrity using trusted transformations. Encourage/regulate dissemination. Separate the narratives. Logging of actions or not. Client choice over service. Instance (facilitates DDoS) and provider-level. Diagnose-ability or not of failures.

20. Thesis II: A major determinant of which pattern or mode is used will be the trust among the communicating parties and the other parties relevant to the situation (e.g. the ISPs, etc.) Trust requires a baseline of identity. Trust and identity will be foundational for tomorrows applications. Lots of ways to get these functions wrong.

21. Designing identity schemes There is more than one way we could approach identity. A private matter among end-nodes. E.g. encrypted or meaningless except at end points. Signal of identity that is visible in the network. Surveillance cameras in cyberspace. Facilitate both policing (perhaps) and repression. Third-party credentials vs. continuity-based familiarity. Revocable anonymity. Anonymity can only be revoked by its creators. Probably need all in different circumstances, so architecture should not constrain. These are not choices to be made by technologists alone. Need a multi-disciplinary conversation. I am very fearful of getting this wrong.

22. Questions?

23. Two quotes from the E2E paper In a system that includes communications, one usually draws a modular boundary around the communication subsystem and defines a firm interface between it and the rest of the system. The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system.

24. Why did we say this? The network was and is flakey. The end-node was a trustworthy platform on which to depend. Reliability checks can compensate for unreliable network. But today the end-node is perhaps the least trustworthy part of the system. Today the issue is both technical reliability and tussle (actors with adverse interests.) Does this eliminate the E2E argument, or motivate us to dig deeper?

25. A more general form A possible re-framing of E2E is trust-to-trust. Original: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Revised: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at points where it can be trusted to perform its job properly. Begs the question trusted by whom, and who has the power to dictate the answer.

26. A final question Do we trust the user. When we do, we get peer production of content (Wikipedia), collaborative filtering, etc. This is seen as the wave of the future. But do we trust the user to select among routes, report failures in system components, and so on? The distinction may have to do with aggregate behavior. How can we design applications to harness this for all the issues I have mentioned here?

27. Outline First, a review of lots of reasons why applications will not always work the same way--why patterns of communication will vary. Briefly, a catalog of theories of decomposition. Comments on power and control Evidence for the centrality of trust Some conclusions, and an aside on E2E.