Developing OpenBGPD to ensure secure and high-performance route servers

1. What is the Route Server Support Foundation (RSSF)?

The Route Server Support Foundation (RSSF) was established as a Dutch non-profit organisation to support the development of IX Route Server software. This will further improve the quality and safety of the global Internet routing system.

The RSSF is currently funded by its four Founding Sponsors (AMS-IX, DE-CIX, LINX, and Netnod) and is also supported by JPNAP and the Internet Society.

2. What are the main goals of the Route Server Support Foundation (RSSF)?

We hire talented developers to extend Internet infrastructure projects (such as OpenBGPD, rpki-client, or Alice LG) to bring much-needed software implementation diversity to the IX community.

We focus on integrating with industry-standard IX automation stacks (both current and planned). Our goal is to make  a robust set of different IX Route Server implementations accessible to IX operators (both large and small) in a safe manner.

Over the last year, we have contributed many significant improvements to the OpenBGPD project, a part of the OpenBSD project. Our mission is to develop a free, secure, and reliable BGP-4 implementation fit for carrier-grade workloads. RSSF and its developers strongly believe in the IETF standards development process to foster innovation and interoperability.

3. What important developments have you seen with standards over 2021? How has the RSSF developed OpenBGPD to include these developments? 

IX Route Server environments are susceptible to an issue known as “Path Hiding” (described in RFC 7947 Section 2.3.1). This issue manifests itself in the intersection between Routing Policy and traditional interpretations of the BGP protocol and leads to reduced visibility of available routing paths for Route Server clients. As a result, we implemented a feature similar to BIRD’s “secondary route” feature, which increases the number of routes available via OpenBGPD route servers.

As outlined in RFC 6471 and draft-ietf-idr-deprecate-as-set-confed-set, AS_SET segments inside the BGP AS_PATH Path Attribute are considered detrimental to the security posture of the global Internet routing system. As a result, OpenBGPD is one of the first implementations to actively support the negation of BGP routes tainted with an AS_SET segment.

An innovative observation about the BGP state machine was contributed to the IETF in the form of draft-spaghetti-idr-bgp-sendholdtimer and implemented in OpenBGPD as the “Send Hold Timer”. OpenBGPD might be the world’s first BGP implementation to correctly detect and react to message pipeline issues in the outgoing direction by coupling the TCP state machine and the BGP state machine in a specific way. In some scenarios, the Send Hold Timer concept reduces the potential for blackholing of IP traffic across internet-exchange fabrics.

Other improvements related to the management and operation of OpenBGPD: the MRT subsystem received various improvements (used for long term BGP message archiving), support for Enhanced Route Refresh (RFC 7313) was added, and various debugging outputs are now available in JSON format for easier parsing in downstream applications.

4. RPKI plays a big part in BGP security and is important for IX route servers. What RPKI developments have you made over 2021?

We added support for the RPKI-To-Router (RTR) protocol (RFC 6810). Support for RTR removes a degree of friction in certain types of large scale deployments. The ingestion of changes to the Validated ROA Payloads (VRPs) set–either via RTR or directly through on-disk configuration–happens graciously without impeding BGP neighbours. OpenBGPD is not susceptible to the issue described in “RPKI-Based Policy Without Route Refresh” (draft-ymbk-sidrops-rov-no-rr). This means that OpenBGPD is a very neighbourly BGP speaker reducing the computational cost for its EBGP neighbours!

OpenBGPD and rpki-client introduced the innovative concept of an ability to honour the transitive expiration moment of RPKI Validated ROA Payloads with per-prefix granularity. This feature improves the robustness of the point where the BGP and RPKI technology layers intersect; by creating a fail-open pathway, certain auto-pilot deployment scenarios become less risky!

5. What do you have in the pipeline for 2022?

RSSF will pursue the study of a deeper integration between the cryptographic RPKI plane and the BGP-4 routing protocol while maintaining high performance and no compromise to security. The board is excited to hire additional staff members to increase availability in case of Internet routing system emergencies.

Job Snijders

Job is IP Development Engineer at NTT Communications, where he analyzes and architects NTT's global IP network for future growth. He has been actively involved in the Internet community in an operational capacity, as a frequent presenter at network operator events such as NANOG, RIPE & APRICOT, and in a number of community projects for over 10 years. Job is founder & chairman of the NLNOG Foundation, and vice president of PeeringDB. Job's special interests are routing policy, routing security and large scale BGP deployments. He maintains several tools such as irrtree and irrexplorer, and is active in the IETF where he has coauthored or contributed to RFCs and Internet-Drafts.

More information

For more information about RSSF’s recent activities, you can read the latest RSSF report covering 2020-2021 here.