Overview

Purpose

• PEERING is a testbed designed to allow researchers to experiment with Internet routing and services that benefit from control over and/or visibility into Internet BGP routing. All uses of PEERING should be consistent with this high-level goal.

Safety

• PEERING interacts directly with real networks around the world, exchanging routes and traffic, and a guiding principle is that experiments should not disrupt Internet services that are not running on PEERING.

Guidelines

• As it interacts with real networks, PEERING is not a "testbed" in the usual sense of a controlled environment for experiments. It consists of computational resources hosted by organizations (including Universities, Internet exchange points, and collocation facilities) that donate their own time, rack-space, and network connectivity for the good of the community. Running an experiment on PEERING is fundamentally different from running it in a LAN-based lab or on an isolated wide-area testbed.
• A good litmus test when considering whether an experiment is appropriate for PEERING is to ask what the network administrator at your organization would say about the experiment running on your local site. If the experiment disrupts local activity (e.g., uses more than its share of your site's Internet bandwidth) or triggers complaints from remote network administrators (e.g., performs systematic port scans or hijacks prefixes), then it is not appropriate for PEERING. It is your responsibility to ensure that your use of PEERING falls within these constraints. This means you should debug your code in a controlled environment so you have confidence that you understand its behavior.
• PEERING is also designed to allow experimental services to run continuously, thereby supporting an end-user community. As a consequence, PEERING could indirectly support users who interact with PEERING traffic (sending/receiving), or are disrupted by PEERING traffic. These users have not officially registered with PEERING, and may even be unknown to you (the service provider). It is your responsibility to ensure that your users do not cause your service to violate the terms of this AUP. In particular, service providers should ensure that their users are not able to hijack their service and use it to attack or spam other nodes or network users.
• PEERING is designed to support network measurement experiments that probe the Internet. However, we expect all users to adhere to widely-accepted standards of network etiquette in an effort to minimize complaints from network administrators. Activities that have been interpreted as worm and denial-of-service attacks in the past (and should be avoided) include sending SYN packets to port 80 on random machines, probing random IP addresses, repeatedly pinging routers, overloading bottleneck links with measurement traffic, and probing a single target machine from many PEERING nodes.
• It is likely that individual sites that host PEERING nodes will have their own AUPs. Users should not knowingly violate such local AUPs. Conflicts between site AUPs and PEERING's stated goal of supporting research into Internet routing should be brought to the attention of PEERING administrators. The expectations placed on sites that host PEERING nodes are described in a companion document: Hosting a PlanetLab Node.
• While the central PEERING authority is often the first point-of-contact for complaints about misbehaving services, PEERING operators may at their discretion put the complainant in direct contact with the researcher that is responsible for triggering the complaint.
• PEERING provides absolutely no privacy guarantees with regard to packets sent to/from slices. In fact, users should assume announcements will be monitored and logged, for example, to allow other users to investigate abuse (see previous paragraph). Other traffic to and from the testbed may be monitored, logged, and recorded as well, at the sole discretion of PEERING operators.
• PEERING also does not provide any guarantees with respect to the reliability of individual nodes, which may be rebooted or reinstalled any time. Reinstalling a node implies that any established sessions will be reset, and the disk may be wiped. Rebooting a node implies that established sessions will be reset.

Rules

Restrictions on Activity

• PEERING must not be used for any illegal or commercial activities. Use for research and educational purposes is allowed. Experiments MUST follow the proposal as approved by PEERING support, and any desired changes in experimental plans MUST be approved by PEERING support before being run.

Node Usage Rules

• Use existing security mechanisms. For example, all access to PEERING nodes must be via OpenVPN tunnels, users should not share their OpenVPN credentials, and users must be approved and authorized by PEERING support to connect and conduct experiments.
• Do not circumvent accounting and auditing mechanisms. This means you must associate your identity with the PEERING account that conducts your experiments, and you must not do anything to obfuscate the audit trail.
• Do not attempt to test the security of the PEERING nodes or configuration. This includes "red team" (hacker test) experiments. All access is non-root.

Network Usage Rules

• Do not use your PEERING account to gain access to any hosting site resources or Internet resources that you did not already have. This includes internal resources at the networks where the PEERING muxes are hosted.
• Do not use one or more PEERING nodes to flood a site with so much traffic as to interfere with its normal operation. Use congestion controlled flows for large transfers.
• Do not announce any prefixes outside of those approved for your use by PEERING support in response to your experiment proposal. Only make announcements as described in your proposal AND approved by PEERING support, and only make announcements for the time period for which PEERING support has explicitly approved your use. Do not make any announcements that could interfere with traffic that is not either sourced from or destined to PEERING addresses allocated to your experiment. Do not send ill-crafted or anomalous BGP announcements, including announcements that are larger/longer than announcements that occur regularly on the “normal” Internet. Follow all guidelines laid out in your proposal and in email exchanges with PEERING support in terms of what you will announce, when you will announce it, and how you will advertise it to the larger Internet operations community.
• Only send traffic sourced from prefixes approved for your use by PEERING support in response to your proposal. Do not spoof other addresses.
• Do not perform systematic or random port or address block scans. Do not attempt to sniff other users traffic.
• Unless explicitly approved by PEERING support, announcements of a particular prefix cannot be more frequent than once every 10 minutes (averaged over a day), and announcements cannot be made to a particular PEERING node more frequently than once every 10 minutes (averaged over a day).

Active Probing Requirements

• Active probing MUST be approved by PEERING support. Proposals must specify the aggregate, per-mux, and per-destination probing rates in packets per second and Mbps. If relevant, please specify the average (sustained) and peak probing rates.
• Probe packets must include a payload with a link to a webpage describing the measurements and their purpose.
• Experiments must be ready to blacklist (remove) destinations from probing in case of complaints.
• One round of equivalent active probing experiments should be run from your institution before being run on PEERING.

Consequences

• Violation of this AUP may result in any of the following: disabling the account; Banning the institution and/or researcher from PEERING; informing the organization's administration.
• To report a suspected violation of this policy, contact PEERING support (noc at peering.ee.columbia.edu).