Architecture from the top down

David D. Clark

MIT CSAIL

April, 2009

What does that mean?

Reasoning from requirements to mechanism.

Reasoning from the application down to the supporting mechanisms. Applications are the driver, after all.

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)

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.

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?

Issues to consider Security Availability and resilience Better management Economic viability Longevity Meet society’s needs Support for tomorrow’s computing Exploit tomorrow’s networking Support tomorrow’s applications Fit for purpose (it works…)

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.

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.

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)

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 don’t often support this capability.

(Management) (see next slide) (Security: firewall = ¬ availability, ¬diagnosis )

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.

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?

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.

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.

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…)

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.

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.

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.

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.

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 tomorrow’s

applications. Lots of ways to get these functions wrong.

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.

Questions?

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.”

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?

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.

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?

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.