PLAN Security System

Active Networks offer the ability to program the network on a per-router, per-user, or even per-packet basis. Unfortunately, this added programmability compromises the security of the system by allowing a wider range of potential attacks. Any feasible Active Network architecture therefore requires strong security guarantees. Of course, we should like these guarantees to come at the lowest possible price to the flexibility, performance, and usability of the system.The PLAN system is a distributed programming framework we have used to build an Active Network, PLANet [4]. In the PLAN system, code implementing distributed programs is broken into two parts: the PLAN level, and the Service Level. All programs in the PLAN level reside in the messages, or packets, that are sent between the nodes of the system. These programs are written in the Programming Language for Active Networks [6] (or simply, PLAN). PLAN programs serve to "glue" together Service level programs; PLAN may be thought of as a network scripting language. In contrast, Service level programs (or simply, services), reside at each node and are invoked by executing PLAN programs. Services are written in general-purpose languages (in particular, the language that the PLAN interpreter is written in) and may be dynamically loaded.
The current Internet (IP and its supporting protocols) allows any user with a network connection to have some basic services. In addition to basic packet delivery provided by IP, basic information services like DNS, finger, and whois, and protocols like HTTP, FTP, TCP, SMTP, and so forth are provided. Similarly, a goal of PLANet is to allow any user of the network to have access to basic services; these services should naturally include some "activeness." This goal implies that some functionality, like packet delivery in the current Internet, should not require authentication; in PLANet, we allow "pure" PLAN programs to run unauthenticated. A PLAN program is considered "pure" if it only makes calls to services considered safe; for example, determining the name of the current host is a safe operation, while updating the host’s router table is not. Successfully calling unsafe services would require proper authorization. This security policy is stated more formally in the following subsection.