Ouroboros

Summary

Ouroboros (abbreviated as O7s) is a prototype packet-switching technology, aimed at substantially simplifying packet networks. It is based on a redesign of the Internet 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 for injecting packets.

Initially, a lot of the information on this website will probably sound like gibberish and gobbledygook, especially if configuring VLANs, defining IP subnets and configuring BGP routers are your daily bread and butter. It requires a bit of effort to plow through the concepts of flow allocation and binding / registering names but when the penny drops, understanding O7s could prove very rewarding.

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.

A lot of this configuration is mostly static and done manually, once the service is in place, everything needs to be painstakingly documented because the configuration can be very brittle: introducing small changes can inadvertently bring the 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 in the media.

The configuration is also spread out as IP addresses and ports need to be consistent between different devices (application servers, DHCP and DNS servers, NAT firewalls, application client hardware). The configuration files for networked applications often have different formats. 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 not very scalable or portable. The IP network topology is defined by manual subnet assignments, and IP addresses often double as server identifiers in the minds of network admins. If an IP subnet has been over- or under-dimensioned, changing it can cause the need for redesigning many parts of the network. More than often, design compromises are made leaving as much of the network as-is because changing it would take weeks and involve downtime for many critical services. 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.

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) has become a decades-long slog. 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). A change in one of the layers permeates all the way through the network stack. To make things worse, standardization and research bodies have been defined based along the demarcation lines in the 5-Layer Internet model. Conway's Law prevents any significant architectural or structural innovations from taking root. Too many in the community continue to confuse familiarity with simplicity and happily label hacks and workarounds as solutions.

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 a nutshell, our objectives are to simplify and reduce configuration and prevent ossification.

Ouroboros characteristics

O7s has no well-known ports:

• ephemeral endpoint identifiers 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 (vulnerable) applications

The flow allocator is a single point of contact:

• endpoint identifiers assigned when a flow is allocated
• sets and stores peer information (remote address and endpoint identifier) at the start of communication, so
  • no need for source address and source 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
• authentication/encryption before first application byte

The application library and IRMd work together to create a single point of configuration:

• Instead of having network configuration per application, single network configuration file per system
• All O7s applications in the system inherit the network capabilities of the installed O7s version.

What to expect from this right now

In its current state, the prototype can demonstrate the validity and potential of the network model. It is far from a production piece of software, but rather a proof-of-concept that you can toy around with.