Activating Networks

J. Smith (Penn), K. Calvert(U. Kentucky), S. Murphy (Trusted Information Systems), H. Orman (U. Arizona and DARPA) and L. Peterson (Princeton), 1999

Summary. The author present the requirements and designs for an active networks architectures including EE architecture, security architecture and a NodeOS architecture.

More detail.

The authors include web proxy caches and firewalls as "simplistic" active network technologies. State that there are two models of more ambitious ANs: one that allows on-the-fly modification of packet-switching infrastructure either in a (1) switch-like model where packets are intermingled with non-active packets or (2) a "capsule" model where all packets are regarded as programs. For ANs, we need:

environments which provide the active services (EE)
protection between the EEs (NodeOS) Note: I'm not sure that they talk about protection within the EEs.
identification of principles (security arch)

Goal of AN arch: minimize global agreement required to deploy end-to-end service while allowing maximum flexibility in the nature of those services. They must also support traditional forwarding model and scale.

NodeOS. The authors address why the NodeOS interface isn't just Posix with processes: want resource control at finer granularity than processes and Posix/Unix not well-suited for forwarding network packets (but they don't explain exactly why) -- an active node's primary responsibility.

NodeOS provides the following abstractions:

Thread pool
Memory pool
Channels
- anchored
  - in: must specify demultiplexing key, buffer
  - out: must specify bandwidth
- cut-through: must specify buffer, demultiplexing key, bw
Flow (unit of resource aggregation, can be hierarchical with root flow belonging to the NodeOS)

NodeOS supports only one additional level of demuxing; that is, the EE can specify a [offset, len, key] that the nodeOS uses to partition ee-visible packet streams onto separate channels. Cut-through channels can be created relative to an existing anchored channel, inherits that channels rich demux key.

One expected model: data packets through cut-through channel; control packets on anchored channel.

Security Architecture. Network's security not self-enforced (as is the case with NodeOS memory and cycles). "The protection of the robustness of the network as a whole must be built into the design of the individual nodes and EEs." Example: TTLs. Safety at the EE level can be provided via type-safety or SFI.

Authorization is a fundamental security service that must be provided. Validating the source of active code is key. The challenge is to provide a mechanism for authorization that scales with active nets -- anything presently used for enterprise nets not suitable. Toward scalability, aggregates must be created. The NodeOS aggregates entities into flows.

Dynamic modification of policy requires separation of policy database and enforcement engine.

The EE must enforce the NodeOS policy at a minimum; can choose to enforce a stricter policy.

Suggests using digital signitures and certificates.

Novel Applications.

Active Reliable Multicast: at the active node, suppresses duplicate NACKS, caches data and does local recovery.
Protocol Boosters (?)
ACC: Active Congestion Control: when congestion encountered, determine ideal window size, drop packets locally that would be out of that packet size, tell sender new window size. Improved throughput 18% over traditional TCP congestion control.
Auctions: can prune out-of-date bids; server sends current bids to active nodes.
ARC and Detour: (?) Need to refer to project documentation.

Interoperability. ANEP and XBone research efforts forwarding interoperability.

Questions

What of the protection within EEs?
They assume that the primary objective is for end-to-end services; what about inter-network services?
Can channels change mid-stream?
Is controlling bandwidth good enough for resource control? Won't stop malicious packets.
In resource protection, want to allow consumption of idle resources.
Can we build non-java EEs easily for performance. Would we end up with just another virtual machine?
Will using dig sigs be too slow??