PlanetLab is an overlay testbed designed to allow researchers to experiment with network applications and services that benefit from distribution across a wide geographic area. All uses of PlanetLab should be consistent with this high-level goal.

PlanetLab is designed to support both short-running experiments and continuously-running services. The former includes network measurement experiments that purposely probe the Internet, while the latter may serve an end-user community. In running these experiments and services, we expect researchers to adhere to widely-accepted standards of network etiquette, as well as adhere to the specific behavior defined in a companion document: The PlanetLab Acceptable Use Policy (AUP).

Hosting Site Responsibilities

Hosting a PlanetLab node implies supporting PlanetLab's research goals. In particular, hosting sites are expected to do the following:

• Provide IP connectivity for the node, including a single static IP address and a DNS name (including both forward and reverse lookup).
• Place the nodes outside the local firewall, in a network DMZ. This implies not filtering traffic into and out of PlanetLab nodes. In general, sites should take reasonable steps to isolate their PlanetLab nodes from the rest of their institution's computer systems.
• Allow the PlanetLab operations team to administer the node, including have root access, install and maintain the operating system, and set up research accounts. Local administrators do not have root on PlanetLab nodes, but they do have several administrator capabilities, as described below.
• Define a point-of-contact that can be called to re-boot a PlanetLab node.
• Forward complaints from external system administrators to the PlanetLab operations team.
• Enforce the PlanetLab AUP with regard to the actions of local users on any PlanetLab machine, whether hosted locally or at another institution. The PlanetLab community relies on each hosting site to stop unacceptable activity originating at that site.

System administrators at hosting sites are strongly encouraged to read the Technical Contact Guide for more information about what's involved in hosting PlanetLab nodes.

PlanetLab Responsibilities

The PlanetLab operations team will install software on PlanetLab nodes that enforces constraints on application programs, thereby limiting their effect on other network users. These constaints include:

• Limit outgoing network bandwidth. The local system administrator will be allowed to set the total outgoing bandwidth that can be consumed by the PlanetLab nodes they host.
• Filter packets addressed to certain destinations. Our policy is to not filter outgoing packets unless explicitly asked to do so by a network administrator that believes his or her network has been "attacked" from a PlanetLab node.
• Not allow applications to spoof IP addresses, or send well-known bad packets (e.g., "ping of death").
• Limit the rate at which probe packets and other potentially disruptive packets leave the site. The PlanetLab operations team will establish limits that are consistent with Internet norms.

PlanetLab provides an administrative slice that can be used to set these parameters on local machines. It also allows administrators to inspect packet logs and run an enhanced version of tcpdump that can relate packets to slices, and hence, projects and instituitions.

Note that it is likely that individual sites that host PlanetLab nodes will have their own AUPs. Since we expect sites to place their PlanetLab nodes outside their firewall, the "internal behavior" aspects of those AUPs are not likely to be relevant (except as they address bandwidth consumption). However, since administrators are likely to care about whether nodes running on their site exhibit "external behavior" that is contrary to their AUP, our policy is to support site-specific requests for restrictions (e.g., packet filtering) to the extent possible. Should such restrictions be contrary to PlanetLab's stated goal of supporting research into wide-area services, however, it may be the case that the only resolution is to remove the PlanetLab node from that site.

Hosting sites can also expect the PlanetLab operations team to take the following steps to ensure the security and integrity of the software running on each node.

• No users other than the PlanetLab operations team have root access to PlanetLab nodes.
• To reduce the chance of a remote root exploit, all PlanetLab nodes run only a limited set of remotely accessible system services as root. All other standard system services—e.g., FTP, TELNET, and SMTP—are disabled. Services that are enabled on the nodes include SSH (RSA authentication only), HTTP, and finger. For SSH, we use OpenSSH v3.7, which is free of any known security vulnerabilities. For HTTP and finger, we use bare-minimum daemons (both a page of Python code) that responds to all incoming connections the same way: by returning a single file with contact information. (Both HTTP and finger will soon be running as nobody to further reduce the chance of a remote exploit.)
• To reduce the chance of a local root exploit, all nodes are kept up-to-date with security patches. PlanetLab nodes currently run a Linux distribution that is largely based on Fedora Core 8. The operations team keep track of the latest security patches and update all the nodes. They also track CERT advisories, ISS security advisories, and security vulnerabilities posted to security mailing lists.
• To further reduce the chance of a local root exploit, remote access to PlanetLab nodes is done using sandboxed execution environments. These execution environments are chroot'ed and further constrained by also limiting the set of processes, IPC resources, network interfaces, and so on, that can be accessed with a sandboxed execution environment. In summary, once you're placed in a sandbox, the scope of your activities is limited to that sandbox. Therefore, even if an account is compromised, a hacker still won't have access to root on the machine, and the limitations outlined above will be enforced.
• Monitoring software installed on nodes provides an audit trail in the event of a security breach.
• To respond to security issues and potential security breaches in a timely manner, report incidents to the PlanetLab operations team.
• To reduce the opportunity for unknown users to abuse PlanetLab services, the PlanetLab operations team reserves the right to restrict end-users (clients of services running on PlanetLab) to those affiliated with PlanetLab sites.