BGPsec - Zou je het kunnen draaien als je dat wilde?

BGP: de lijm van het internet

Het Border Gateway Protocol (BGP) verbindt de meer dan 75.000 verschillende netwerken waaruit het internet bestaat tot een enkele wereldwijde communicatie-infrastructuur. Het maakt gebruik van het concept van een 'BGP-pad' om de beste route naar een netwerk te bepalen en daarmee ook de prefixen die dat netwerk aankondigt. Een router verneemt deze paden via BGP-updateberichten van andere routers.

Het gewone BGP bevat geen beveiligingsmechanismen die garanderen dat het door een router aangegeven BGP-pad geldig is. In de kern is BGP dus gebaseerd op vertrouwen tussen partijen die BGP-routers beheren. In de steeds groter wordende internetinfrastructuur is dit vertrouwen niet altijd meer vanzelfsprekend. Een kwaadwillend Autonoom Systeem (AS) kan bijvoorbeeld opzettelijk een prefix aankondigen zonder daartoe gerechtigd te zijn (prefixkaping), of een AS-pad wijzigen om een valse link naar het eigen AS te creëren (AS-padvervalsing). Bij beide voorbeelden wordt verkeer omgeleid naar een netwerk dat niet de bedoeling was, waar het kan worden onderschept of geblackholed.

Wat is BGPsec?

BGPsec is een uitbreiding op BGP die de grondslag vormt voor padverificatie en bescherming biedt tegen de 2 bovengenoemde soorten aanvallen. Om een geldige BGP-update met het BGPsec-attribuut te construeren, moeten routers een handtekening toevoegen. De handtekening garandeert de correctheid van de prefix die door de update wordt aangekondigd, het AS-nummer (ASN) van het AS waar de update naartoe wordt gestuurd, en alle eerdere handtekeningen. De private sleutel die routers gebruiken voor het ondertekenen, moet overeenkomen met het BGPsec-routercertificaat dat is opgeslagen in de Resource Public Key Infrastructure (RPKI) en gekoppeld is aan het ASN van de router.

BGPsec is niet de enige manier om BGP te beveiligen. Er kan ook gebruikt worden gemaakt van Route Origin Authorization (ROA)-objecten, een benadering die behoorlijk wat navolging heeft gevonden. ROA's geven een router de mogelijkheid om te controleren of het AS dat een bepaalde prefix aankondigt daartoe gerechtigd is en bieden zo bescherming tegen prefixkapingen. Daarnaast gaat de RPKI binnenkort misschien ook Autonomous System Provider Authorization (ASPA)-objecten opslaan, waarmee het mogelijk wordt om de plausibiliteit van een ontvangen pad te evalueren op basis van een lijst van vooraf goedgekeurde provider-AS'en. De rest van deze blog gaat alleen over BGPsec. Voor meer actuele informatie over ROA's en ASPA kun je het artikel ‘RPKI/ROV-beveiligingsprotocol maakt razendsnelle adoptie door’ op sidn.nl lezen.

Het probleem met BGPsec: geen uitrol sinds 2017

Hoewel BGPsec beschermt tegen een additionele aanvalscategorie, heeft het niet dezelfde groei doorgemaakt als ROA's, ondanks het feit dat het inmiddels al 8 jaar is gestandaardiseerd. Dit heeft te maken met een aantal zorgen binnen de onderzoeks- en operationele gemeenschap. Denk bijvoorbeeld aan hogere verwerkingskosten en geheugenvereisten voor de huidige generatie routers, een toename van het aantal updateberichten en het ontbreken van prikkels voor early adopters omdat de voordelen van BGPsec bij beperkte deployment gelimiteerd zijn.

Tegelijkertijd heeft BGPsec in combinatie met ROA’s en ASPA potentie voor de volgende generatie routers, zoals BGP-expert Job Snijders onlangs aangaf. Daarom voeren we een empirische validatie uit van de functionele mogelijkheden en interoperabiliteit van de huidige routerimplementaties met BGPsec-functionaliteit. Deze interoperabiliteit en mogelijkheden moeten uitontwikkeld zijn om BGPsec op grote schaal uit te kunnen rollen. Onze aanpak bestaat uit het uitvoeren van praktijkgerichte experimenten in een kleinschalig testbed dat we daarvoor hebben opgezet.

Wat heb je nodig om een BGPsec-router te implementeren?

Om BGPsec-updates te kunnen ondertekenen en valideren, moet een router eerst een routercertificaat krijgen van een Regional Internet Registry (RIR). Op het moment van schrijven ondersteunt echter geen van de RPKI-repository's die door de 5 RIR's worden gehost de publicatie van BGPsec-routercertificaten. RIPE NCC laat weten dat dit gepland staat voor het tweede kwartaal van 2025. Gelukkig is het ook mogelijk om gebruik te maken van delegated RPKI. Door middel van delegated RPKI kunnen operators en onderzoekers RPKI-objecten opslaan in een aparte repository, die ze beschikbaar kunnen stellen aan het publiek zonder te hoeven wachten op de RIR's. Hiervoor kan gebruik worden gemaakt van de Certificate Authority-software Krill, die BGPsec-routercertificaten ondersteunt.

De tweede component die een BGPsec-router nodig heeft, is een validerende cache. Deze valideert en bewaart BGPsec-routercertificaten die via HTTPS of rsync uit de RPKI zijn opgehaald. Drie actief onderhouden validerende caches zijn Routinator, FORT validator en rpki-client. Routinator en rpki-client ondersteunen de validatie van BGPsec-routercertificaten.

Ten slotte moet de router het RPKI-to-Router (RTR)-protocol ondersteunen. Routinator bevat een ingebouwde RTR-server die RTR versie 1 ondersteunt. Zoals beschreven in RFC8210, voegt versie 1 van RTR functionaliteit voor BGPsec toe. Tot versie 1.5.2 werden BGPsec-routercertificaten ook ondersteund door FORT validator. Deze ondersteuning is echter ingetrokken omdat er 'meer testen' nodig waren. Van de beschikbare implementaties van het RTR-protocol bieden StayRTR en RTRlib ondersteuning van BGPsec-routercertificaten.

Geëvalueerde routers die BGPsec ondersteunen

We evalueerden 5 softwarerouters met ondersteuning voor BGPsec. De 5 implementaties waren afkomstig van bgpsec.net: QuaggaSRx, GoBGP-SRx, ExaBGP-SRx, FRR en BIRD. Deze implementaties zijn allemaal tussen de 2 en 10 jaar oude afsplitsingen van bestaande, goed onderhouden softwarerouters. Voor zover wij weten, is er op dit moment geen hardwarerouter die BGPsec ondersteunt.

QuaggaSRx, GoBGP-SRx en ExaBGP-SRx zijn gebouwd door een team bij NIST en maken deel uit van een voorbeeldimplementatie van BGPsec: de BGP (S)ecure (R)outing E(x)tension Software Suite (NIST BGP-SRx). Om een softwarerouter te kunnen draaien die deel uitmaakt van de suite is het nodig om de SRxCryptoAPI te compileren. Deze API bevat cryptografische functies waarmee de router BGPsec-paden kan ondertekenen en valideren.

Naast de API biedt NIST BGP-SRx een SRx-server waaraan de router de validatie kan uitbesteden. Deze server kan worden aangesloten op een validerende cache om gevalideerde gegevens op te halen uit een RPKI-repository, waaronder beschikbare BGPsec-routercertificaten. Certificaten kunnen ook rechtstreeks aan de router worden verstrekt via de lokale sleutelopslag van de SRxCryptoAPI.

De resterende 2 BGPsec-implementaties die we evalueerden, zijn afsplitsingen van BIRD en FRR. Deze maken geen van beide deel uit van NIST BGP-SRx en staan er los van. De BGPsec-afsplitsing van BIRD dateert van voor de standaardisatie van BGPsec en is de oudste afsplitsing in deze lijst. Door middel van wat kleine patches waren we in staat om de delen van de implementatie die duidelijk verouderd waren te repareren. Een voorbeeld hiervan is het gebruik van een willekeurig nummer om ondersteuning van BGPsec aan te geven die niet aangepast is aan de latere standaard.

Ons experimentele BGPsec-netwerk

We configureerden Docker-containers om de 5 routers en hun functionaliteit te evalueren en te verifiëren. We compileerden de implementaties, brachten waar nodig patches aan en configureerden onderlinge BGP-sessies met BGPsec. Hiervoor moesten we een Subject Key Identifier (SKI) instellen voor de identificatie van een BGPsec-routercertificaat en bijbehorende private sleutel voor ondertekening. Waar nodig moesten we de router laten weten op welk IP-adres de SRx-Server of Routinator kon worden gevonden.. Voordat we de routers in werking stelden, bereidden we private sleutels en certificaten voor in de vereiste opmaak en volgens gedefinieerde naamgevingsregels. De argumenten die nodig zijn om BGPsec te configureren, verschillen per routerimplementatie.

We evalueerden de routers met topologieën die bestonden uit 2 BGP-routers die allebei 1 IPv4-prefix aankondigden. Voor de implementaties die via RTR (of indirect via de SRx-Server) gegevens konden ophalen uit een validerende cache, gebruikten we Routinator als validerende cache en Krill als RPKI-testbed dat onze BGPsec-routercertificaten bevatte.

QuaggaSRx is geïntegreerd met de SRx-Server. Zoals te zien is in Figuur 1, haalt Routinator in onze opstelling de BGPsec-routercertificaten op van Krill en verloopt de communicatie met de SRx-Server via RTR. De communicatie tussen de SRx-Server en QuaggaSRx verloopt via het nog niet gestandaardiseerde SRx Proxy Protocol. Indien geconfigureerd, wordt de validatie van handtekeningen uitbesteed aan de SRx-Server. Private sleutels worden lokaal opgeslagen in de sleutelopslag van de SRxCryptoAPI en worden gebruikt om handtekeningen aan te maken.

Figuur 1. QuaggaSRx-opstelling in ons testbed.

Hoewel op de projectwebsite van NIST BGP-SRx staat dat GoBGP-SRx en ExaBGP-SRx beide de SRx-Server ondersteunen, beschrijft de documentatie '3 mogelijke scenario's voor hoe het gebruik van de SRX-Server zou kunnen worden gefaciliteerd'. Op basis van onze analyse en de bestaande documentatie constateerden we dat de huidige implementaties geen out-of-the-box integratie met de SRx-Server bieden. Ze hebben echter wel toegang tot de BGPsec-routercertificaten wanneer deze worden verstrekt via de bij de SRxCryptoAPI behorende sleutelopslag. Zoals wordt weergegeven in Figuur 2, testten we beide routers door de private sleutels en certificaten lokaal op te slaan. Wanneer de SRxCryptoAPI wordt geïnitialiseerd, worden ze geladen en kunnen ze worden gebruikt voor ondertekening en validatie.

Figuur 2. Opstelling voor het draaien van ExaBGP-SRx of GoBGP-SRx in ons testbed.

FRR maakt gebruik van de bestaande ondersteuning voor BGPsec-routercertificaten van RTRlib om met de validerende cache te communiceren. Figuur 3 laat zien dat de communicatie tussen FRR en Routinator rechtstreeks via RTR plaatsvindt, zonder een tussenliggende server zoals bij QuaggaSRx.

Figuur 3. FRR-opstelling in ons testbed.

BIRD heeft geen geïntegreerde RTR-client en communiceert niet met een validerende cache. Deze opstelling vertrouwt dus uitsluitend op de BIRD-router zelf, zoals te zien is in Figuur 4. In tegenstelling tot ExaBGP-SRx en GoBGP-SRx maakt BIRD voor de validatie geen gebruik van BGPsec-routercertificaten, maar wordt er enkel om lokaal opgeslagen corresponderende publieke sleutels gevraagd.

Figuur 4. BIRD-opstelling in ons testbed.

Methodologie: verkeersanalyse van BGPsec-aankondigingen

Om te evalueren in hoeverre de routers in staat waren om aan de hand van de geconfigureerde private sleutel geldige handtekeningen aan te maken en BGPsec-padattributen te construeren, lieten we ze allemaal een IPv4-prefix aankondigen en analyseerden we het onderlinge verkeer met behulp van Wireshark.

Om de validatie van de handtekeningen te testen, construeerden we BGPsec-updates met een private sleutel die niet overeenkwam met de sleutel die in Krill of de lokale sleutelopslag voor het verzendende AS geconfigureerd was. Vervolgens onderzochten we de logbestanden en de RIB van elke router om te zien hoe de router omging met geldige en ongeldige handtekeningen. Vermelding 1 toont een voorbeeld van hoe BIRD in de RIB een route correct markeert als geldig volgens BGPsec (BSEC VALID).

bird> show route
10.2.0.0/16        via 10.0.0.2 on eth0 [bgp1 14:58:53] * (100) [AS64602i] ASP:1 (BSEC VALID: 64602)
10.3.0.0/16        via 10.0.0.3 on eth0 [static1 14:58:48] * (200)

Vermelding 1. BIRD markeert route als BSEC VALID in RIB.

We evalueerden de interoperabiliteit tussen routers door BGP-sessies op te zetten tussen alle combinaties van 2 routerimplementaties (dus 15 in totaal). Als BGP-updates met BGPsec-attributen met succes werden uitgewisseld en verwerkt, beschouwen we de 2 implementaties als interoperabel. Vermelding 2 toont een voorbeeld van 2 routers waarbij dit niet het geval was: nadat FRR een BGPsec-update van BIRD heeft ontvangen, breekt FRR het proces af en wordt de sessie beëindigd.

frr_two     | BGP: Received signal 6 at 1741005719 (si_addr 0x1, PC 0x7f52ec57ab2c); aborting...
frr_two     | malloc(): unaligned tcache chunk detected

Vermelding 2. FRR breekt het proces af na ontvangst van een BGPsec-update van BIRD.

Resultaat 1: Functionaliteit van BGPsec-routers

Tabel 1 geeft een overzicht van onze evaluatie van de functionele mogelijkheden van de implementaties. Alle implementaties kondigen de BGPsec-functionaliteit van de router correct aan in het BGP OPEN-bericht en construeren geldige BGPsec-attributen in updates. Voor BIRD moesten we een patch ontwikkelen en toepassen om de code voor de functionaliteitsaankondiging en het BGPsec-padattribuut aan te passen aan de huidige BGPsec-standaard.

¹ Ondertekening met een incorrecte SKI wordt niet vermeld in een log of in de adj-rib in / out. Route wordt toegevoegd.

² Mislukte handtekeningvalidatie wordt vermeld in het log maar niet in de RIB. Route wordt toegevoegd. RIB geeft aan dat de route is vernomen via een BGPsec-UPDATE, niet of deze met succes is gevalideerd.

³ Handtekening wordt als geldig gemarkeerd als SKI aanwezig is in de van Routinator ontvangen gegevens. Als de voor ondertekening gebruikte SKI correspondeert met het ASN, wordt deze niet gevalideerd.

Tabel 1. BGPsec-functies per geëvalueerde implementatie.

We constateerden dat het onduidelijk is of ExaBGP-SRx de ontvangen BGPsec-handtekeningen valideert. De logbestanden bevatten geen validatieresultaten en het resultaat wordt ook niet vermeld in de RIB. Ontvangen routes worden altijd toegevoegd. FRR valideert ontvangen handtekeningen wel. Er is echter geen garantie dat de voor ondertekening gebruikte SKI correspondeert met het AS dat de update heeft gemaakt. Elke handtekening die is aangemaakt met een SKI die voorkomt in de RPKI-gegevens wordt geaccepteerd.

De verbinding met een validerende cache via RTR loopt zoals verwacht bij QuaggaSRx via de SRx-Server en bij FRR via RTRlib, zoals beschreven staat in hun documentatie. In de documentatie van NIST BGP-SRx worden ook nog verschillende methoden beschreven waarmee ExaBGP-SRx en GoBGP-SRx kunnen worden geïntegreerd met de SRx-Server om toegang te krijgen tot RPKI-gegevens en net als QuaggaSRx de validatie uit te besteden, maar dat zou extra implementatiewerk met zich meebrengen.

Resultaat 2: Interoperabiliteit van BGPsec-routers

We evalueerden ook de interoperabiliteit van de routers, zoals te zien is in Tabel 2. We zagen dat BIRD het minst goed samenwerkt met de andere implementaties. ExaBGP-SRx en GoBGP-SRx sloten allebei hun sessie met BIRD af na het verzenden van een BGP NOTIFICATION-bericht. In het geval van FRR leidde de ontvangst van een BGPsec-bericht van BIRD er zelfs toe dat FRR werd beëindigd wegens een SIGABRT.

¹ IRD geeft in het OPEN-bericht niet correct aan dat het IPv6 unicast ondersteunt, maar stuurt dan een MP_UNREACH_NLRI voor IPv6 unicast, wat ertoe leidt dat ExaBGP-SRx een NOTIFICATION-bericht stuurt en de verbinding verbreekt.

² Na ontvangst van een BGPsec-UPDATE van BIRD stuurt GoBGP-SRx een NOTIFICATION met code 0 en wordt de sessie gesloten.

³ BIRD stuurt een BGPsec-UPDATE naar FRR, wat leidt tot een SIGABRT veroorzaakt door een malloc call.

Tabel 2. Interoperabiliteit per geëvalueerde BGPsec-implementatie.

Hoe nu verder?

We hebben met behulp van een kleinschalig testbed een praktische evaluatie uitgevoerd van 5 bestaande routerimplementaties die BGPsec ondersteunen. De routers zijn functioneel en interoperabel genoeg om een testbed op te zetten om experimenten uit te voeren. De implementaties zijn echter nog lang niet in staat om BGPsec te ondersteunen in productie, laat staan op de schaal die nodig zou zijn om BGP-routering wereldwijd te beveiligen. We stellen in onze GitHub repository containers beschikbaar voor alle implementaties, zodat je eenvoudig je eigen testbed kunt opzetten.

Een mogelijke volgende stap in ons werk met BGPsec is het uitvoeren van experimenten waarbij we routeringsgegevens uit de praktijk reproduceren in een groter BGPsec-testbed, om een dieper inzicht te krijgen in de impact van BGPsec op de routerprestatie en in de schaalbaarheid ervan in praktijksituaties. Een andere mogelijkheid zou kunnen zijn dat we onze compatibiliteitsevaluatie uitbreiden met meer testen, wat zou kunnen helpen bij het ophelderen van onduidelijkheden in de BGPsec-standaard.

De komende maanden gaan we bekijken hoe we hier bij SIDN Labs kunnen helpen om deze uitdagingen aan te pakken. In de tussentijd nodigen we je uit om met behulp van ons testbed zelf te gaan experimenteren met de implementaties.

Wat vind jij?

We zijn heel benieuwd naar jouw mening over dit onderwerp!

Hebben we implementaties gemist? En hoe denk jij over BGPsec en de toekomst ervan in het algemeen? Laat het ons weten op lisa.bruder@sidn.nl.