• HOME
  • About
  • Program Plan
  • Annual Report
  • Joining CAIDA
  • Staff
  • Jobs
  • Legal Agreements
  • How-To
  • Blog
• RESEARCH
  • Routing
  • Topology
  • Security
  • Traffic Analysis
  • Economics and Policy
  • Visualization
• DATA
  • Overview
  • Data Sharing
  • Distribution Statistics
  • How-to
  • Data Usage FAQ
  • Papers using CAIDA Data
  • Acceptable Use Agreement
• TOOLS
  • Overview
• INTERACTIVE
  • AS Rank
  • DatCat
  • DDec
  • Vela
• PUBLICATIONS
  • Papers
  • Presentations
  • Blog
  • Visualizations
  • - Animations
  • - Posters
  • Networking Bibliography
• WORKSHOPS
  • Overview
  • CREDS
  • AIMS
  • NDN
  • WIE
  • CAIDA-WIDE-CASFI
  • Collaborative
  • Archive
• PROJECTS
  • Ark
  • Macroscopic Topology
  • Cybersecurity
  • Spoofer
  • Network Telescope
  • IMPACT (PREDICT)
  • IODA
  • Named Data Networking
  • IMDC (DatCat)
• FUNDING
  • PANDA
  • STARDUST
  • SISTER
  • AT&T Interconnection
  • Spoofer
  • iLENS-NP
  • Congestion
  • IPv6 Adoption
  • HIJACKS
  • Named Data Networking
  • Econ-Contract
  • IMPACT (PREDICT)
  • Program Plan

CAIDA Obligations and Expectations

In pursuit of this research purpose, CAIDA aims to be a responsible steward of the measurement infrastructure hosted by your organization and will conduct measurements that are ethical, conform to best practices, respect your policies, and do not impose an unacceptable burden on your network.

Ark is intended to be a step toward a community-oriented measurement infrastructure. To that end, Ark nodes may be used by both internal CAIDA researchers and suitably vetted 3rd-party researchers to conduct measurements. CAIDA utilizes both policy and technical safeguards to ensure that only legitimate researchers are granted access to Ark nodes, that these users agree to uphold Ark node usage policies, and that appropriate information security controls are in place to minimize risks associated with node usage.

In addition, all measurements are vetted to conform to community best practices regarding respect for network and system resources. To this end, CAIDA enforces reasonable limits on measurement rate and volume. CAIDA also maintains a "no probe" list for applicable measurements to comply with end-user requests to opt-out of future measurements. Hosting sites should forward to us any complaints they receive from end users who have received measurement traffic, and we will respond to the complaints (letting the hosting site know of our responses) and, if necessary, add destinations to our no-probe list to prevent future complaints. For over a decade, CAIDA has maintained and obligated users of CAIDA data and infrastructure to adhere to a no-probe list for topology measurements.

An Ark node will only collect or analyze its own traffic, such as responses to measurement probes it sends itself. Some typical uses of Ark nodes include:

• topology measurements such as ICMP, TCP, and UDP traceroute and ping measurements to a broad cross section of the routed address space;
• performance measurements such as one-way delay, loss, and jitter; and,
• DNS measurements such as query latency to root servers.

An informative FAQ provides more details about expected usage patterns and incoming and outgoing traffic details at http://www.caida.org/projects/ark/siteinfo.xml.

CAIDA will ask each hosting site for specific permission to conduct any measurements that are functionally and consequentially different from the typical set of measurements listed above. For example, CAIDA has asked in the past for permission to use Ark nodes to collect data for the MIT Spoofer Project.

CAIDA will remotely manage the Ark monitor to fulfill our intention of minimizing the ongoing effort and involvement needed by the hosting site after initial installation and setup of the server. Specifically, this includes managing user accounts, installing software, applying security patches, and upgrading the operating system. However, CAIDA will provide a system administration account on an Ark monitor for the hosting site if requested (note: most servers can be cleanly powered down on short notice without logging in by simply pushing the power button, and this feature satisfies the most common need for a local account).

Hosting Site Obligations and Expectations

To support the primary goal of comprehensive and continuous long-term measurements, CAIDA requests the following deployment environment and operational support, where possible:

1. The Ark monitor is either a dedicated 1U server placed in a server rack or a Raspberry Pi placed in any suitable location--in a server rack, on a desk in an office, or anywhere at home with/without a NAT. In the case of a 1U server, the ideal placement is in a server room with uninterruptible power (UPS);
2. The hosting site provides physical administration ("remote hands") at the system console to troubleshoot and revive a nonfunctioning Ark monitor if a problem cannot be resolved by CAIDA remotely. We ask that the hosting site respond to these requests within two weeks of being notified;
3. The hosting site notifies CAIDA of any scheduled maintenance that may disrupt power or network connectivity so that CAIDA may plan time-sensitive measurements accordingly;
4. The hosting site whitelists the persistent contact address monitor-info@caida.org that CAIDA will use for all monitor-related communication; and,
5. The hosting sites designates a contact for Ark-related communication and notifies CAIDA of updates in the contact address to ensure uninterrupted communication.

In addition, the hosting site may need to make adjustments to the network environment to accommodate an Ark monitor. For example:

1. An Ark monitor may need to be put into an exception list for security monitoring and firewalls. In particular, the hosting site may need to relax firewall rules to allow the anticipated set of measurement probes and responses (please see the firewall configuration section of http://www.caida.org/projects/ark/siteinfo.xml). If desired, the Ark monitor may be put in the DMZ for increased security.
2. Rate-limiting of ICMP probes and responses may need to be removed. Ark measurements will not generate a high packet rate, but certain implementations of rate limiting (for example, dropping 50% of all ICMP packets) will significantly impair even low-rate measurements. Rate-limiting of other measurement packets may need to be removed as well, depending on actual node usage (for example, DNS queries and responses if conducting DNS performance measurements), but CAIDA will separately discuss and gain approval of such requirements with the hosting site.

Termination

This MOC will remain in effect until either CAIDA or the hosting site indicates in writing its decision to terminate the cooperative arrangement described herein. Upon termination, CAIDA and the hosting site will discuss and agree to either dispose of or return any CAIDA-provided hardware.

Contact

CAIDA welcomes your comments and/or concerns regarding the obligations and expectations described in this MOC. If you believe that CAIDA or one of its Collaborators has not adhered to these provisions, or if you later determine a specific use to be unacceptable, please contact us at ark-info@caida.org. We will use best reasonable efforts to promptly work with you to determine and remedy any problem.