Pluginized Protocols

TCPLS featured on the APNIC blog

2021-04-15T00:00:00+00:00

The APNIC blog regularly publishes posts on recent scientific articles that could be of interest for the networking community. In a blog post entitled Introducing TCPLS: A game of transport protocols, Florentin Rochet describes some of key features of TCPLS.

2021 ANRP award for xBGP

2021-01-05T00:00:00+00:00

Every year, the Internet Research Task Force awards the Applied Networking Research Prize (ANRP) to recognise the best recent results in applied networking, interesting new research ideas of potential relevance to the Internet standards community. In late 2020, 78 papers published in networking conferences and journals were nominated. The xBGP paper, xBGP: When You Can’t Wait for the IETF and Vendors written by Thomas Wirtgen (UCLouvain), Quentin De Coninck (UCLouvain), Randy Bush (Internet Initiative Japan & Arrcus, Inc), Laurent Vanbever (ETH Zürich) and Olivier Bonaventure (UCLouvain) was selected with five other articles. It will be presented by Thomas Wirtgen at a forthcoming IETF meeting.

This award shows the interest from the community on the xBGP effort.

A first xBGP plugin

2020-11-29T00:00:00+00:00

An xBGP compliant implementation such as our forks of BIRD and FRRouting supports a simple API that enables network operators and researchers to extend it. The xBGP API is defined and briefly documented in xbgp_plugin_api.h. In this post, we start with a very simple xBGP extension that we implement using a plugin.

The BGP specifications define the format of the BGP messages. The UPDATE message is the most complex BGP message since it contains the information about the new routes. BGP supports different BGP Path Attributes that are defined in various RFCs. Each of these path attributes is identified using a one byte integer. IANA maintains a list with all the known path attributes.

For our first example, we simply assume that a network operator would like to ignore the BGP UPDATE messages that contain an unknown attribute. A practical example of this usage is when problems with the processing of BGP Path attribute 128 caused the failure of BGP sessions. To support this feature, we retrieve the list of allocated BGP path attribute identifiers from IANA. We use it to create the is_known_attr macro that checks this validity.

#include "ubpf_api.h"
#include "bytecode_public.h"

#define is_known_attr(code) ( \
    ((code) == RESERVED_ATTR_ID) || \
    ((code) == ORIGIN_ATTR_ID) || \
    ((code) == AS_PATH_ATTR_ID) || \
    ...
    )

This filter needs to be attached to the xBGP implementation at the code point where it parses an incoming BGP message, i.e., at location 1 in the figure below.

The next step is to write a small C function that parses the received message and checks the attributes that it contains.

uint64_t parse_attribute(args_t *args UNUSED) {

    uint8_t *code;
    code = get_arg(0); // argument 0 is the code attribute received from the neighbor.

    if (!code) {
        // unable to retrieve the argument (internal failure)
        return EXIT_FAILURE;
    }

    if (!is_known_attr(*code)) {
        return EXIT_FAILURE;
    }

    return 0;
}

You can experiment with this simple plugin as follows. Save your plugin as valid_attr.c.

First, the C program must be compiled to an eBPF bytecode. This can be done with the clang compiler. However for the sake of simplicity, we provide a Makefile that contains the prebuilt commands to successfully compile your plugins.

Clone our GitHub repository:

$ git clone https://github.com/pluginized-protocols/xbgp_plugins.git

The libxbgp folder must also be cloned. It contains headers that are required to interact with the eBPF userspace virtual machine. For example, they contain functions to allocate memory, retrieve arguments (get_arg) from the host implementation and using base functions such as htonl, ntohl, etc.

All your plugins must be located in the cloned folder because it contains the required headers that define the xBGP API used by the plugins.

Inside the xbgp_plugins folder, execute the following command:

$ make LIBXBGP=<path/to/the/libxbgp cloned repository>

This command will browse the entire folder and its subfolders recursively to find any .c files. For each .c file, the clang compiler will produce the associated object (.o) file. This will be the eBPF bytecode of your plugin.

Take the valid_attr.o associated with the function written previously. You are now ready to inject it inside one xBGP compliant BGP implementation. In this tutorial, we provide the steps to successfully update the FRRouting BGPD daemon. The steps are similar for BIRD routing.

Our modified version of FRR BGPD requires that each .o must be located in <config_frr_dir>/frr/plugins. By default, and depending on the compilation of FRRouting, the default configuration folder is /etc/frr/plugins.

The next step is to update the manifest. This manifest is a json formatted file that is read by the daemon at startup to include all the plugins that it contains. It is located at <config_frr_dir>/frr/plugins/manifest.json. Modify it as follows:

{
  "jit_all": false,
  "plugins": {
    "filter_invalid_attr": {
      "extra_mem": 128,
      "shared_mem": 0,
      "obj_code_list": {
        "invalid_attr": {
          "obj": "invalid_attr.o",
          "jit": true
        }
      }
    }
  },
  "insertion_points": {
    "bgp_decode_attr": {
      "replace": {
        "0": "invalid_attr"
      }
    }
  }
}

This manifest contains several required fields :

plugins: contains the definition of all that plugins that must be loaded at startup time.
- <plugin_name>: the identifier of the plugin. In this example, we use filter_invalid_attr
  - extra_mem: how many *bytes* to allocate for the API function. Some functions need extra memory to allocate data retrieved from the host implementation. Other functions such as ctx_malloc rely on this memory space.
  - shared_mem: how many *bytes* to allocate for the memory space shared among the pluglets of the same plugin. This memory space is used by functions of type shared_memory.
  - obj_code_list: contains the list of the pluglets that belong to the same plugin. Each pluglet must have a unique identifier. In the example, we use the identifier invalid_attr.
    - <pluglet_identifier>: the identifier associated with the actual eBPF bytecode object.
      - obj: the real name of the file containing the eBPF bytecode.
      - jit: whether or not the pluglet must be converted to x86_64 machine code (can be omitted. Default: false).
insertion_points: this object field defines the location of each pluglet of a given plugin inside the host BGP implementation. This field takes a list of insertion point identifiers. We want that our plugin composed of one pluglet is executed at bgp_decode_attr.
- <insertion_point_id>: defines the list of pluglets that must be executed at this insertion_point
  - <replace|pre|post>: contains all the pluglets that will be executed in the replace, pre or post part of the insertion_point.
    - <execution order (int)>: the value associated to the int is the pluglet identifier defined in the plugin part of the manifest. In our example we want to execute the invalid_attr.o bytecode as the first pluglet of this insertion point. In the case of multiple insertion point the execution order field determines the order of execution. Pluglet 0 is executed first, then 1, …

Once the manifest has been saved and the pluglets saved in the <config_frr_dir>/etc/plugins file, you are now ready to start the BGP daemon.

To observe the filter behavior, we recommend that you use ExaBGP to generate custom attributes.

Finally, we provide a Dockerfile that includes our modified version of both BIRD and FRRouting, as well as a compiler (clang) to generate eBPF bytecodes. Currently, you need to manually to start the BGP from inside the docker. We will continue to maintain the docker to improve its configuration.

xBGP presented at IETF109

2020-11-19T00:00:00+00:00

Olivier Bonaventure presented xBGP on November 19th, 2020 to the TCPM working group at IETF109

You can download the pdf version of his slides or listen to his presentation on youtube.

You can find additional information in the Hotnets’20 paper xBGP: When You Can’t Wait for the IETF and Vendors written by Thomas Wirtgen and Quentin De Coninck (UCLouvain); Randy Bush (Internet Initiative Japan & Arrcus, Inc); Laurent Vanbever (ETH Zürich) and Olivier Bonaventure (UCLouvain)

TCPLS presented at IETF109

2020-11-18T00:00:00+00:00

Olivier Bonaventure presented TCPLS on November 18th, 2020 to the TCPM working group at IETF109

You can download the pdf version of his slides or listen to his presentation on youtube.

More details are provided in the TCPLS: Closely Integrating TCP and TLS paper written by Florentin Rochet (UCL Crypto Group); Emery Assogba and Olivier Bonaventure (UCLouvain) and presented at Hotnets’20.

TCPLS presented at Hotnets’20

2020-11-05T00:00:00+00:00

Florentin Rochet presented TCPLS on November 4th, 2020 at HotNets 2020: Nineteenth ACM Workshop on Hot Topics in Networks. The full paper is available from the ACM DL :

TCPLS: Closely Integrating TCP and TLS Florentin Rochet (UCL Crypto Group); Emery Assogba and Olivier Bonaventure (UCLouvain)

You can also download a pdf version of his slides or listen to his presentation on youtube.

xBGP presented at Hotnets’20

2020-11-05T00:00:00+00:00

Thomas Wirtgen presented xBGP on November 4th, 2020 at HotNets 2020: Nineteenth ACM Workshop on Hot Topics in Networks. The full paper is available from the ACM DL :

xBGP: When You Can’t Wait for the IETF and Vendors Thomas Wirtgen and Quentin De Coninck (UCLouvain); Randy Bush (Internet Initiative Japan & Arrcus, Inc); Laurent Vanbever (ETH Zürich); Olivier Bonaventure (UCLouvain)

You can also download a pdf version of his slides or listen to his presentation on youtube.

Source code for xBGP prototypes

2020-11-04T00:00:00+00:00

The source code for our xBGP prototype is available on github. It is divided in several repositories:

https://github.com/pluginized-protocols/libxbgp contains the libxbgp implementation which can be included in different BGP implementations
https://github.com/pluginized-protocols/xbgp_bird contains the changes required to support xBGP in BIRD
https://github.com/pluginized-protocols/xbgp_frr contains the changes required to support xBGP in FRRouting

In addition, we have collected several example xBGP plugins in the following repository:

https://github.com/pluginized-protocols/xbgp_plugins

Suggestions, comments and ideas are more than welcome !

Source code for the TCPLS prototype

2020-11-04T00:00:00+00:00

The source code for the current TCPLS prototype is available on github. This prototype is a fork of the picotls implementation :

https://github.com/pluginized-protocols/picotcpls

In addition to the TCPLS prototype, we are also developing a library that will allow existing applications to use TCPLS without any modification.

https://github.com/pluginized-protocols/tcplslibconvert

This library is currently a work in progress, but suggestions, comments and ideas are more than welcome !

An abstract workflow for BGP implementations

2020-10-07T00:00:00+00:00

The first step to allow BGP implementations to be programmed is to have a clear understanding of how the BGP protocol operates and how it processes and sends messages. If we ignore the establishment of BGP sessions and the detection of failures, all BGP implementations need to implement the workflow described in the figure below.

This workflow corresponds to the abstraction description of the BGP protocol in RFC4271. It illustrates the different datastructures that a BGP implementation must maintain and how BGP messages are processed. BGP messages are received on the left part of the figure and sent on the right. A BGP router maintains one BGP session with each peer. It stores several configuration parameters for each peer (IP address, AS Number, …) and associates an import filter to each peer. These filters are typically configured using vendor-specific commands or using NETCONF. When a BGP message is received over a BGP session it first passes through the import filter that may add or modify some of its attributes (e.g. local-pref or communities). It may also decide to discard the message (e.g. because it contains an invalid prefix). If the BGP message is accepted by the import filter, it is stored in the session’s BGP-Adj-RIB-In and then sent to the BGP-Loc-RIB. This RIB contains all the routes received from the different peers and accepted by their associated import filters. It is used by the BGP decision process to select the best route towards each IP prefix. This decision process is executed when a route is added or removed from the BGP-Loc-RIB and when the routes towards BGP nexthops change. The routes chosen by the BGP decision process are then pushed to the router’s FIB and advertised to peers, subject to the per-session export filters.

Starting from this workflow, one can identify five critical points in the processing of BGP messages. These points are identified with green circles in the figure below.

The first of these points is the reception of a BGP message from a peer. Several BGP extensions have defined new BGP attributes. This point is the part of the BGP implementation that parses the BGP message. To support a new BGP attribute, this is where a plugin could add new code to parse and process a new BGP attribute.

The second point corresponds to the import filters. This is a important part of a BGP implementation. When a new BGP attribute is defined, it typically needs to be supported in the import filter that could for example add the attribute to a BGP message or use its content in the filter.

The third point is the BGP decision process. This is a key part of a BGP implementation since network operators often need to tune the BGP decision process and modify how the best route is selected. By inserting plugins at this point, network operators

The fourth point corresponds to the export filters. As for the import filters, this is where new BGP attributes would be processed by the filters.

The last point is the encoding of the BGP messages that are sent to peers. This is where a new BGP attribute would be written before being sent on the wire.

In following blog posts, we’ll describe how plugins can be attached to these insertion points to support different types of BGP extensions.