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
- 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
- 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.
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
- 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
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
- 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
- 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
- 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.