Hannes Mehnert

Is the way we run services these days sustainable? The trusted computing base -- the lines of code where, if a flaw is discovered, jeopardizes the security and integrity of the entire service -- is enormous. Using orchestration systems that contain millions of lines of code, and that execute shell code, does not decrease this. This talk will present an alternative, minimalist approach to secure network services - relying on OCaml, a programming language that guarantees memory safety - composing small libraries (open source, permissively licensed) to build so-called MirageOS unikernels -- special purpose services. Besides web services, other digital infrastructure such as VPN gateway, calendar server, DNS server and resolver, and a minimalistic orchestration system, will be presented. Each unikernel can either run as virtual machine (KVM, Xen, BHyve, virtio), as a sandboxed process (seccomp which whitelists only 8 system calls), or in smaller containments (GenodeOS, muen separation kernel) -- even a prototypical ESP32 backend is available.

Starting with an operating system from scratch is tough, lots of engineering hours have been put into the omnipresent ones. Reducing the required effort by declaring certain subsystems being out of scope -- e.g. hardware drivers, preemptive multitasking, multicore -- decreases the required person-power. The MirageOS project started as research project more than a decade ago at the University of Cambridge, as a minimal guest for Xen written in the functional programming language OCaml. Network protocols (TCP/IP, DHCP, TLS, DNS, ..), a branchable immutable store (similar and interoperable with git) are available. The trusted computing base is roughly two orders of magnitude smaller than contemporary operating systems. The performance is in the same ballpark as conventional systems. The boot time is measured in milliseconds instead of seconds. Not only the binary size of a unikernel image is much smaller, also the required resources are smaller: memory usage easily drops by a factor of 25, CPU usage drops by a factor of 10. More recently we focused on deployment: integration of logging, metrics (influx, grafana), an orchestration system (remote deployment via a TLS handshake, offers console access and an event log) for multi-tenant systems (policies are encoded in the certificate chain). We are developing, mostly thanks to public funding, various useful services: a CalDAV server storing its content in a remote git repository, an OpenVPN client and server, DNS resolver and server (storing zone files in a remote git repository) with let's encrypt integration, a firewall for QubesOS, image viewer mainly for QubesOS, ... The experience while developing such a huge project is that lots of components can be developed and tested by separate groups - and even used in a variety of different applications. The integration of the components is achieved in a type-safe way with module types in OCaml. This means that lots of errors are caught by the compiler, instead of at runtime.

Whenever you enter a name into your computer, it resolves it to a numerical IP address. This resolution uses the Domain Name System (DNS), which is a hierarchical decentralised naming system used on the Internet. DNS is organised in a way that top-level domain (e.g. .com, .org) are delegated to registrars, which delegate subdomains (e.g. foo.com). This delegation is done as well via the DNS protocol via nameserver (NS) records. Since different types of data are kept in DNS, it can as well be seen as a distributed (and cached!) key-value store - which is fault-tolerant. I will explain the basic usage of DNS, including stub and recursive resolver, server, various protocol extensions (zone transfer, dynamic updates, authentication, notifications, ...), privacy extensions (query path minimisation, DNS-over-TLS), provisioning let's encrypt certificates. I will talk about attacks (poisoning, amplification, ...) and implementation pitfalls (not get stuck in the recursive resolver). I implemented DNS with above mentioned extensions as minimized MirageOS unikernels over past years.

DNS is used since 1985 for the Internet, and provides useful service for various protocols. Its initial design could not foresee its wide usage 30 years later. DNS is a core dependency of today's Internet usage. Within the MirageOS project we re-develop network protocols, and I was eager to learn about all the details of DNS, a protocol which has been around and will be around for more time since a lot of systems depend on it.

TCP/IP is the most widely used protocol on the Internet for transmitting data. But how does it work in detail? This talk will explain the TCP protocol, from handshake over established to teardown in detail - and elaborate a bit on protocol adjustments over time and congestion control.

I will briefly explain how computers talk to each other via the Internet Protocol (IP), and explain the transport protocols UDP and TCP, and their interaction with ICMP (for error and control messages). UDP is the user datagram protocol, an unreliable packet-oriented protocol. TCP provides a reliable stream of data, and includes connection establishment, feature negotiation, window management, and teardown. Over the last years at University of Cambridge I contributed to a formal model of TCP/IP and the Unix sockets API, developed in HOL4. We validated our HOL4 model with the FreeBSD-12 stack using Dtrace (packets, system calls, internal TCP state). In this research, we formalised a more exact TCP state machine than in initial RFCs or common literature (Stevens).