Turkey's Twitter Shoot: Lessons Learned

In March, the nation of Turkey attempted to shut Twitter down within the country. There are several lessons network engineers should glean from Turkey’s efforts to shut down a single service, including lessons on resilience, indirection, and the interaction between Internet governance and the technology decisions engineers make when designing protocols and networks.

First -- because of resilience -- it’s become very difficult to turn off “one service” on the Internet. Turkey tried to shut down Twitter by blocking access to Twitter’s DNS records. Using DNS to block access to a service isn’t very effective, though; it’s easy enough to switch to a public DNS server, such as those run by Google, thus restoring any services rendered unreachable through this sort of blocking.

Let’s assume, though, that Turkey had decided to block the IP addresses of Twitter servers rather than the DNS records. Would this have worked? Probably not. Just about any service can be deployed across a number of different IP addresses, even changing IP addresses on a periodic basis to make it difficult to find and block each individual instance of the service. Putting the service behind a large-scale network address translator (NAT), would make it virtually impossible to block without blocking a large number of sites that are “innocent bystanders.”

Indirection such as NAT is often considered a very bad thing in network and protocol design and engineering. If we had a truly “transparent” Internet, where every person or service had to be identified before sending traffic, we’d certainly have a lot less spam. But without the indirections, Twitter service could not have been restored to people living in Turkey.

So the first lesson is this: To block any particular service, you almost have to block the entire Internet. IP networks are just too good at routing around blocked paths or dealing with mapping information being removed from one source. Resilience is a two-edged sword -- individual services are much more reliable, but they’re also much harder to block or otherwise shut down.

Second, this level of resilience comes with another sort of cost in terms of security. DNS servers are often used to reflect or amplify denial-of-service attacks specifically because of the resilience built into the DNS system as a whole. Are we potentially facing another version of the CAP theorem? Just as a database cannot be made to be consistent, available, and partitionable all at the same time, maybe network protocols cannot be resilient, reliable, and secure all at the same time.

Finally, while we sit outside Turkey, smugly condemning an attempt to block Twitter, "free speech zones" are becoming increasingly common in the US. Free speech isn’t just about technology. It’s also about accepting that you’re not going to agree with anyone all of the time -- and, in fact, you might just find what they say offensive. This is perhaps a little more of a personal lesson, but as engineers we need to realize that, while we can’t anticipate all the potential consequences of every decision we make, there is still some interaction between the technical world and the political one.

Engineering decisions have social outcomes as well as technical ones. It’s important to remain as neutral as possible, providing technology for a narrow set of requirements at hand, but it’s also important to get our heads out of the technology sandbox and try to come to terms with the real-world implications of what we’re building from time to time.