Ouroboros

 This page is under construction  

Summary

Ouroboros is a prototype packet-switched network. 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 would be micro-services architecture applied to the network itself.

From an application perspective, an Ouroboros network is a “black box” with a simple application programming interface to request communication services. Ouroboros can provision a unicast flow - a (bidirectional) channel that delivers messages or a byte-stream with some requested operational parameters such as maximum delay and bandwidth, protection against packet loss and authentication of peers and encryption of in-flight data; or it provides a broadcast flow to a set of joined programs.

From an administrative perspective, an Ouroboros network is a bunch 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.

While the prototype is not directly compatible with TCP/IP or POSIX sockets, 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

Robust configuration

Setting up a service over TCP/IP usually involves many different technologies, each with their own set of algorithms and idiosyncrasies. By the time the service is up and running, it will likely have involved configuring (port-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 subnets, 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 a reverse proxy, setting firewall rules and some Network Address Translation rules, a demilitarized zone, a Virtual Private Network server, some SSH tunnels here and there... the list is almost endless.

A lot of this configuration is done manualy. And in the end, only the person that has designed the network setup fully understands it.

The configuration is quite brittle , introducing a small error can bring down the whole service, and tracking down small configuration errors can take hours or days. News stories about some BGP or DNS misconfiguration taking down a global service pop up regularly.

The configuration is literally everywhere. The application IP addresses and ports need to be set in a configuration file for each application on each server, which needs to be consistent between different devices (servers, NAT firewalls, clients). Maintainging and automating network configuration has become so daunting that it has its own buzz terminology: infrastructure as code.

The configuration is also not portable, if an IP subnet has been over- or underdimensioned, changing it can cause the need for redesigning much larger parts of the (corporate) network. Moving infrastructure between datacenters or reintegrating an appliance can cause similar headaches.

Internet is resilient against attacks on infrastructure (hardware), but vulnerable to attacks from within on configuration.

O7s aims for:

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

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

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.