Scriptroute Acceptable Usage Policy, version 1.1 (January 2004) Scriptroute is designed to prevent any actual security incidents, but you as a Scriptroute user can help to limit the number of headache-causing complaints your measurement traffic generates. Failure to design your experiment to avoid complaints may result in your banishment from Scriptroute. Updated Scriptroute AUPs will be posted on the scriptroute@cs.washington.edu mailing list. It is your responsibility to subscribe to this list and ensure that your experiment confirms to the AUP, although we would be happy to work with you to do so. This policy is composed of three sections: behavior you must avoid, behavior you should avoid if at all possible, and behavior you can trust Scriptroute to prevent. It is followed by a short guide to handling complaint ("report of network abuse") messages. Behavior you must avoid -- 1.1 Do not use scriptroute with the intent to abuse any host on the network. Most behavior is excusable if it was inadvertent and isolated. Abuse includes, but is not limited to, denial of service attacks, attempted host compromise, and more generally any attempt to launder traffic you could just send yourself. This prohibition also includes attempts to exploit bugs in Scriptroute to gain access to host resources. It is the most important rule, but also the least surprising, and we don't expect to have to remind anyone of this clause. 1.2 Do not synchronize your measurements to the same destination (that is, don't send traffic from multiple servers to the same place at the same time). The reverse path tree (rpt) example works as it does with the intent to avoid overloading any destination. If you need a tree of paths to a destination, use the rpt tool. Behavior you should avoid -- This is a list of best-practices. 2.1 If you have an ambitious experiment that uses several servers over several hours or days, please do not start it all at once. Try a limited-scale version first, wait a day or two, ensure that the data is what you wanted and that complaints haven't flooded in, and then proceed. Better yet, send us a heads-up so that we know what to expect. 2.2 If testing connectivity to the prefixes in the BGP table, try to use only the ".1's", that is, the first address in any prefix. This can limit your experiment if your goal is to send traffic absolutely everywhere in the network. Please only break this rule if you have reason to believe that the prefix was aggregated before being advertised, and it is necessary to send to the different prefix to see the different location. Such a "reason to believe" entails observing significantly different paths when running traceroute from a site you manage to different parts of a prefix. 2.3 Be aware of projects of comparable scope to your experiment. For example, CAIDA's skitter project measures connectivity to 43 million destinations: all advertised /28 prefixes, albeit from a smaller set of vantage points. Behavior we prohibit -- Please don't try any of these without alerting us first. We appreciate if someone looks for holes in the security policy, but would like to be advised first or give you a sandbox to work in. 3.1 Port scanning. Scriptroute ensures that no traffic be destined to priviledged ports (those below 1024, excluding 80 (web), 53 (dns), and 123 (ntp)). Further, TCP SYN packets are limited to one per second, which discourages port scans of higher ports. Note, however, that traceroute traffic may be mistaken for a port scan. As traceroute uses ports above 33,000, it is essentially useless for finding vulnerabilities. We also block port 31337, the default for Back Orifice. 3.2 Flooding. Each destination prefix by default can receive at most 8 kBits/s of traffic or 2 packet/s from any host. These configuration variables may be increased by the local administrator. Assuming you do not violate rules 1 and 2, a destination host should not have an excess of traffic to complain about. 3.3 Evil-packets. Malformed packets that are known to cause problems with some destinations are blocked. 3.4 Other stuff; for a complete description of all that is blocked, see the scriptroute administrator's guide for details or our USITS paper for a general description. If you're an administrator and someone complains about traffic (informational) -- The complaints we've seen about scriptroute and other measurement traffic cite the traffic pattern of a traceroute -- high numbered udp ports, fewer than ten packets -- and are the output of Intrusion Detection Systems (IDS) run by system administrators who do not differentiate between the output of an IDS and an actual intrusion or malicious port scan. It is possible to see the log of sent and received Scriptroute packets by visiting http://servername:3355/ and typing in the IP address of the alleged victim. This will show you who requested the traffic be sent, and if credentials are required by your server, an identifier that can be used to get an email address to contact the user responsible. If the traffic appears to be unlike traceroute or appears to be part of an abusive network experiment, we can give you the email address of a client matching an ns:@ cookie. Please forward complaint messages to block@scriptroute.org, preferably with a subject of "block " where represents the ip address prefix (or /32 if just a single host) that generated the complaint. We will ensure that no additional traffic from our scriptroute servers reach that destination in an effort to prevent further complaint traffic. -- If you have additional concerns or questions, please send mail to scriptroute at cs.washington.edu or to me, nspring at cs.washington.edu.