One of the main purposes of PlanetLab is to enable research into new internet technology. Frequently, researchers will deploy technologies on PlanetLab Europe that use the internet in new ways. As a result, PlanetLab network traffic is often viewed as anomalous by many automated Intrusion Detection Systems (IDSs) and may trigger alerts. If an alert is interpreted as a security threat by a system administrator or IDS, a complaint may be lodged against your site or other PlanetLab hosting sites.

While the vast majority of such complaints can be quickly resolved by explaining PlanetLab's purpose, some complaints may be an indication that an experiment is out of control or, rarely, that a slice has been compromised. All complaints should be taken seriously. When you receive a complaint about a security incident involving one of your PlanetLab Europe nodes, determine the IP addresses of all hosts involved, and the time when the incident occurred. You may have to ask the person who reported the incident for this information. If they cannot or will not give you this information, there is little that can be done to investigate the incident, and the incident can be resolved if your local site administrators agree.

Once you have determined the IP addresses of all hosts involved, you may be able to identify which slice sent the traffic and ask the researchers in charge of the slice to deal with the complainant directly. Use the search form on the home page of the PlanetLab node(s) involved in the incident (for example, http://planetlab-1.cs.princeton.edu/) and input as much information as you can about the incident (the hosts and ports involved and a time frame). If you are able to determine which slice was responsible for the traffic, contact the researchers in charge of it for an explanation, and ask that they respond to the complainant directly and copy you and PlanetLab Support on all correspondence.

To contact the PI, Technical Contact, or users of a particular slice, such as princeton_test1, send e-mail to the following aliases, replacing princeton_test1 with the name of the slice and princeton with the "short name" of the site:

• princeton_test1@slices.planet-lab.org

  The users of the princeton_test1 slice, and their PI.

• pi-princeton@sites.planet-lab.org

  The PI(s) at Princeton.

• tech-princeton@sites.planet-lab.org

  The Technical Contact(s) at Princeton.

If you are forced to take immediate action by your local site administrators, or because you suspect that one of your nodes has been compromised, reboot the affected node(s) into their secure Debug mode by following the instructions in Debug Mode. Do not disconnect your nodes from the network or turn them off; as explained in Debug Mode, any offending network traffic will stop once the nodes reboot into debug mode. Contact PlanetLab Support immediately after rebooting your nodes to assist in resolving the complaint.

Common Problem Reports

It is not uncommon for normal PlanetLab network traffic to be misinterpreted by IDSs as an attack or a symptom of a compromised machine. For example, PlanetLab Support often receives complaints that a PlanetLab node is a Windows-based machine that has been infected by a virus. Of course, such a claim is misguided, since PlanetLab nodes are Linux-based, but you should still take such complaints seriously, investigate the source of the traffic, and attempt to resolve them.

Other common problem reports, and suggestions for resolving them, are listed below.

Excessive Traffic

Some experiments generate large amounts of network traffic, sometimes for sustained periods of time, and may trigger alarms at your site. You may cap the outbound network bandwidth of your PlanetLab nodes by following the instructions in Setting Bandwidth Limits. If you suspect that an experiment is out of control, or your site cannot handle the traffic load even with bandwidth limits in place, contact PlanetLab Support. Otherwise, try to explain to local site administrators the nature of PlanetLab, its requirements, and that heavy network usage is to be expected.

Port Scans

Network mapping experiments running on PlanetLab often probe remote hosts, triggering "port scan" alerts. Sometimes, problems with probing experiments manifest themselves locally:

• Probes often contact a large number of unique destination addresses and may overload the caches on your local routers.

• Bursts of incoming ICMP errors (e.g., TTL Exceeded or Port Unreachable) may be received in response to locally generated probes.

Established network mapping services running on PlanetLab such as Scriptroute go to great lengths to minimize the chance of triggering a port scan alert. If you receive a port scan alert and cannot placate the complainant, contact PlanetLab Support to have the complainant's subnet added to a blacklist.

Open Proxy Alerts and Objectionable Content Complaints

Several "semi-open" proxies run on PlanetLab that test new content distribution technologies. Two of the more successful proxies currently running are CoDeeN and CoralCDN.

Many system administrators lodge complaints against PlanetLab proxies because they notice large amounts of traffic from PlanetLab to their site, and are either unaware that users at their own site are requesting the traffic through PlanetLab proxies, or do not know that the proxies are research projects that are actively managed. Most of the time, a simple explanation of what a proxy is, and how PlanetLab proxies are not entirely "open", suffices to resolve this type of complaint.

You may receive complaints about objectionable or illegal content being served from proxies running on your PlanetLab nodes. Because most proxies running on PlanetLab are caching proxies, the content is not being served from your nodes, it is being served from a third-party server somewhere else on the Internet, to a user who has voluntarily requested it. Nevertheless, if you or your local site administrators feel pressured to withdraw from the PlanetLab Consortium agreement because of objectionable or illegal content passing through your nodes, contact PlanetLab Support to have the incident reviewed.