Ouroboros

 This page is under construction  

Summary

Ouroboros is a (work-in-progress) prototype packet-switching technology, aimed at substantially simplifying networking. It is based on a redesign of the current packet networking model – from the programming API almost to the wire. If we had to describe Ouroboros in a single sentence, it could be micro-services architecture applied to the network itself.

From an end-user application perspective, an Ouroboros network is a black box with a simple application programming interface to request communication services. Ouroboros can provision unicast flows - (bidirectional) channels that deliver message streams or byte streams with some requested operational (QoS) parameters such as maximum delay and bandwidth, protection against packet loss and authentication of peers and encryption of in-flight data; or it can provide broadcast flows to sets of processes.

From an administrative perspective, an Ouroboros network is a collection of daemons that can be thought of as software routers (unicast) or software hubs (broadcast) that can be connected to each other; again through a simple management API.

The prototype is not directly compatible with TCP/IP (it uses different protocols) or POSIX sockets (it has a different API), but it has interfaces and tools to run over Ethernet or UDP, or to create IP/Ethernet tunnels over Ouroboros by exposing tap or tun devices.

Objectives

Setting up a service over TCP/IP usually involves many different technologies. By the time the service is up and running, it will likely have involved configuring (switchport-based and trunk) VLANs, enabling some Spanning Tree Protocol variant in parts of the network, setting up link aggregation between ports on stacked switches, defining IP subnetworks, configuring a DHCP server to assign addresses to the subnets, setting up gateways, DNS servers, possibly configuring OSPF, IS-IS or iBGP/eBGP, selecting TCP and UDP ports for the applications, configuring reverse proxies, setting firewall and Network Address Translation (NAT) rules, adding some servers to a demilitarized zone, configuring a Virtual Private Network server, establishing a few SSH tunnels here and there... the list is almost endless.

To make things worse, a lot of this configuration is mostly static and done manually. Once the service is in place, everything needs to be painstakingly documented.

A networked service configuration is very brittle , introducing even small errors can bring the whole service down, and tracking down bugs, configuration errors or faults can take hours or even days. News stories about some DNS or BGP misconfiguration taking down a global service pop up regularly.

The configuration is also literally everywhere. The application IP addresses and ports need to be set in a configuration file for each server application, and needs to be consistent between different devices (DHCP and DNS servers, NAT firewalls, clients). Storing, maintaining and automating network and service configuration has become so elaborate and daunting that it has its own buzzword: infrastructure as code.

The service configuration is also not very scalable or portable, if an IP subnet has been over- or under-dimensioned, changing it can cause the need for redesigning and reconfiguring many parts of the network. Moving infrastructure within or between datacenters or reintegrating it in a different parts can cause many headaches, some can be mitigated using virtualization, but the configuration of virtual machines and containers is still much more complicated than necessary.

IP addresses function as server identifiers in the minds of network admins.

The Internet model is also rife with internal contradictions and inconsistencies. Examples abound of protocols that are jammed into the model without fitting - if IP is L3, how is ICMP also L3 as it runs on top of IP, in the same logical location as TCP which is L4?

Core Internet technology itself has become ossified; the core protocols haven't changed much in 30 years because making changes that are easy in theory, such as adding a new L3 protocol (IPv6) have become a decades-long slog. A change in one layer permeates into other layers. There are many layer violations creating unnecessary and unwanted ties between different layers in the model: L2 (Ethertype), L3 (protocol field), L4 (well-known ports) and L5 (struct sockaddr_in/_in6). To make things worse, standardization and research bodies have been defined based on the demarcation lines in the 5-Layer Internet model. Conway's Law ensures that the community will continue to confuse familiarity with simplicity and happily mistake hacks and workarounds for solutions, preventing any significant architectural or structural innovations from taking root.

In a nutshell, our objectives are to simplify and reduce configuration, reduce protocol attack surface, prevent ossification and unlock fast innovation, and make networks more robust against cyberthreats.

Reduce protocol attack surface

O7s has no well-known ports, but instead uses an ephemeral endpoint identifier defined at the model's network end-to-end layer that is randomly assigned at runtime. This implies:

• No direct tie between the network protocols and certain application, and thus no need to 'standardize' certain values for certain identifiers (Ethertype/protocol/port).
• No need to define and/or de-conflict port values when setting up networked applications
• No need to keep track of used 'port' values while designing network applications
• No hacks such as port-scanning a server for applications

In addition, O7s sets and stores peer information (remote address and endpoint identifier) at the start of communication (flow allocation). This means

• No need for source address and endpoint in every packet
• Even if an attacker would find a valid address/port, fabricated packets sent there will not result in any knowledge gained by the attacker as return traffic is sent to the stored peer, not the attacker.
• No smurf/amplification attacks leveraging faked source addresses

O7s discourages manual addressing, and addresses are never leaked outside of the network forwarding layer.

Single point of contact: Flow allocator - authentication/security before first application byte

Robust configuration

abstraction - management API

Single point of configuration: Instead of having network configuration per application, single network configuration file per system.

Prevent ossification

HTTP has taken over the role of 'narrow waist' anymore from IP, reverse proxy has become the service endpoint. The protocol stack up to TCP/UDP port 443 is becoming more and more ossified.

Fast Bootstrap

Kick nodes from network , hot-swap entire networks.