Tor as infrastructure: challenges and opportunities

Infrastructure as a Service (IaaS) is commonly used within enterprise environments whereby organizations pay for someone else’s physical or virtual resources, including networking resources. Individuals also pay for IaaS when, for example, they need to deploy a VPS or VPN for personal use. From Gartner:

Infrastructure as a service (IaaS) is a standardized, highly automated offering, where compute resources, complemented by storage and networking capabilities are owned and hosted by a service provider and offered to customers on-demand.

 

Tor, the network of operators that make up the network, is IaaS. What is unusual about this terminology is that the Tor network is distributed, and utilization of this networking resource is free. Companies like Duck Duck Go, Facebook, New York Times, and every organization utilizing SecureDrop including the Associated Press, is using this IaaS in order to best support their users’ privacy rights.

A problem that Tor network operators have always faced is that setting up and maintaining the network is not free. Tor is free-to-use IaaS on purpose — people and services need to be able to use the network without attribution in order for Tor to provide specific guarantees of privacy.

If privacy infrastructure operators had better funding, we would be in a better position to support larger infrastructure needs. For example, if Mozilla or Brave ever wanted to collect browser telemetry over Tor onion services to best support the privacy of their users, the Tor network would likely need to pivot towards larger and more stable network operators. In this article, we will look at some of the challenges and opportunities for operators of privacy infrastructure.

Challenges

Emerald Onion was created, in part, to be able to demonstrate a successful Transit Internet Service Provider that only supports privacy IaaS. It was designed to best leverage existing laws in the United States in tandem with operational designs that require privacy-focused security properties. There have been and continue to be serious challenges facing Emerald Onion along with any other organization that is dedicated to privacy IaaS.

IP transit service is exclusively a for-profit business

IP transit is a required part of an ISP. Emerald Onion, Riseup, Calyx, Quintex, etc, need to pay upstream providers who provide the physical transport of the encrypted packets that we transit as part of the Tor network. This transit service is expensive. For example, 1Gbps of service in a residential setting can cost around $80 per month in Seattle, and 1Gbps of service in a datacenter can easily cost $800 per month. This dramatic cost difference is because of capitalism — it is presumed that a service provider in a datacenter environment is going to be profiting off of this service. Upstream providers don’t care one bit that Emerald Onion is a 501(c)3 not-for-profit supporting human rights.

Little options for trustworthy, open source hardware, particularly networking equipment

Emerald Onion is using general-purpose computing devices (currently low-power Intel Xeon D) with BSD operating systems. It is a priority for us to be using trustworthy compute infrastructure, so we are at least ensuring that the kernels and applications that we use are free/libre open source software. We hope to transition to free/libre open source hardware and firmware as soon as we can, but we also have to be concerned with compatibility and stability with HardenedBSD/FreeBSD, and the cost of this hardware. We know that options exist for free/libre open source hardware, but this is still a very new and maturing market. To further complicate this prioritized need for trustworthy compute infrastructure, Emerald Onion has particular interest in 10Gbps networking for both the LAN and WAN.

One day, we’d like to be able to support 40Gbps and 100Gbps; however, we are not aware of any free/libre open source hardware and firmware that supports 40Gbps or 100Gbps networking.

High cost of network redundancy

Our proof-of-concept work has focused on low-cost options. This means we do not currently have redundancy at our LAN or WAN layers. Network redundancy for Emerald Onion, at minimum, would entail having not just one expensive IP transit link, but two, ideally from different upstream providers, which means two edge routers and two links to each of our Internet Exchange Points. This would also mean that we have to add redundant LAN switching, and all of this means increasing our rack space and power requirements. Basically, we would have to more than double our recurring costs to be able to have this level of infrastructure stability. While Tor itself is highly resistant to network changes, the more capacity that Emerald Onion, and other large Tor operators support, the greater the negative impact we would impose on the Tor network whenever we have to perform hardware, firmware, kernel, and application updates.

IPv4 scopes for exit operators

As an exit relay operator, Emerald Onion must own and operate our own IPv4 address space for efficiently handling abuse communications from other service providers and law enforcement. Additionally, relay operators who peer directly with other service providers in Internet Exchange Points (IXPs) who have their own Autonomous System Number (ASNs) also require their own IP space. The entire world ran out of IPv4 address scopes to hand out to new and existing service providers a few years ago, and this is a blocker for any new Tor operator who is working to achieve the same level of stability that Emerald Onion is working to achieve.

Tor exit relaying currently depends in IPv4 connectivity between Tor routers (middle relay to exit relay traffic, for example). To be given an exit flag, a static IPv4 address is ideal for the Tor network (dynamic IP addresses would require a few hours delay of client discovery in the consensus).

Tor exit operators would not need their own Regional Internet Registry (RIR) -provisioned IPv4 address space if the exit flag could be given to IPv6-only operators, but this is not currently possible. ORPort connections (inter-tor circuit connections from middle relays, for example) cannot usually generate abuse, so IPv4 scope leasing is an easier option if IPv6-only exiting was a possibility.

One idea that Emerald Onion has had is that it may be possible to make proposals to large organizations, including universities, that are sitting on very large IPv4 scopes. We think that these organizations might be willing to donate small (/24) scopes to not-for-profit Tor network operators.

Opportunities

Surveillance and latency minimization

Seattle is home to a very large telecommunications hub called the Westin Building Exchange (WBE). We know that this building has National Security Agency (NSA) taps on I/O connections that are likely to facilitate traffic to regions like China and Russia. Additionally, WBE hosts several of the Internet’s DNS Root Servers, several of which are part of the Seattle Internet Exchange (SIX).

Emerald Onion went through the process of securing our own ASN, IPv6, and IPv4 scopes from American Registry of Internet Numbers (ARIN). We needed these things to connect to the SIX. Connecting to the SIX means that we are physically and directly connected to as many as 280 other service providers. We made this a priority because direct peering, using Border Gateway Protocol (BGP), minimizes the amount of clear-net switches and routers that a Tor user’s exit traffic has to travel through to reach its final destination. Every switch or router that Tor traffic has to traverse is an opportunity for surveillance and adds latency.

This strategy for Tor exit router placement is also ideal considering DNS. Being that multiple DNS Root Servers are directly peered with Emerald Onion, this further minimizes a global persistent adversary’s ability to spy on what Tor users are doing.

Statistically, due to requirements in the Tor protocol, individual Tor circuits bounce around multiple countries before they exit the network. This means that a non-trivial amount of the traffic that Emerald Onion, and any other United States exit operator facilitates, comes from a middle relay not within the United States. In tandem, generally speaking, a non-trivial amount of Tor exit traffic is destined to American services like Akamai, Cloudflare, Facebook, Google, and DNS Root Servers. These two likelihoods, together, means the following:

Tor exit traffic that is destined to service providers in the United States is best served, in terms of surveillance and latency minimization, by Tor exit operators that have exit relays connected to IXPs in datacenters along the coasts of the United States where undersea cables physically terminate, presuming that popular service providers like Akamai, Cloudflare, Facebook, Google, and DNS Root Servers are direct peers. This, in theory, minimizes the opportunity for American-sponsored traffic analysis, data retention, and surveillance, in addition to any other global persistent adversary who may have compromised network equipment within IXPs.

Emerald Onion has already compiled an initial list of IXPs around the United States. We continue to work on a list of qualities that an IXP should have that is a ideal for a Tor network operator:

  • Number of participants — This is important because if there is a peering link (using BGP) with another service provider, the opportunities for surveillance are minimized. For obvious reasons, the amount of direct peers is as important as the popularity of said services.
  • Access to specific participants — This is important because, for example, peering agreements with large providers such as Akamai, Cloudflare, Facebook, Google, and DNS Root Servers minimize the opportunity for surveillance while minimizing latency.
  • Nonprofit and affordable — A large number of IXPs are for-profit and thus have high up-front and high recurring costs for connectivity, in addition to setup fees and recurring fees for copper or fiber maintenance.
  • Geo-location — This is important because of, at least, location diversity, peer diversity, and direct connections with international undersea cables are focal points for the facilitators of global passive surveillance.
  • Prohibits network surveillance — The Seattle Internet Exchange, for example, has a stated policy that prohibits surveillance on peering links. One day, we hope that the SIX, and other public-benefit IXPs, will also publish a regular transparency report.

Funding

Emerald Onion has been in operation for 10 months. We wouldn’t exist, as we are today, without the generous startup grant of $5,000 from Tor Servers. We also would not still be around without the continuous donations from our Directors who personally donate as much as $350 each month. We currently require roughly $700 per month to operate, largely due to our service contract with our co-location provider who is also our upstream transit ISP.

Going back to the beginning of this article, the Tor network is a privacy-focused IaaS. Sustainability is a constant issue for Tor network operators, especially for operators who preemptively tackle legal and long-term operational challenges. We need help. There is no easy answer for funding. Grant writing and grant management is not a trivial task, nor is sustaining a 501(c)3 not-for-profit purely based on part-time volunteer work. Emerald Onion is incredibly lucky to have a few people who regularly donate large amounts of money and time to keep the organization online, but this is not sustainable.

The operations model that Emerald Onion has created, however, is scalable if properly funded. If we were provided between between $7,000 to $10,000 per month, we could multiply our capacity by a factor of 10. If we had a pool of funding that supported 10 independent Tor network operators in the United States (there are over 100 IXPs in the United States), we could dramatically bolster the capacity and stability of the Tor network while also minimizing network surveillance opportunities and network latency.

Conclusion

I hope that this article begins to shed light on the challenges facing privacy IaaS providers like the thousands of operators that make up the Tor network. Emerald Onion is going to continue to educate others on these topics, attempt to find and create solutions for these challenges, and continue to encourage hacker communities around the United States to build their own privacy-focused not-for-profit ISP.

OTF Concept Note

What is your idea?

Emerald Onion is a recently founded ISP/community non-profit organization based in Seattle seeded by a Tor Servers grant and personal donations. Our goal is to expand the privacy community by lowering the cost and learning curve for community organizations in the US to operate infrastructure.

Existing organizations in this space, Calyx and Riseup, have succeeded in rapidly becoming focal points for the community, but are inherently difficult to scale and are most effective in their local geographic communities. Thus, while Riseup has excelled at providing technical software, there is no easy path to establishing similar organizations. We want to change that!

In beginning the process of establishing ourselves, we have been documenting every step of the way. We are already running multiple unfiltered Tor exit nodes, and have both legally vetted abuse letters and educational material for law enforcement published. Now, we want to take this knowledge and export it to other communities. In particular, we want to focus on areas near Internet Exchange Points that are in at least 49 metro locations around the US, which can provide economical pricing and good connectivity for Internet traffic. We hope to spur wider deployment of Tor, onion services, and surrounding privacy technologies by helping other local groups follow our path.

Part of this mission is becoming a focal point for privacy operations work ourselves. Working with researchers at Berkeley, we are contributing to easier handling of abuse complaints. With academics in the Tor community, we are piloting new exit strategies to limit the impact of censorship. With the open source community, we are increasing platform diversity through the use and documentation of HardenedBSD as an alternative software stack. Our trajectory as an organization will include partnering with these organizations to improve usage and deployability, education of other network operators, and increasing our network presence and capacity.

What are your goals / long-term effects?

Our goal is that most major communities in the US have local organizations focused on operating privacy technology. Hackerspaces today are a mixed bag, and are often centered around physical rather than digital creation. Despite the presence of major IXPs, there are many urban centers today without community-driven organizations working to bolster privacy. We envision providing the groundwork and enthusiasm to support a network of ISPs around the country that can rectify this situation. Getting these entities in place will be important underlying infrastructure for future decentralized and federated networks to follow the model of Tor today.

Emerald Onion will directly evangelize operational best practices as it matures as a community organization and fits into the Seattle privacy community. To take advantage of Seattle’s position as one of the largest exchange points in the world, Emerald Onion will actively seek out peering agreements and aim to transit a significant amount of Tor traffic. Through our ISP operations, we hope for two primary longer term effects: First, that we are able to disseminate knowledge of peering agreements to make it significantly easier for other entities to understand how to enter into these negotiations. Second, that we can help Tor and other privacy enhancing networks gain capacity, reliability, and strategies for resilience to censorship. These technologies have focused on their software properties, but there are significant operational and networking challenges that need to be solved in tandem. We believe entities like Emerald Onion are the right complement to help privacy technologies succeed.

How will you do it?

Concretely, Emerald Onion will work to bring at least 10 new, independent, Privacy-focused ISPs into existence within the next 12 months. We will also speak in conferences, and use our existing communication pathways to advertise and publish our work. We will work to find other supporters and help them establish their own organizations. In addition, we will work to make shared support networks, like legal funds, peering databases, and abuse systems to be more accessible to these community groups.

Specifically, we will focus on the following areas of capacity:

  1. Funding and organizational stability strategies
  2. Nonprofit ISP incorporation setup and management
  3. Data center co-location setup and management
  4. ARIN registration and AS and IP scope management
  5. IP transit setup and management
  6. BGP setup and management
  7. Peering agreement setup and management
  8. Legal response setup and management

To stabilize ourselves as a focal point of the Seattle privacy community, Emerald Onion will continue to develop both its own sustainability model, and its infrastructure.

We expect to receive 501c3 status by the end of the year, and have already begun soliciting donations for our general operations. We have had initial success in approaching local members of the community to contribute the funds for one relay worth of cost in exchange for “naming rights” of that node. We believe direct community contributions can provide sustainability, and will complement this income stream with grant funding for growth.

We will also continue to increase our network presence to improve our fault tolerance and gain access to more network peers. Higher capacity will allow us to provide incubation for a larger range of privacy enhancing technologies.

Who is it for?

Emerald Onion is not just for the ~60 million monthly Tor users or the Seattle privacy community. We are not just a testing ground for encountering and solving operational issues in the deployment of privacy technologies. Emerald Onion is strategically developing as a model steward of privacy networks that is focused on quality and integrity. Our actions and relationships further legitimize Tor within communities that operate the backbones of the Internet and will help normalize the use of Tor for business-driven service providers.  We will continue to be an inspiration for community groups and other ethically-conscious ISPs alike.

Emerald Onion’s day-to-day work at present focuses on existing and new Tor router operators, who with the organizations that they create will immediately impact public perception. In Emerald Onion’s short existence, we have made direct, personal connections with at least 50 professional network administrators, datacenter operators, and Internet service providers. Imagine that happening in every major IXP community around the United States.

Emerald Onion has paid for professional legal services, and has already published our verified Legal FAQ and abuse complaint responses that are valid within the United States. Similarly, the organization is working with Academics to better understand the operational reality of abuse complaints, and to understand opportunities for making use of the IP space. These services benefit the larger privacy community both operationally, and as an incubator for projects.

What is the existing community?

The Tor relay community is already strong, but lacks strong US-based advocacy for growth. In Europe, TorServers.net has evolved into a grant-giving organization, which is able to provide advice and financial support to help new relays get started, but is not well positioned to support US-based relays. In Canada, Coldhak runs a valuable relay, but has not attempted to export its knowledge to external entities.

In the US, the largest relay presences come from Riseup.net and Calyx networks. Riseup is focused on services like email and VPNs in tandem with important education. This is valuable work, but does not extend to directly advocating for new groups to enter the ISP space. Calyx is supported through a cellular ISP model focusing on end-users but does not focus on supporting new relay operators.

Emerald Onion aims to fill this gap through direct advocacy to guide and support new relay operators and encourage the existence and creation of privacy supporting entities in a diverse set of IXPs around the country.

Complementary Efforts?

The Tor Project itself provides a basic level of support for new entities, particularly with technical support. In addition to a wide-reaching and engaging community, the presence of the Tor-relays mailing list provides a valuable community-wide support network between operators. The EFF has been a long-time supporter of the legal aspects of relay operation, and has helped with several legal papers supporting helping to establish the legal protections of Tor exit operation, along with providing counsel when new legal issues arise. It remains the case that new entities establishing Tor exit nodes in the US face thousands of dollars of legal fees to properly prepare themselves with the needed form letters for abuse and a tricky navigation of legal guidelines to establish themselves as legal entities with the authority to respond to complaints without fear of retribution.

Emerald Onion hopes to fill these gaps by making it easier for others by defining clear direction, freely published in the public domain, so that new operators don’t need to duplicate work that we’ve already performed. Building a shared legal defense fund and sharing how to navigate data center costs and contracts will allow groups to form with much less risk or uncertainty.

Why is it needed?

In building Emerald Onion so far, we have already found that many of the steps we are taking are undocumented, or rely on verbally communicated lore. That situation is not sustainable, and cannot scale or significantly improve the current state of the world.

More organizations are needed that focus on Internet privacy the same way hackerspaces have focused on hardware and technical development. Internet issues are inherently rooted in being part of the Internet and that barrier has so far been a high hurdle for community groups. We believe that this hurdle needs to be lower.

Without active development of these entities, we will continue to see even more centralization of the Internet and continued erosion of neutrality. Retaining a community presence in Internet operations is a key underlying infrastructure that we strongly believe has the potential to change the future development of the Internet.

 

Tor on HardenedBSD

In this post, we’ll detail how we set up Tor on HardenedBSD. We’ll use HardenedBSD 11-STABLE, which ships with LibreSSL as the default crypto library in base and in ports. The vast majority of Tor infrastructure nodes run Linux and OpenSSL. Emerald Onion believes running HardenedBSD will help improve the diversity and resiliency of the Tor network. Additionally, running HardenedBSD gives us peace of mind due to its expertly crafted, robust, and scalable exploit mitigations. Together, Emerald Onion and HardenedBSD are working towards a safer and more secure Tor network.

This article should be considered a living document. We’ll keep it up-to-date as HardenedBSD and Emerald Onion evolve.

Initial Steps

Downloading and installing HardenedBSD 11-STABLE is simple. Navigate to the latest build and download the installation media that suits your needs. The memstick image is suited for USB flash drives. Boot the installation media.

Installing HardenedBSD is simple. Follow the prompts. Sample screenshots are provided below:

  1. Select Install:
  2. Select your keymap. If you use a standard US English keyboard, the default is fine:
  3. Choose a hostname:
  4. Select the distribution sets to install:
  5. Choose your filesystem. For purposes of this article, we’ll use ZFS for full-disk encryption:
  6. Selecting the Pool Type will allow you to configure your ZFS pool the way you want. We will just use a single disk in this article:
  7. Since we’re using a single disk, we’ll select the Stripe option:
  8. Select the disks to use in the pool. Only a single disk for us:
  9. After selecting the disks, you’ll go back to the original ZFS setup menu. We’ve made a few changes (Encrypt Disks, Swap Size, Encrypt Swap):
  10. Review the changes:
  11. Set the password on your encrypted ZFS pool:
  12. Validate the password:
  13. Encrypted ZFS will initialize itself:
  14. HardenedBSD will now install distribution sets:
  15. Set the root password:
  16. If you want to set up networking, select the network device to configure. In this article, we’ll set up a dynamic (DHCP) network configuration:
  17. We want to use IPv4:
  18. We want to use DHCP:
  19. It will try to acquire a DHCP lease:
  20. At Emerald Onion, we put IPv6 first. However, in this example article, we won’t use IPv6 as it’s not currently available. So we’ll choose no when prompted to set up IPv6:
  21. Ensure the DNS information is correct and make any changes if needed:
  22. It’s now time to choose the system timezone. Select the region:
  23. We chose America. We’ll choose United States for the country next:
  24. Finally we’ll chose the actual timezone:
  25. Confirm the timezone:
  26. Because we use NTP, we’ll skip setting the date:
  27. We’ll also skip setting the time:
  28. Select the services to start at boot:
  29. Select the system hardening options. HardenedBSD sets options one through five by default, so there’s no need to set them here.
  30. We will go ahead and add an unprivileged user. Make sure to add the user to the “wheel” group for access to use the su program:
  31. Set the user’s details:
  32. HardenedBSD is now installed! Exit the installer. The installer will do things in the background so there may be some delay between exiting and the next prompt:
  33. We don’t want to make further modifications to the installation prior to rebooting:
  34. Go ahead and reboot:

The installation is now complete!

Installing Tor

Installing Tor is simple, too. Once HardenedBSD is installed and you’ve logged in, run the following command:

# pkg install tor

The Tor package on HardenedBSD, and its upstream FreeBSD, currently does not ship with a modified Tor configuration file, which can be found at /usr/local/etc/tor/torrc. Tor isn’t set up to log outside of initial startup messages. You will need to edit the Tor configuration file to suit your needs. Take a look at the tor(1) manpage for all the available configuration options.

In our set up, Tor listens on TCP ports 80 and 443 as an unprivileged user. We need to tell HardenedBSD to allow non-root users to be able to bind to ports that traditionally require root privileges:

# echo 'net.inet.ip.portrange.reservedhigh=0' >> /etc/sysctl.conf
# service sysctl start

Multi-Instance Tor

At Emerald Onion, we run multiple instances of Tor on the same server. This allows us to scale Tor to our needs. The following instructions detail how to set up multi-instance Tor. The same instructions can be used for single-instance Tor.

We named our instances simple names: instance-01, instance-02, instance-03, and so on. Each instance has its own configuration file, located at /usr/local/etc/tor/torrc@${instance_name}. We first set up a template config file:

Nickname EmeraldOnion%%INSTANCE%%
Address tor01.emeraldonion.org
ContactInfo abuse_at_emeraldonion_dot_org
Log notice file /var/log/tor/instance-%%INSTANCE%%/notices.log
OutboundBindAddressExit %%IP4ADDR%%
OutboundBindAddressOR %%IP4ADDR%%
DirPort %%IP4ADDR%%:80
ORPort %%IP4ADDR%%:443
ORPort %%IP6ADDR%%:443
RelayBandwidthRate 24 MBytes
RelayBandwidthBurst 125 MBytes
MyFamily %%FAMILY%%
IPv6Exit 1
ExitPolicy accept *:*
ExitPolicy accept6 *:*
SocksPort 0

The next script installs the appropriate config file based on the above template. Some things are sanitized. Shawn, who wrote the script, is a fan of zsh.

#!/usr/local/bin/zsh

ninstances=5

family=""

for ((i=1; i <= ${ninstances}; i++)); do
	instance=$(printf '%02d' ${i})

	family=""
	for ((k=1; k <= ${ninstances}; k++)); do
		[ ${k} -eq ${i} ] && continue
		[ ${#family} -gt 0 ] && family="${family},"
		family="${family}EmeraldOnion$(printf '%02d' ${k})"
	done

	sed -e "s/%%INSTANCE%%/${instance}/g" \
		-e "s/%%IP4ADDR%%/192.168.1.$((${i} + 10))/g" \
		-e "s/%%IP6ADDR%%/\[fe80::$((${i} + 10))\]/g" \
		-e "s/%%FAMILY%%/${family}/g" \
		tmpl.config > /usr/local/etc/tor/torrc@instance-${instance}
	mkdir -p /var/log/tor/instance-${instance}
	chown _tor:_tor /var/log/instance-${instance}
	chmod 700 /var/log/instance-${instance}
done

We then instructed the Tor rc script not to run the default instance of Tor:

# sysrc tor_disable_default_instance=YES

Then we tell the rc system which Tor instances we want to run and set Tor to start at boot:

# sysrc tor_instances="instance-01 instance-02 instance-03 instance-04 instance-05"
# sysrc tor_enable=YES

Then we start Tor. The first time the Tor rc script starts Tor, it will create the data and logging directories for you with the proper permissions.

# service tor start

Keeping HardenedBSD and Tor Up-To-Date

Updating HardenedBSD is simple with hbsd-update. We publish updates for base periodically. Feel free to use hbsd-update as often as you’d like to check for updates to the base operating system.

For example:

# hbsd-update
# shutdown -r now

To update your packages, including Tor, use:

# pkg upgrade

Tor Service Management Basics

The tor rc script uses SIGINT when shutting Tor down. This causes Tor to shutdown in an ungraceful manner, immediately halting connections from clients. Instead of using the traditional service tor stop command, directly issue SIGTERM to the instance you wish to stop.

# service tor status instance-01
tor is running as pid 70918.
# kill -SIGTERM 70918

If you’d like to stop all instances in a graceful way at the same time:

# killall -SIGTERM tor

In a multi-instance setup, you can tell the service command which instance you want to control by appending the instance name (the portion after the @ symbol of the torrc file) at the end of the command. For example, to reload the config file for instance-01, issue the following command:

# service tor reload instance-01

If you want to reload the config file for all instances, simply remove the instance name from the above command. The rc script will issue the reload command across all instances.

If you’d like to look at an instance’s log file, you can use the tail command:

# tail -f /var/log/tor/instance-01/notices.log

Future Work

In the future, we would like to further harden our Tor setup by having each instance deployed in its own HardenedBSD jail. Once that is complete, we will document and publish the steps we took.

Legal Responses to Tor Abuse Complaints

Disclaimer: This is not legal advice due to the fact that Emerald Onion is not your lawyer. Further, it is based on laws and court cases in the United States and does not apply to most of the world. If you are planning on becoming an ISP dedicated to transiting Tor traffic, please seek out and maintain active support from your own lawyer.

One of Emerald Onion’s priorities when establishing was to work with professional legal services for specific language when communicating with other organizations negatively impacted by the anonymous Tor traffic that we transit. Another priority is to freely share our work, to help others who take on the cause.

If you value our not-for-profit work, like the information shared here, please keep in mind that we graciously accept donations.

There are three documents that we use for addressing Tor abuse complaints. The first one has been published on our site for over a month, our Legal FAQ. We use this document whenever someone contacts us about any issue that is not a DMCA issue, so it is used a lot. Keep in mind that Emerald Onion only operates full (not reduced) exit relays, so we get lots of infringement related complaints.

The two other documents (below) should be used based on where an abuse complaint is coming from. Most Tor operators are used to working with their upstream ISP directly. This is because these operators lease IP space from their upstream ISP. In this case, it is important to use the “Complaint Forwarded By Your ISP(s)”.

The other way that abuse complaints can come in is directly from third-parties, typically the ones who have recorded your IP address(es) as being the cause of perceived abuse. Emerald Onion went through the process of obtaining our own Autonomous System (AS) number, IPv6 and IPv4 scopes, and because of this, we receive all abuse complaints directly. Third-parties at the other end of the anonymous Tor traffic that we transit only see our contact information in the WHOIS for our IP space, and not the contact information of our upstream providers.

We encourage other Tor operators to replicate our work so that they can directly manage all abuse complaints. Doing so removes a tremendous amount of legal stress from upstream providers. When this is applicable to you, use the “Direct Complaint” document below.

Please also thank EFF and The Tor Project for their prior work in this area.

Complaint Forwarded By Your ISP(s)

I am writing on behalf of [Your Organization] in response to the notice copyright below.

[Your Organization] is a [Your State] State-based nonprofit corporation and encrypted transit internet service provider. I would like to assure you that [Your Organization] is neither infringing copyrights nor hosting the claimed infringing materials on behalf of users. The notice is likely based upon misunderstandings about the law and about some of the software we run.

As an initial matter, the faulty copyright notice was triggered by a routing program that we are running on our servers called Tor. The Tor network is a group of volunteer-operated routers on the Internet that helps people enhance their security, privacy, and safety. [Your Organization] only runs Tor traffic through our routers.

Tor bounces communications through routers on the network before sending those packets on to their final destinations. However, Tor tunnels the connections so that no router can learn both the source and destination of the packets, which protects users from nefarious snooping on network traffic. The result is that the final IP address that the recipient receives is not the IP address of the sender.

Tor is valuable because it promotes privacy and free expression around the world. It also protects users against hazards such as harassment, spam, identity theft, price discrimination, and even dissident surveillance by oppressive governments. To learn more about Tor, see https://www.torproject.org/.

[Your Organization] operates Tor exit routers with connectivity to the [Your Internet Exchange Point(s)]. Those routers are only a conduit of online traffic. We are thus protected by the Digital Millennium Copyright Act safe harbor provision of 512(a). That safe harbor also likely protects you, as our ISP, from liability arising from this complaint.

The DMCA creates four “safe harbors” that protect service providers from copyright liability for the acts of their users, provided that the ISPs fulfill certain requirements. 17 U.S.C. § 512. The DMCA’s requirements vary depending on the ISP’s role. You may be familiar with the “notice and takedown” provisions of section 512(c) of the DMCA, which applies to ISPs hosting content on behalf of users. However, those requirements do not apply when an ISP merely serves as a “conduit,” i.e., transmits, routes, or provides for connections through a system or network. The safe harbor of section 512(a) has different and less burdensome eligibility requirements for conduits. See Recording Indus. Ass’n of Am., Inc. v. Verizon Internet Servs., Inc., 351 F.3d 1229 (D.C. Cir. 2003); In re Charter Commc’ns, Inc., Subpoena Enforcement Matter, 393 F.3d 771 (8th Cir. 2005).

Under section 512(a), service providers like you are typically protected from damages for copyright infringement claims if you also maintain “a policy that provides for termination in appropriate circumstances of subscribers and account holders of the service provider’s system or network who are repeat infringers.” If you have and implement such a policy, and you otherwise qualify for the safe harbor, you should be free from fear of copyright damages.

As an organization committed to protecting the privacy of its customers, I hope you’ll agree that Tor is a valuable technology and will continue to support our effort to strengthen the Tor network.

Thank you for working with me on this matter. As a loyal subscriber, I appreciate your notifying me of this issue and hope that the protections of DMCA 512 put any concerns you may have to rest. If not, please contact me with any further questions.

Sincerely,

[Your Name], on behalf of [Your Organization]

 

Direct Complaint

I am writing on behalf of [Your Organization] in response to the notice copyright below.

[Your Organization] is a [Your State] State-based nonprofit corporation and encrypted transit internet service provider. I would like to assure you that [Your Organization] is neither infringing copyrights nor hosting the claimed infringing materials on behalf of users. The notice is likely based upon misunderstandings about the law and about some of the software we run.

As an initial matter, the faulty copyright notice was triggered by a routing program that we are running on our servers called Tor. The Tor network is a group of volunteer-operated routers on the Internet that helps people enhance their security, privacy, and safety. [Your Organization] only runs Tor traffic through our routers.

Tor bounces communications through routers on the network before sending those packets on to their final destinations. However, Tor tunnels the connections so that no router can learn both the source and destination of the packets, which protects users from nefarious snooping on network traffic. The result is that the final IP address that the recipient receives is not the IP address of the sender.

Tor is valuable because it promotes privacy and free expression around the world. It also protects users against hazards such as harassment, spam, identity theft, price discrimination, and even dissident surveillance by oppressive governments. To learn more about Tor, see https://www.torproject.org/.

As you may know, the DMCA creates four “safe harbors” that protect service providers from copyright liability for the acts of their users, provided that the ISPs fulfill certain requirements. 17 U.S.C. § 512. The DMCA’s requirements vary depending on the ISP’s role. You may be familiar with the “notice and takedown” provisions of section 512(c) of the DMCA, which applies to ISPs hosting content on behalf of users. However, those requirements do not apply when an ISP merely serves as a “conduit,” i.e., transmits, routes, or provides for connections through a system or network. The safe harbor of section 512(a) has different and less burdensome eligibility requirements for conduits. See Recording Indus. Ass’n of Am., Inc. v. Verizon Internet Servs., Inc., 351 F.3d 1229 (D.C. Cir. 2003); In re Charter Commc’ns, Inc., Subpoena Enforcement Matter, 393 F.3d 771 (8th Cir. 2005).

[Your Organization] operates Tor exit routers with connectivity to the [Your Internet Exchange Point(s)]. Because [Your Organization] serves as a conduit of online traffic, we fall within the section 512(a) safe harbor, and are not subject to the requirements of section 512(c).

Thank you for working with me on this matter. I hope that the protections of DMCA 512 put any concerns you may have to rest. If not, please contact me with any further questions.

Sincerely,

[Your Name], on behalf of [Your Organization]

 

Internet Exchange Points in the United States

Emerald Onion is researching IXPs in the U.S.A. in order to identify areas of priority as it concerns increasing global Tor network capacity by way of putting Tor routers directly on these highly interconnected networks. Putting Tor exit routers in IXPs, for example, may reduce network latency to end points. It may also reduce network hops, potentially minimizing the possibility of third-party surveillance. Emerald Onion envisions a future where the Tor network is composed of much larger and more stable network operators, globally.

Questions

  1. Are there any Tor routers connected to any United States-based IXPs? If so, which ones and who operates them?
  2. Is this IXP friendly to Tor?
  3. What is the organizational structure of this IXP? Such as corporate-run or community-driven, etc.
  4. What qualities of an IXP should impact how meaningful it would be for the Tor network?
    • Number of participants?
    • Access to specific participants?
    • Nonprofit?
    • Community driven?
    • Affordability?
    • Geolocation?
    • Prohibits network surveillance?

A top 20 list of cities to focus on for Tor development?

  1. Chicago, IL has at least 12 IXPs
  2. New York City, NY has at least 9 IXPs (and has Calyx Institute)
  3. Dallas, TX has at least 6 IXPs
  4. Los Angeles, CA has at least 6 IXPs
  5. Miami, FL has at least 6 IXPs
  6. Seattle, WA has at least 5 IXPs (and has Riseup and Emerald Onion)
  7. San Jose, CA has at least 5 IXPs
  8. Phoenix, AZ has at least 5 IXPs
  9. Ashburn, VA has at least 3 IXPs
  10. Reston, VA has at least 3 IXPs
  11. Boston, MA has at least 3 IXPs
  12. Atlanta, GA has at least 3 IXPs
  13. Portland, OR has at least 3 IXPs
  14. Honolulu, HI has at least 2 IXPs
  15. Denver, CO has at least 2 IXPs
  16. Vienna, VA has at least 2 IXPs
  17. Palo Alto, CA has at least 1 IXP
  18. Salt Lake City, UT has at least 1 IXP (and has XMission)
  19. Minneapolis, MN has at least 1 IXP
  20. Detroit, MI has at least 1 IXP

IXPs in the United States

Ashburn, VA

    1. Equinix Ashburn Exchange (Equinix Ashburn)
    2. LINX Northern Virginia (LINX)
    3. MAE East

Ashland, VA

    1. Richmond Virginia Internet Exchange (RVA-IX)

Atlanta, GA

    1. Digital Realty / Telx Internet Exchange (TIE)
    2. Equinix Internet Exchange Atlanta (Equinix Atlanta)
    3. Southeast Network Access Point (SNAP)

Austin, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)

Billings, MT

    1. Yellowstone Regional Internet eXchange (YRIX)

Boston, MA

    1. Boston Internet Exchange
    2. Massachusetts eXchange Point (MXP)
    3. CoreSite – Any2 Boston

Buffalo, NY

    1. Buffalo Niagara International Internet Exchange (BNIIX)

Chicago, IL

    1. AMS-IX Chicago
    2. CyrusOne Internet Exchange (CyrusOne IX)
    3. Equinix Chicago Exchange (Equinix Chicago)
    4. Greater Chicago International Internet Exchange (GCIIX)
    5. United IX – Chicago (ChIX)
    6. CoreSite – Any2 Chicago
    7. MAE Central

Columbus, OH

    1. OhioIX

Dallas, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)
    2. DE-CIX, the Dallas Internet Exchange (DE-CIX Dallas)
    3. Digital Realty / Telx Internet Exchange (TIE)
    4. Equinix Dallas Exchange (Equinix Dallas)
    5. MAE Central
    6. Megaport MegaIX Dallas (MegaIX Dallas)

Denver, CO

    1. CoreSite – Any2 Denver
    2. Interconnection eXchange Denver (IX-Denver)

Detroit, MI

    1. Detroit Internet Exchange (DET-IX)

Duluth, NM

    1. Twin Ports Internet Exchange (TP-IX)

Gillette, WY

    1. BigHorn Fiber Internet Exchang (BFIX)

Hagåtña, Guam

    1. Guam Internet Exchange (GU-IX)

Honolulu, HI

    1. DRFortress Exchange (DRF IX)
    2. Hawaii Internet eXchange (HIX)

Houston, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)

Indianapolis, IN

    1. Midwest Internet Exchange (MidWest-IX – Indy)

Jacksonville, FL

    1. Jacksonville Internet Exchange (JXIX)

Kansas City, MO

    1. Kansas City Internet eXchange (KCIX)

Los Angeles, CA

    1. CENIC International Internet eXchange (CIIX)
    2. Equinix Los Angeles Exchange (Equinix Los Angeles)
    3. Los Angeles International Internet eXchange (LAIIX)
    4. MAE West
    5. Pacific Wave Exchange in Los Angeles and Seattle (PacificWave)
    6. CoreSite – Any2 California

Madison, WI

    1. Madison Internet Exchange (MadIX)

Manassas, VA

    1. LINX Northern Virginia (LINX)

Medford, OR

    1. Southern Oregon Access Exchange (SOAX)

Miami, FL

    1. Equinix Internet Exchange Miami (Equinix Miami)
    2. MAE East
    3. Miami Internet Exchange (MiamiIX)
    4. NAP of the Americas (NOTA)
    5. The South Florida Internet Exchange (FL-IX)
    6. CoreSite – Any2 Miami

Milwaukee, WI

    1. The Milwaukee IX (MKE-IX)

Minneapolis, MN

    1. Midwest Internet Cooperative Exchange (MICE)

Moffett Field, CA

    1. NGIX West

Nashville, TN

    1. Nashville Internet Exchange (NashIX)

New York, NY

    1. AMS-IX New York (AMS-IX NY)
    2. Big Apple Peering Exchange (BigApe)
    3. Digital Realty / Telx Internet Exchange (TIE)
    4. Equinix Internet Exchange New York (Equinix New York)
    5. Free NYIIX Alternative (NYCX)
    6. New York, NY – (CoreSite – Any2 New York)
    7. DE-CIX, the New York / New Jersey Internet Exchange (DE-CIX New York)
    8. New York International Internet eXchange (NYIIX)
    9. MAE East

Omaha, NE

    1. Omaha Internet Exchange (OmahaIX)

Palo Alto, CA

    1. Equinix Internet Exchange Palo Alto (Equinix Palo Alto)

Philadelphia, PA

    1. Philadelphia Internet Exchange (PHILAIX)

Phoenix, AZ

    1. Arizona Internet Exchange (AZIX)
    2. Digital Realty / Telx Internet Exchange (TIE)
    3. Phoenix Internet Exchange, LLC (PHX-IX)
    4. Phoenix IX
    5. CyrusOne Internet Exchange (CyrusOne IX)

Portland, OR

    1. Central Oregon Internet eXchange (COIX)
    2. Northwest Access Exchange, Inc. (NWAX)
    3. Oregon Internet Exchange (OIX)

Reno, NV

    1. Tahoe Internet Exchange (TahoeIX)

Reston, VA

    1. LINX Northern Virginia (LINX)
    2. MAE East
    3. CoreSite – Any2 NorthEast

Saint George, UT

    1. Southern Utah Peering Regional Network (SUPRnet)

Salt Lake City, UT

    1. Salt Lake Internet Exchange (SLIX)

San Antonio, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)

San Diego, CA

    1. San Diego NAP (SD-NAP)

San Francisco, CA

    1. San Francisco Internet Exchange (SFIX)
    2. San Francisco Metropolitan Internet Exchange (SFMIX)

San Jose, CA

    1. AMS-IX Bay Area (AMS-IX BA
    2. CoreSite – Any2 Northern California)
    3. Equinix San Jose / Bay Area Exchange (Equinix San Jose)
    4. NASA Ames Internet eXchange (AIX)
    5. MAE West

San Juan, Puerto Rico

    1. Internet Exchange of Puerto Rico (IX.PR)
    2. Puerto Rico Bridge Initiative (PRBI-IX)

Seattle, WA

    1. Megaport MegaIX Seattle (MegaIX Seattle)
    2. Pacific Wave Exchange in Los Angeles and Seattle (PacificWave)
    3. Seattle Internet Exchange (SIX)
    4. Seattle Internet Exchange (9000 MTU) (SIX Seattle (Jumbo))
    5. Seattle, WA Equinix Internet Exchange Seattle (Equinix Seattle)

Sterling, VA

    1. CyrusOne Internet Exchange (CyrusOne IX)

Tampa, FL

    1. Tampa Internet Exchange (TampaIX)
    2. Tampa Internet Exchange (TPAIX)

Tulsa, OK

    1. LiveAir Tulsa IX

Vienna, VA

  1. Equinix Internet Exchange Vienna, VA (Equinix Vienna (VA))
  2. MAE East