Node Contribution

If a Node Contribution is required for the type of membership specified, Member agrees to dedicate at least two server-class machines (called nodes) to the PlanetLab Europe testbed. Nodes must meet the Minimum Hardware Requirements in force at the time of entering into this Membership Agreement; these are appended to, and form an integral part, of this Membership Agreement. The nodes are exclusively devoted to PlanetLab Europe operations, and all data on the nodes are erased as part of the installation process.

  1. Hosting Site Responsibilities

    2. 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 Europe nodes. In general, sites should take reasonable steps to isolate their PlanetLab Europe nodes from the rest of their institution’s computer systems.
    • Allow the PlanetLab Europe 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 Europe 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 Europe node.
    • Forward complaints from external system administrators to the PlanetLab Europe operations team.
    • Enforce the PlanetLab Europe AUP with regard to the actions of local users on any PlanetLab machine, whether hosted locally or at another institution. The PlanetLab Europe community relies on each hosting site to stop unacceptable activity originating at that site. The PlanetLab Europe operations team will install software on PlanetLab Europe nodes that enforces constraints on application programs, thereby limiting their effect on other network users. These constraints 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 Europe nodes they host.
      • Filter packets addressed to certain destinations. PlanetLab Europe 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 Europe 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 Europe operations team will establish limits that are consistent with Internet norms. PlanetLab Europe provides an administrative slice that the Member can use 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 institutions.
  2. PlanetLab Europe Responsibilities

    3. The Member can expect the PlanetLab Europe 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 Europe operations team and their authorized agents have root access to PlanetLab Europe nodes.
    • To reduce the chance of a remote root exploit, all PlanetLab Europe 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. PlanetLab Europe’s aim in configuring these services is to provide the maximum security possible while allowing essential PlanetLab Europe operation.
    • To reduce the chance of a local root exploit, all nodes are kept up-to-date with security patches. The operations team, directly or through agents, keeps track of the latest security patches and updates 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 Europe 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. As a result, 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.