The United Nations recently set out the ETC 2020 strategy, asking for a remarkable change in how humanitarian communications will happen in future disasters and other humanitarian crises. The ETC 2020 strategy does something which I’ve previously advocated for, a focus on delivering communications not just to the humanitarian responder community, but directly to the population affected by a crisis. (Disclosure note: I was one of the contributors to ETC 2020). In our modern world, even remote populations depend on connectivity from a number of different media to be informed and engaged in their own humanitarian response. The term you’ll hear now within the UN humanitarian system is “Connecting with Communities” or CwC. CwC is a relatively broad term that refers to the focus on delivering communications to affected populations through all means: community broadcast radio all the way to providing wireless networks that disaster victims can use.
As emergency communicators, the scale and scope of the kind of communications we will have to deliver must change to meet this new expanded role and mandate. Simply put, the kind of networking that the ICT response community has typically deployed in the past will not easily scale to the much greater demands of supporting affected populations. We aren’t just providing communications to a few dozen to a few hundred humanitarian responders in an emergency. We’re now talking about providing connectivity to thousands to hundreds of thousands of affected individuals, while still retaining the ability to support humanitarian operations too.
The kinds of networks we will need to design and deploy will have to change.
The End of “Dumb Pipes”
Traditional humanitarian networks have relied upon what I am terming “dumb pipes” – relatively simple networks that were quickly able to be deployed and paired up with a VSAT or other form of backhaul to provide service. While such networks (sometimes built with consumer-grade gear) would work, they also lacked the cybersecurity, network optimization and network management capabilities essential for communications at scale.
Once deployed, these networks are often left in place for an extended period of time throughout the incident, and provide an undifferentiated level of network access to a small number humanitarian responders at a scene. But since these networks are often unmanaged, the overall health of the network is usually left unexamined – only when a user complains that she isn’t able to get to the Internet is a technical issue ever investigated. Malware-compromised hosts, or power users who might know what BitTorrent is are free to suck up a disproportionate amount of network bandwidth and displace legitimate mission traffic – because hey, aren’t all networks in disaster zones slow? *insert eyeroll here*
Defining the Next Generation of Humanitarian Networking
So given that the dumb pipe method doesn’t scale, doesn’t protect and doesn’t assure network quality, we have to start defining the capabilities of the next generation of humanitarian networking (hereafter NGN) that will ultimately realize the ETC 2020 vision. What does that look like?
Advanced Cybersecurity: Legacy networks may (at best) have a layer 3/4 stateful firewall between the users of the network and the Internet. But this is woefully inadequate for the threat environment that we face in 2016 and into the future. Humanitarian organizations that have the duty to support and protect affected populations must realize that that very same duty extends to the electronic realm as well — especially if they are providing humanitarian connectivity to that same group of people!
The cyberwarfare elements of current conflicts in Ukraine and Syria are well documented – and the targets of these campaigns often include humanitarian aid workers and vulnerable civilians. This intersection between information security and military conflict will only increase as the toolsets become more accessible and the attack surface of potential targets grows. This is because of the inexorable growth of smartphones and other devices even among the most vulnerable populations on the planet.
Networks supporting humanitarian workers and CwC in an NGN must embed the kind of cryptography and day-zero intrusion prevention that identifies and mitigates advanced attacks against a range of threats: from traditional phishing attacks to sophisticated malware created by a nation-state or combatant. This protection must be in the network, because the ability to enforce policy on any of the devices joining the network will be minimal to nonexistent.
This kind of capability must exist on every network regardless of whether the emergency is a conflict situation or natural disaster. After all, we saw nation-state malware attacks against humanitarians on the ground in Nepal after the 2015 earthquake!
Content Management: Are there types of Internet content that the humanitarian community should exclude from a CwC network? Some types of content are an easy choice to limit due to the amount of bandwidth they consume: YouTube and other streaming content, for example – especially on low-bandwidth links! Other types of content are also an easy choice based on security: blocking untrusted Android app stores where malware is known to reside, or confirmed spam sources. But what about blocking content based on other concerns? Adult content, access to militant websites, or sites related to human trafficking… the possible list is endless. NGNs will have to be able to block inappropriate content at a technical level, but this also requires the humanitarian technical community to determine a policy around content management. Blocking content is easy in any modern network, but often the human policy decision of what to block and when to block it is going to be the tougher problem.
Traffic Shaping and Quality of Service: Sometimes there is a need to allow traffic, but ensure that it doesn’t take up the entirety of available bandwidth. We often see this in disaster ICT soon after the emergency when responders first show up on the ground with their laptops and smartphones: as soon as these devices (which may have been offline for some time previously) get onto the network, they start pulling down operating system updates, anti-virus databases, fixes to Adobe Flash (aren’t there always?) and iPhones and Androids start syncing everything to the cloud. (Android is particularly chatty, by the way!) — all of this traffic is legitimate: we want people to have security fixes! But all of this activity can displace essential mission traffic, creating a defacto denial of service against the humanitarian network.
In an NGN, we should have the ability to provide a high quality of service to delay-sensitive traffic, such as VoIP – SIP, Skype, WhatsApp and other forms of realtime voice and video traffic. Additionally, we should be able to ensure that things like security updates and operating system downloads get a much lower level of priority to ensure that mission traffic is not displaced from the network.
Rate Limiting: Just like networks supporting a sporting event or other mass gathering, humanitarian NGNs will have to implement per-client rate limiting to ensure that the largest number of devices are able to get effective service from the network. Enforcing a rate cap of 100-200 kbps per mobile client device is enough to ensure that the user gets a network that “feels” fast for most applications, supports voice and video calling over Skype or WhatsApp, and yet prevents any one device from hogging up the entire network pipe. Devices that truly require higher data rates can be segmented onto another VLAN or SSID that is itself deconflicted from lower-priority traffic.
Network Management: As stated earlier, many existing networks supporting humanitarian response are essentially unmanaged once they are set up and in service. Logs are not monitored, errors that may make the network less effective are not dealt with until the point where human users start to complain. In essence, humanitarian ICT teams have used their own users as the “tripwire” that something is wrong with the network.
In an NGN this should never be the case. Even for reasons of good customer service, if nothing else, the network should be instrumented and actively monitored for problems. Minor problems must be identified and resolved before they cause major headaches for users. The IT team supporting the network should be the first to know if there is an outage, not the last.
This Can Happen Today. It Already Has.
These five essential capabilities must comprise the core bedrock of humanitarian networks now and into the future. On our team, we have already made this a part of how we operate. Starting with Cyclone Pam in Vanuatu, the response to the Nepal earthquake and most recently our work in Europe on the Syrian refugee crisis we have deployed networks that have all five of these capabilities designed in from the very beginning. All of this without busting the budgets or limited number of network engineers available to humanitarian aid organizations, and yet being able to scale to an extremely large number of users.
The ambition and scope of ETC 2020 will require an evolution in how we provide Internet connectivity in the midst of disaster and humanitarian crisis. The core capabilities I’ve described are common capabilities in solutions from many vendors at practical price points. With the right engineering, there is no reason why the CwC vision of providing connectivity to massive numbers of affected people shouldn’t be a reality.