Originally published in Air Force Space Command’s High Frontier Journal

The inventor of the Internet (Advanced Research Projects Agency Network [ARPANet]), and more specifically the co-creator of transmission control protocol/Internet protocol (TCP/IP), Vint Cerf has ventured into the world of wiring up space, what has been dubbed the “Interplanetary Internet” (IPN). In doing this, Cerf and his team have created a new protocol, disruption-tolerant networking (DTN), capable of dealing with the delays and disruptions of space communications. Cerf and others took this as an opportunity to solve some of the inherent security problems of TCP/IP and the fundamentals of today’s Internet. Moreover, it just so happens that when you engineer your core network technology to inherently deal with disruptions, there are enormous security benefits. This article will discuss the cyberspace security lessons learned from the space-based DTN experience. And, it will also discuss the potential for and benefits of replacing TCP/IP with DTN as the core protocol powering the Internet of the future—interplanetary or not.

Background

In 1998, after 25 years of the Internet’s evolution, Vint Cerf began envisioning the Internet in 2025. Realizing that the Internet had come to span the planet Earth, Cerf took on the challenge of networking the solar system. This challenge had its root in the flurry of manned and robotic space exploration that the National Aeronautics and Space Administration (NASA) and others had planned and underway. Cerf knew that TCP/IP was simply not designed to deal with the delays and disruptions inherent in networking in space. So naturally, Cerf in concert with team members from NASA’s Jet Propulsion Laboratory, Goddard Space Flight Center, the Mitre Corporation, and Intel Research, Cerf began inventing a protocol that would enable complex space missions—DTN.

As the co-creator of TCP/IP during the original ARPANet project, Cerf had experience the nascent days of the Internet when their hub at the University of California, Los Angeles was connected only to a handful of other nodes. Notably, this sparse network diagram closely resembled the IPN experiments that Cerf and his team later initiated. The experiment simply involved uploading the new DTN protocol software onto a few spaceborne platforms and conducting some dial tone experiments.

DTN, like the original TCP/IP was relatively simple to demonstrate. But, this ease belied the enormous amount of security that was built into DTN which TCP/IP never enjoyed. The driving motivation of all this security work was the avoidance of a future headline such as “15-Year-Old Takes Over MarsNet.” DTN has many TCP/IP security lessons learned embodied in its implementation. As national security decision-makers decide on how to staunch the information bleeding, or perhaps more aptly the hemorrhaging that currently characterizes the current cyber-threat environment, an analysis of DTN is clearly in order.

Lessons from Space Communications

When Cerf and his team embarked on their quest to achieve an IPN, it quickly became clear that the brittleness of TCP/IP would simply not do. When speaking at the Open Mobile Summit in San Francisco in 2009, Cerf summed up the network communications challenge posed by space:

There was a little problem called the speed of light. When Earth and Mars are closest, we’re 35 million miles apart, and it’s a three and a half minute trip one way, seven minutes for a round trip. Then when we’re farthest apart, we’re 235 million miles—20 minutes one way, 40 minutes round trip. Just try using TCP/IP for a 40 minute round trip.… [Moreover] The planets rotate, and we haven’t figured out how to stop that.… It’s a very disruptive system, and it’s potentially a variably delayed system, because these planets are moving further apart based on our orbits.1

The example of communications between Earth and Mars is illustrative. But, similar delays and disruptions can occur with much shorter distances. Satellite to satellite communication links are orders of magnitude shorter, but yet pose similar patterns of disruption and delay, as has been shown in NASA experiments.2

The continuous connection that TCP/IP assumes would fundamentally never exist in a space scenario. When using TCP/IP, a lost connection means that most applications simply will cease working. At the most basic level, DTN was designed address this challenge of delay/disruption by simply hanging onto packets until they can be safely transmitted.

Achieving Mission Success Despite Disruption

If we have learned anything with modern networking (and networked) technologies, delay and disruption are hardly unexpected. Whether traversing space, the Internet, or mobile networks, the common denominator of all missions is that they must “fight through” disruptions. In the world of satellite to satellite communication, or interplanetary communications, disruptions due to solar flares, orbital dynamics, or any number of other mitigating circumstances cannot be allowed to compromise a mission. At the tactical edge of a military network, disruptions due to power outages, broken physical links, radio frequency jamming, and more cannot be allowed to compromise a mission. Dependent on commercial cellular infrastructure, first responders must be able to conduct their mission, despite the crush of calls during a catastrophe that make cellular service intermittent.

And, in the realm of cyber-security threats, missions need to “fight through” network penetration with core network infrastructure that is capable of preventing the exfiltration and modification of data, as well as the denial of service. Running a mission, or simply conducting business, requires that users be able to access critical information available over the network without being denied by their adversaries. Even under attack by a sophisticated, internal adversary, operators need to have access to critical information, and know that it will not be disclosed.

The key DTN feature that enables mission success is that unlike TCP/IP, it does not discard data in times of disruption. It implements a “store and forward” model which is different from the way IP multi-casting currently works.3 DTN provides secure, persistent storage for the data that traverses the network, until delivery is assured. This can be thought of as a DTN cache. The data can be marked with metadata that can be encrypted with different keys from the keys used to encrypt the payload data itself. In this way, DTN maintains the cryptographic integrity of the data in motion and at rest in these caches. And, to provide an extra measure of disruption tolerance, the DTN team has been adapting a convolutional/erasure algorithm scheme (the same sort of encoding associated with RAID devices) that allows data to be reconstituted despite the loss of up to 15 percent of the data traversing the network.

Hardening the Internet’s Core

In a TCP/IP environment, current cyber-security measures are commonly limited to protecting our organizations’ perimeters and perhaps encrypting our file systems, which just happen to be unlocked at boot. Data exfiltration, modification, and the denial of service are commonplace. And, our responses to network attacks that breach our perimeter are limited. In general, we must take compromised components offline, and curtail our mission-readiness.

If atop TCP/IP you used public key infrastructure and Internet protocol security and insisted on having all devices authenticate, then indeed you would materially improve your organization’s security. Assuming that you could trust all the certificates that this construct would rely on, it would harden the core of your network, rather than simply relying on your perimeter defenses. And, many organizations have done just that. But, that is a massive added expense, and a level of technical know-how that typically exceeds that possessed by average organizations.

DTN, at its core, was designed to bring this overlay of security measures into the core design of the network. And, it drew upon other mature techniques learned from other parts of the information and communications technology domain to build an IPN that would not be hijacked by 15-year-olds.

DTN leveraged encryption and structured fragmentation in order to protect against data exfiltration. It used signing and erasure coding to protect against data modification. It looked to diffusion-based replication strategies that protect network resources against denial of service. And, DTN used cache over-encryption in order to achieve dynamic access control. While one would need a forensic analysis of DTN’s security architecture in order to trust such an innovative approach to securing network traffic, it is clear that DTN represents an enormous leap in terms of the “built-in” security provided by the core network protocol. It is useful to perhaps dwell on each of these four DTN security features.

As a result of these technical security measures, DTN is able to provide a high level of assurance that missions will continue despite network compromise, and the disruptions and delays due to compromise. In the face of network compromise, DTN enables assured availability and confidentiality. DTN uses a diffusion-based replication strategy, that leverages an encrypted cache architecture, in order to move data to the right user, despite delay and disruption. DTN is designed to provide this level of availability and confidentiality despite network penetration by an adversary who can gain access to both client and data storage nodes, and even eavesdrop on network traffic.

A Critical Layer of Indirection

For those intimate with the inner working of today’s Internet, DTN is indeed somewhat unfamiliar. It does not follow many of the assumptions that drive today’s Internet.

[DTN uses] a flexible node addressing scheme in lieu of the traditional IP naming conventions. DTN architecture revolves around a data-centric model, not a network-centric model.… DTN uses a unique, new naming convention for routing the data bundles—not packets—throughout the network. Data is protected while at rest and can be stored along the network path to the destination if the network is not stable.4

DTN in some ways is more akin modern wireless telecommunications networks, where each device has an endpoint

identifier (EID) that specifies and uniquely identifies it as an endpoint connected to the network. The information about the location of a given endpoint on the network is given by a “locator” which may change as the network topology changes. In this framework, ongoing communication is not disrupted when a locator changes since endpoints are identified by their EIDs and not their locators.

In the worlds of telecommunications and mobile computing devices, it is not uncommon that a given end device will be connected to more than one IP address. As a user moves from cell tower zone to cell tower zone, it may touch the network (and even the Internet) in multiple places at the same time. To do this, such locators help to dynamically bind the routing layer and the physical endpoints. When you introduce such a layer of indirection, you have the benefit that the device no longer cares which network path(s) you are traversing. The device could simultaneously traverse multiple networks at the same time.

DTN is designed on just such principles. So, as the network topology is disrupted for any reason, communication does not cease. And, due to the caching strategy employed by DTN, data is not lost when a node drops out of the topology. Quite simply, the data finds other ways to make its way to its intended recipient, even if it takes a while.

Security Early and Often

TCP/IP was designed with little regard for security. It was designed to get messages through networks which were assumed to offer high availability. As a result, it is rife with security vulnerabilities because it does not enforce security measures early and often. DTN on the other hand promptly prevents unauthorized applications from having their data carried through or stored in the DTN. It prevents unauthorized applications from asserting control over the DTN infrastructure. It prevents otherwise authorized applications from sending bundles at a rate or class of service for which they lack permission. DTN promptly discards bundles that are damaged or improperly modified in transit, ensuring the highest level of integrity. And, DTN promptly detects and de-authorizes compromised entities.5

[DTNSEC] utilizes hop-by-hop and end-to-end authentication and integrity mechanisms. The purpose of using both approaches is to be able to handle access control for data forwarding and storage separately from application-layer data integrity. While the end-to-end mechanism provides authentication for a principal such as a user (of which there may be many), the hop-by-hop mechanism is intended to authenticate DTN nodes as legitimate transceivers of bundles to each-other. Note that it is conceivable to construct a DTN in which only a subset of the nodes participate in the security mechanisms, resulting in a secure DTN overlay existing atop an insecure DTN overlay. This idea is relatively new and is still being explored.

In accordance with the goals listed above, DTN nodes discard traffic as early as possible if authentication or access control checks fail. This approach meets the goals of removing unwanted traffic from being forwarded over specific high-value links, but also has the associated benefit of making denial-of-service attacks considerably harder to mount more generally, as compared with conventional Internet routers. However, the obvious cost for this capability is potentially larger computation and credential storage overhead required at DTN nodes.6

Adopting and Adapting

DTN is not just an idea. It has been implemented in an open source software stack that has been through the bureaucratic processes to determine that export restrictions should not prevent its distribution to other space-faring nations. The DTN protocol suite could easily be adopted by commercial infrastructure providers such as CISCO, Juniper, F5, Huawei, Alcatel-Lucent, and US Tellabs. Google, no doubt by virtue of Cerf’s employment, has already rolled DTN into its Android platform in order to take advantage of its ability to overcome the disruption and delay in mobile networks. Microsoft could, no doubt, roll out DTN in upcoming releases of Windows operating systems.

The Internet is continually adapting, with the term “Internet year”7 used as the provocation to every innovator to remind them how fast they must act, or else be overcome by events. It would only take a handful of Internet years to ensure DTN is ubiquitously available. Some public sponsorship would be required, akin to the Defense Advanced Research Projects Agency support currently being applied to the exploration of DTN’s battlefield benefits.8 But, the scale of resources that would be required to enable the adoption of and adaptation to DTN would inevitably be orders of magnitudes less than that required to secure a TCP/IP based Internet.

Ending Internet Hostilities

For a long time, popular culture has embraced the notion that the Internet is rather safe, in terms of cyber security. Even more sophisticated enterprise views of security have assumed that their perimeter security measures are keeping their operations safe and secure, in the face of possible cyber threats. It is high time, however, that we begin to understand that whatever cyber activities we engage in, we are engaging in them over a hostile Internet infrastructure. It is hostile in large part because TCP/IP as a protocol leaves users and enterprises wide open to panoply of attacks simply because of its original design. And, its vulnerabilities have become so well understood that random 15 year olds can wreak enormous amounts of havoc.

Unless the user or enterprise is very sophisticated in its security investments atop this insecure infrastructure, they will be utterly defenseless in the face of rising, organized Internet hostilities—whether posed by nefarious nation states, non-state actor networks, organized crime, or lone bad actors.

Many billions of dollars are currently being amassed and spent to address these hostilities. And, epic engineering efforts are currently being envisioned. In this context, it is not too much to ask that we evaluate the fundamental shortcomings of today’s Internet, and entertain a wholesale switch to a stronger and secure foundational protocol.

Acknowledgement:

While “Cerfing (Cyber)Space” suggests that Cerf alone is responsible for the future of the Interplanetary Internet, Cerf takes great pains to acknowledge the contributions of his colleagues Robert Durst, MITRE; Adrian Hooke, NASA; Scott Burleigh, JPL; Keith Scott, MITRE; Leigh Torgerson, JPL; Kevin Fall, Intel Research; David Israel, Goddard Space Flight Center; and Jay Wyatt, JPL.

*******

Citations are available in the original article here.