eBPF in IETF protocols
In 1992, Steven MacCanne and Van Jacobson proposed the BSD Packet Filter <https://www.tcpdump.org/papers/bpf-usenix93.pdf> as an efficient technique to implement flexible packet filters in the tcpdump packet capture tool. In a nutshell, BPF specifies a small instruction set which be used to write programs that are executed on the captured packets to determine which packets can be matched. BPF is the standard solution to build powerful packet filters in tcpdump and related tools.
Almost 25 years later, Alexei Starovoitov used a similar approach to design extended BPF (eBPF). eBPF is an extension of the original BPF instruction set which is supported by a virtual machine, a Just-In-Time compiler and a verifier inside the Linux kernel. With eBPF, it becomes possible to add executable bytecode inside the Linux kernel to tune its behavior without having to recompile the kernel or use modules. eBPF is now widely used inside the Linux kernel and there are many use cases.
eBPF has also been ported to Microsoft Windows. To encourage the adoption of eBPF in other use cases than the Linux kernel, the IETF has chartered the BPF/eBPF working group to specify the basic features of this technology, namely the eBPF Instruction Set, the expectations for the verifier, …
eBPF should not be limited to operating system kernels such as Linux and Windows. There are many other use cases where the extensibility of eBPF can be beneficial. The IETF spends a lot of efforts to maintain and slowly extend widely deployed protocols. In the last years, we have demonstrated that by leveraging eBPF inside protocol implementations, it is possible to make them much more flexible. Here are a few examples that illustrate the flexibility that eBPF can bring to IETF protocols.
A first example is IPv6 Segment Routing or SRv6. David Lebrun has implemented SRv6 in the Linux kernel and Mathieu Xhonneux added eBPF features to this implementation to make it easier to extend.
Our second example is the utilization of eBPF to monitor the networking stack. This is one of the classical use cases for eBPF today. Olivier Tilmans proposed the COP2 set of eBPF programs to monitor the performance of the networking stack and export the collected metrics using IPFIX.
Our third example is TCP. TCP is the standard reliable transport protocol for many applications. Viet-Hoang Tran showed that it is possible to leverage eBPF to extend both TCP and Multipath TCP by adding new TCP options in the Linux TCP stack. Mathieu Jadin took a different approach and proposed the TCP Path Changer (TPC). The TPC leverages eBPF and IPv6 Segment routing to allow a TCP stack to react to different types of events by moving established TCP connections to a different path.
QUIC is a new IETF protocol that replaces the classical TLS over TCP stack. It is already widely deployed by cloud providers. Quentin De Coninck, Maxime Piraux, Francois Michel showed in Pluginizing QUIC that it is possible to use eBPF inside a QUIC implementation to support various protocol extensions including Multipath, VPN or Forward Erasure Correction.
Our last example is BGP. BGP is the most important Internet routing protocol. It slowly evolves. With xBGP, Thomas Wirtgen demonstrated that by adding eBPF support in the BIRD and FRRouting implementations it becomes possible for network operators to develop their own extensions to the BGP protocol and execute them as eBPF program.
Once the IETF BPF/eBPF working group has finished the standardization of the basics of eBPF the IETF should start to discuss the utilization of eBPF inside various Internet protocols.