Internet Indirection Infrastructure April 16, 2009

This seems to do the same as SSH reverse tunneling in terms of its mobility.

Indirection — this allows for portability in that the end user does not need to know the exact location of the other end and the system can more easily do “creative” rerouting (e.g. multicast).

Distributed routing “tables” — instead of having one central domain name server as a single point of failure, this allows for some reliability through multiplexing and redundancy.

I see an issue with the routing efficiency. The paper gives the example of having the sender and receiver in Berkeley, but the i3 node storing the triggers in London. The claim is that the data can avoid the trip from Berkeley to London and back by way of a private trigger on a closer server, but does not account for the case where there is no closer server.

Active Network Vision and Reality: Lessons from a Capsule-based System. April 14, 2009

The authors provide a description of their experience building and using an active network system, ANTS. ANTS is a system that routes capsules (i.e. network packets) through a network of active nodes according to custom software, as provided by the capsules themselves. Because the software is custom, it can provide support for deploying a new protocol without changing all the routers currently in the network.

ANTS is a Java based active router that runs on PCs called active nodes in the paper. The capsules are augmented IP packets that contain additional header information that (among other things) defines the custom software to run. The custom software is not actually contained in the capsule itself. It is referenced by a signature in the capsule and acquired separately via a directory service.

One of the key characteristics of this implementation is that despite the fact that the capsule doesn’t contain the custom code itself, the code is still acquired on demand. When an active node receives a capsule that doesn’t have the necessary custom code, a header in the capsule defines the previous active node. This previous active node can supply the necessary missing code on demand. This solution is efficient in that it only requires distributing custom code when necessary and only to those nodes on the path of actively routed capsules.

Another benefit of the ANTS design is that the active nodes are based on soft state. Thus each active node has the flexibility to unload state as necessary. The state can be reacquired at some later point if necessary. This flexibility may result in dropped capsules, but the authors argue that this behavior is consistent with “normal” levels of packet loss in traditional forwarding networks.

Lastly, and possibly the most important contribution, the ANTS implementation supports incremental deployment. All custom protocols must support heterogeneous network environments, where active nodes are connected by traditional IP forwarding nodes. This requirement allows the ANTS system to be deployed over existing networks. Ultimately, any new protocol will need to be deployed incrementally as it is unrealistic to expect any large network to change nodes completely and instantaneously.

Unfortunately, their security model is not as well crafted. The authors describe how they tried to balance security with the idea of making ANTS available to anyone with a new protocol. It seems that their compromises were less than successful at achieving either goal. Although the ANTS runtime environment provides significant protection in terms of protocol isolation and resource usage, the validity of the custom routing code ultimately boils down to third party certification. This approach seems to be used when no other alternative to programmatic security can be thought of.

Despite some faults, the ANTS system seems like a reasonable implementation for trying active network approaches. I’d like to see further research in terms of developing low cost devices that can function as active nodes. FPGAs are a likely candidate as they can perform a constrained set of active node API operations at wire line speeds.

Active Network Vision and Reality: Lessons from a Capsule-based System April 14, 2009

Contributions

This paper describes an extensible forwarding architecture for the internet and presents design experiences and experimental results for security and performance concerns. It is a concrete implementation of the active network model, which envisioned distributing computing resources to many nodes on the network, to leverage their computing power in order to solve complex compute-intensive tasks. Since the architecture is extensible in respect to tasks, the computing code (or for this paper, the forwarding code) has to be distributed to all participating nodes.

To achieve backwards compatibility and adhere to slow adaption of the new architecture in the internet, the proposed packet format is an extension to IP’s packet format, which allows the so-called “capsules” to be forwarded as normal IP packets by existing routers, and be forwarded according to their associated forwarding code by the so-called “active nodes” which have adapted to the capsule standard and the new architecture. Therefore, it creates an overlay network.

The services supported by this network are identified by the MD5-hashes of their forwarding code, which each of the nodes on the route to the target receives from its upstream node. These MD5-hashes are stored in the capsule and due to security measures, they cannot change on any node in the network. The code itself is executed in a sandbox environment and has limited access to its environment, although services belonging to the same family can share state information.

Furthermore, the paper presents resource allocation problems in this overlay network, for the solution of which the authors fall back to certification mechanisms by a trusted authority (e.g. the IETF).

The authors also provide performance measurements, they report a slow-down ratio of around 4, due to the software forwarding in Java (1.2).

Overall, the authors imagine this network to support different multicast schemes and congestion notifications.

Most glaring problem

In retrospect, the advances in MD5-collision finding suggest that it may be possible to inject service code in the network for an existing service, therefore possibly breaking it. Due to the fixed nature of the packet format changing the hash function is non-trivial, so future versions should be extensible in respect to the type field.

Future work

It would be very interesting to see if these software-based forwarding mechanisms can also be implemented in hardware, being extensible by using FPGAs, to achieve higher performance goals while preserving the architecture goals.