Here is a style of security for DSR. It suggests a form of active networks and it is a form of capability security.
We present some ideas that are a bit orthogonal to the DSR ideas. They complement DSR well, however, and may be strategic to DSR. They support the idea of a network application of which the circuit is only a special case. A network application consists of special agents at each of several sites communicating thru private channels. There is a bias in this design towards applications whose design assumes an early decision about how function should be distributed between sites. The nearer you get to the hardware, the more its nature emerges. These designs are to support the function that is near the hardware. Joule, by contrast, concentrates on applications of more complexity set on a more luxurious infrastructure that supports late decisions on the allocation of function to sites.

We suggest here some site architectures that support robust network applications with unreliable or even hostile code at the sites where the application agents reside. So far the agents considered have been simple and "owned" by the sites. We consider principles sufficient for open sites to allow untrusted agents to operate.

An open site must constrain actions of agents. The memory map of modern CPU's may be used to constrain machine language agents. An interpreter may limit the semantics of the language in which agent code is expressed. The agent code may be unconstrained machine language that is the output of a trusted compiler for such a language. The agent logic may be expressed in hardware designed by a trusted designer.

We shall proceed by listing the allowable actions of an agent. We leave undefined, for now, any definite execution model. An agent has only implicit access to its money. If it wants to segregate its money it can do this by keeping its own accounting records. As an agent runs it consumes its money to pay for the resources is uses as it runs. This is not the only constraint on the agent's running.

There are these reasons for limiting agent actions:

Constructs such as "* ((char *)rand()) = 0;" make it unsafe to run arbitrary C agent programs. Other popular languages are not enough better in this regard. (PS: Java addresses this problem.) This is sometimes called the safety issue for the language. None of the main line languages have achieved safety. Operating systems achieve a degree of security by running the agent program with an address map that protects other agents. System calls in these programs are typically designed with no particular security model in mind and security is usually available only against the casual opponent. Most operating systems have been designed for environments unsuitable for our requirements. Files are not required for the sorts of applications that we pursue.

While common modern languages are unsafe they do provide ideas that are fruitful for our purposes. It is intended that a variable declared in a block be inaccessible outside that block. If this intent were enforced we would have much of what we need. The language Scheme has made progress toward some of these goals.

What is an agent composed of?

An agent has some state that changes according to some definite algorithm. It has a money account. We presume some kind of computing that an agent may do that has no input or output beyond that provided by some small enumerated list of capabilities to objects. There are a just few types of objects which we enumerate here. Each object type description is immediately followed by the orders, or methods on those objects. An agent may issue any of these orders on an object by specifying its capability to that object.
Channel end:
An agent can access a channel end in some interface. The other end of the channel is usually accessed by another agent at another site probably from the same application. Access to a channel may be parameterize somehow regarding priority to send data over the channel when this competes with users of other channels thru the same interface.

Basic operations on a channel are to receive and send packets on the channel. When receiving a packet the packet's money field is added to the agent's account. The data are delivered to the agent and the money amount is disclosed to the agent. When the agent sends a packet it provides the data and declares an amount of money to be included in the packet which comes from its account.
Channel Pool:
This allocates and deallocates channels for some set of interfaces.


Returns the number of interfaces accessible hereby.

Buy a channel (for some low price) at some specified interface. Return access to this end of the channel. A side effect of buying a channel is the creation of another agent at the neighboring site that holds the other end of the channel. That agent initially obeys a protocol that causes it to obey instructions it receives over the channel. The new agent is endowed with a few standard capabilities such as rent-a-buffer, buy-a channel, capability-heap. It has an account taken from the creator.

Sell an owned channel and get a refund. A signal is delivered to the other end of the circuit to the agent at the other site.

RAM buffer:
The agent can own portions of RAM for periods of time. Rent is probably deducted from the agent's account. Basic operations on a buffer are reading and writing. Channel operations may take or deposit their data in buffers.
Buffer Pool:
Invoking this is a very low cost transaction. Charging may be statistical in order to keep the cost of measuring the cost smaller than the cost of the buffer. An agent may hold zero, one or more capabilities to buffer pools. It may hold two such capabilities which provide buffers under different terms and conditions which may address issues of market cornering.


Buy a buffer (size)

Sell a buffer

Other agents:
It is possible to send or receive data, money and capabilities to other agents at the same site.


An alternative to this idea is channels with both ends at the site. An agent might be endowed when it is born with a capability to itself.

Capability heap:
This associates capabilities with 96 bit numbers. The application designer should assume that all agents at a site have access to the same capability heap. We assume that placing a capability associated with a random 96 bit number is a safe way to pass the capability between agents at a site that have a secure way of passing the number. If circuits are insecure against passive taps one will wish to cipher these 96 bit keys before passing them. This ciphering overhead occurs only during establishment of these agents.


Add a pair to the heap for $.002

Present the number and retrieve the capability. Present the number and delete the pair and be refunded the $.002.

Cornering the market is a special case of using limited resources. The problem centers partly on the difference between short term and long term supply elasticity. The site operator could profitably arrange for more storage if the demand were anticipated. The application owner may be able to contract for storage soon enough for more real storage to be added. The other problem is the peak to average demand ratio. The total memory resources available at a given site may be cheap compared to the money available to some aberrant or malicious application. Market cornering seems to be a real phenomenon in the "real world". Our agents have less common sense and may be more vulnerable to damage caused by an opponent who corners a local market. One simple solution is for the vendor to establish some sort of two-to-the-customer policy and hope that peak demands will not occur at once. Special deals can be worked out for special requirements. An agent can be safe by acquiring memory (or other resource) early and keeping it permanently. The site operator may discriminate between applications in their ability to acquire resources by schemes described below.

When memory is available for rent or lease at a price somehow connected with cost and the memory requirements are stable then the issue of using too much memory is an issue limited to the application designer.

The Real Accumulator

We promised that the accumulator described was only an abstraction. I presume that both systems at a logical interface would actually implement an accumulator and that the real link between the two systems would be controlled for errors and lost or duplicated packets. An occasional net specie acknowledgment seems to provide a good debugging strategy. I also presume that whenever there is a net change in the accumulator of more than about $1 that the new value would be recorded in non-volatile storage. The specie acknowledgment and non-volatile record could well be synchronized. This provides a bound on discrepancies arising from crashes while minimizing the cost of accounting. Enciphering the link prevents a class of mischief by an active wire-tapper.