The Problem ZPR Solves

Internet Protocol was originally designed with the explicit assumption that security was not the network’s problem. Instead, security was left to the endpoints. This has proven to be more difficult than anticipated.

Once it was understood that it was not desirable for everything to be able to communicate with everything else, enterprises began to section off parts of their own networks by adding firewalls to block undesired communication. As firewall rules accumulated over time, the original purposes of specific rules were often forgotten. To complicate things further, enterprises must support remote users, host Internet-facing websites, connect distant offices, and benefit from cloud computing. These demands made configuration of perimeter security even more complex, by adding security mechanisms, such as virtual private networks (VPN), demilitarized zones (DMZ), and cloud-specific security frameworks.

The protections that emerged from the interaction of the accumulated firewall rules, cloud security frameworks, remote access mechanisms, evolving network topology and the ongoing attempts at endpoint security can be difficult to manage. Today, bad actors discover and exploit the misconfigurations and security flaws, leaving enterprises vulnerable to cyberattacks. Meanwhile, network managers are often forced to create and enforce security policies imposing costly operational constraints due to the lack of easily manageable controls on data.

An enterprise should be able to understand and control the communication policies of its computational infrastructure, independent of what networks it is operating on. These policies should be clearly described in one place, in a way that humans can easily understand and audit themeasily. It should be simple to prove that the intended policies will be enforced.

Zero-Trust Packet Routing (ZPR, pronounced zip’-er) is a proposal to accomplish these goals. ZPR provides a way to describe communications policies and a way to reliably enforce them within the network. Because policies are enforced by the network itself, they provide an additional layer of security that is independent of any existing protection provided by endpoints, VPNs, firewalls, or cloud-specific security frameworks.

Design Principles

ZPR is designed based on four paranoid design principles:

1. Every packet must have an authenticated sender and receiver.
2. The network itself must enforce communications policies continuously and throughout the network not just when packets enter and leave or when sessions are established. Every packet must be discarded unless it is explicitly allowed by a policy.
3. The users of the network, the devices that implement the network, and even the individuals who administer the network must not be trusted to always behave in any particular manner. It should be possible to implement the network so that policies will be enforced correctly, even if one of the network components becomes unreliable or compromised.
4. The network is configured and managed as a unified resource, through the network itself.
   

Disallowing out-of-band management and forcing all management to be policy compliant, helps a ZPRnet protect itself from accidental or deliberate misconfiguration. This also allows policy to be distributed and enforced in ZPRnets that cross multiple networks, including multiple clouds, customer premise networks, and the Internet.

ZPR Policy Specification and Enforcement

One of the biggest challenges with IP security is that the rules used to secure network traffic are highly technical and semantically distant from the security concepts at a business level. We designed ZPR’s policy language, ZPL, was designed to avoid this problem. It is:

• Easy to read and understand
• Easy to administer
• Easy to audit
• Hard to make mistakes
• Easy to catch mistakes

As simple example, a permission for users with an attribute named “role” that has value “customer-support” could be expressed like this:

Allow users with role customer-support access to resources with data-category customer-data.

Here is more complex example that puts a limit where the user is located, what networks they can use, and the amount of information that they can be transfer per day:

Allow users with role customer-support access to resources with data-category customer-data when located-in sales-support-facility, limited to 100 megabytes-per-day.

Because all senders and receivers are authenticated, ZPR has trusted identity information about who is communicating. ZPL policies are based on information about people, computers, services and devices that exist in the enterprise in directories and other trusted services. This allows ZPL to refer to roles, groups, tags, and other attributes of communicators to simplify policies and reduce the number of policies required.

When a packet is sent over a ZPRnet, the network checks to see if the packet belongs to a flow that was already approved by policy. If not, the network uses the attributes of the sender, receiver, and data itself to see if there is a policy entry that permits the specific communication. If so, the flow is permitted, otherwise a security violation is logged. When a flow is permitted, each hop in the network is informed so that the packet can be checked throughout the network.

Performance and Interoperability

Senders and receivers on a ZPRnet communicate using standard Internet protocol (IP) packets so no change is required to existing applications and operating systems. Within the ZPRnet, packets are transmitted as special ZPR packets that are optimized for security, performance, and ease of processing. ZPR packets are designed to be carried on any IP network.

We designed the format of ZPR packets to take advantage of the hardware acceleration capabilities found in modern routers and smart network interfaces. And given that today’s large enterprises have resources spread across multiple offices, private datacenters, and commercial clouds, ZPR enables a single ZPRnet to span all of these, and to make use of whatever underlying acceleration is available in each network. This enables participating organizations to optimize their networks for ZPR traffic without impacting ZPR interoperability.

Summary

Computer networks were originally designed to allow all devices to freely communicate. What modern organizations need for data security is networks that enable users and services to communicate only when they have permission to do so. The difference between these two is what makes network security such a difficult problem.

ZPR goes to the heart of the problem by providing a mechanism to establish clear communication policies and to enforce them in the network. ZPR brings identity and policy down to the level of network packets, adding a robust layer of network security that complements existing security mechanisms.

How ZPR works?