Onze onderzoeksagenda voor veiligere routering

Een greep uit de problemen met het normale BGP

De huidige versie van het BGP is BGP4. Het BGP verbindt autonoom beheerde netwerken, die autonome systemen (AS'en) worden genoemd. Het doet dit door routeringsinformatie op een gedistribueerde en gedecentraliseerde manier door het internet te propageren. AS'en gaan peering-relaties met elkaar aan op basis van vertrouwen en economische prikkels. De wereldwijde uitwisseling van routeringsinformatie is afhankelijk van het transitieve vertrouwen dat uit deze peering-relaties voortkomt.

Elk AS kan nieuwe routes op het internet claimen, soms met rampzalige gevolgen. Een AS kan bijvoorbeeld opzettelijk of per ongeluk claimen dat het de oorsprong is van een IP-adresbereik of dat het op een pad naar een AS van bestemming ligt. Normaal gesproken is het geen probleem dat een IP-adresbereik vanuit meerdere AS'en kan worden aangekondigd, omdat het de eigenaar van een bepaald prefix de kans geeft om tussen AS'en te migreren of resources te spreiden om de robuustheid te vergroten. Het grootste probleem hier is echter dat het BGP in zijn meest basale vorm een AS niet de mogelijkheid biedt om te controleren of een ander AS een IP-prefix terecht claimt. Als zo'n claim niet terecht is, kan dat er dus toe leiden dat het betreffende adresbereik niet beschikbaar is, het 'kapende' AS in staat is om het verkeer naar IP's binnen het adresbereik af te luisteren of zelfs om diensten na te bootsen.

Netwerkbeheerders implementeren filters om te voorkomen dat valse routeringsinformatie wordt gepropageerd. Ze kunnen er bijvoorbeeld voor zorgen dat ze alleen routes accepteren van klanten die er ook daadwerkelijk voor verantwoordelijk zijn. Zulke filters worden echter niet altijd juist geïmplementeerd en omdat informatie vaak niet kan worden geverifieerd, zijn ze niet toereikend. Aangezien het internet afhankelijk is van de juistheid en stabiliteit van de informatie die via het BGP wordt uitgewisseld, heeft de internetgemeenschap verschillende protocollen ontwikkeld die de veiligheid van het BGP kunnen verbeteren en de hier beschreven problemen kunnen aanpakken. In deze blog introduceren we in het kort de protocollen in kwestie en bespreken we op welk vlak naar onze mening onderzoek nodig is om deze protocollen verder te verbeteren en de implementatie ervan te bevorderen.

Een overzicht van BGP-beveiliging

De hier besproken protocollen maken gebruik van de Resource Public Key Infrastructure (RPKI), waarmee eigenaren van IP-adresruimte en AS'en cryptografisch verifieerbare claims kunnen maken ten aanzien van hun resources, zoals IP-adressen of AS-nummers (ASN's). Een overzicht van RFC's die betrekking hebben op de RPKI vind je hier.

De eerste en meest gebruikte objecten in de RPKI zijn Route Origin Authorizations (ROA's), waarin de eigenaar van een resource het prefix ervan cryptografisch koppelt aan een groep ASN's die de oorsprong van dat prefix mogen zijn. Alle 5 Regional Internet Registry's (RIR's) ondersteunen het creëren van ROA's. AS'en die valideren en filteren op basis van ROA's kunnen gevallen voorkomen waarin een ander AS ten onrechte claimt de oorsprong van een prefix te zijn. Dit validatieproces wordt Route Origin Validation (RoV) genoemd. De impact van deze oplossing wordt echter beperkt door het aantal ondertekende ROA's. Op dit moment laat het aantal ROA's een stijgende lijn zien en worden prefixen die een ROA schenden door steeds meer netwerken niet geaccepteerd. Vergeet niet dat routers aan de rand van het internet voor RoV vaak moeten vertrouwen op hun upstream providers, omdat ze niet de volledige BGP-tabel ontvangen en daarom zelf geen RoV kunnen uitvoeren.

Terwijl ROA's IP-prefixen koppelen aan groepen ASN's die zich de oorsprong ervan mogen noemen, stellen ASPA-objecten (Autonomous Systems Provider Authorization) paal en perk aan het spoofen en nabootsen van ASN's. ASPA is nog niet gestandaardiseerd, maar is bedoeld om AS'en in staat te stellen om in de RPKI te publiceren welke provider ze gebruiken om verbinding te maken met de rest van het internet. Daarom kan ASPA voorkomen dat een AS ten onrechte claimt rechtstreeks verbonden te zijn met een AS dat ASPA-objecten publiceert.

Ten slotte stelt Border Gateway Protocol Security (BGPsec), gestandaardiseerd in RFC 8205, routers op het internet in staat te verifiëren of de ontvangen routeringsinformatie daadwerkelijk is gepropageerd via het verkondigde AS-pad. De router kan er dan zeker van zijn dat het pad dat in het BGP-updatebericht wordt vermeld ook echt bestaat. Het systeem vereist dat routers langs het pad de BGP-update ondertekenen met hun privésleutels, inclusief de handtekening van de vorige BGP-hop. Dankzij de vertrouwensketen die hierdoor ontstaat, kunnen routers AS-paden van begin tot eind verifiëren. BGPsec verplicht netwerkbeheerders de publieke sleutels van hun routers te publiceren in de RPKI.

Ook de onderzoeksgemeenschap heeft verschillende maatregelen bedacht om de beveiliging van het BGP te verbeteren, zoals BGP-iSec. Er zijn echter geen pogingen om deze bij de IETF te standaardiseren, wat de kans op adoptie verkleint. Om deze reden laten we ze hier buiten beschouwing.

Onze onderzoeksagenda voor veilige routering

We willen ons richten op 3 aspecten van de beveiliging van het BGP: de robuustheid van de RPKI, de implementatie van BGPsec, en tools en inzichten die beheerders helpen om kapingen het hoofd te bieden. We zijn van mening dat deze aspecten niet genoeg aandacht hebben gekregen of dusdanig belangrijk zijn voor de veiligheid van het internet dat ze de aandacht verdienen van zoveel mogelijk onderzoekers.

Onderzoeksgebied 1: Robuustheid van de RPKI

De RPKI is het fundament van onder andere ROA's en ASPA-objecten en speelt een belangrijke rol in BGPsec. De beschikbaarheid en robuustheid van de RPKI zijn dan ook cruciaal. Als RPKI-informatie langere tijd niet beschikbaar is, kan het gebeuren dat partijen niet in staat zijn om ROA- en ASPA-objecten te valideren, updates te ontvangen of routercertificaten op te halen. Dat zou de bescherming die deze protocollen bieden in feite teniet doen en zelfs ervoor zorgen dat routes niet gepropageerd worden.

Wanneer de RPKI niet beschikbaar is, is het bijvoorbeeld mogelijk dat de eigenaar van een prefix die migreert tussen AS'en niet in staat is om de bijbehorende ROA bij te werken. Dat kan tot gevolg hebben dat de ROA ongeldig wordt en validerende partijen de routes naar het AS verwerpen. Nu op grote schaal gebruik wordt gemaakt van RoV, kunnen zulke scenario's desastreuze gevolgen hebben voor de beschikbaarheid van het internet.

Ons doel is om de kritieke componenten te identificeren die de beschikbaarheid van de RPKI kunnen beïnvloeden, een inschatting te maken van de waarschijnlijkheid en impact van uitval, en te bepalen wat er nodig is om de robuustheid van de RPKI te vergroten.

Voorbeelden van onderzoeksvragen met betrekking tot de robuustheid van de RPKI:

• Welke componenten zijn verantwoordelijk voor de beschikbaarheid van RPKI?

• Wat zou de impact zijn als RPKI deels of helemaal niet beschikbaar zou zijn?

• Wat voor gebeurtenissen kunnen van invloed zijn op de beschikbaarheid van kritieke componenten en hoe waarschijnlijk zijn zulke gebeurtenissen?

• Hoe kunnen we zulke gebeurtenissen voorkomen of de impact ervan verminderen?

Om die vragen te beantwoorden, gaan we internetbrede metingen uitvoeren van de verschillende RPKI-componenten en hun onderliggende afhankelijkheden.

Onderzoeksgebied 2: De implementatie van BGPsec

Hoewel de RFC's die BGPsec standaardiseren al 6 jaar oud zijn, wordt BGPsec nog steeds nauwelijks toegepast. Dit is deels te wijten aan het kip-of-ei-probleem dat in het verleden meer beveiligingsuitbreidingen van protocollen, waaronder DNSSEC, parten heeft gespeeld.

Een andere reden is dat de impact van BGPsec op de propagatie van routes nog niet goed wordt begrepen. Een router die een route deelt met een peer moet het gehele AS-pad in een aankondiging ondertekenen en een router aan de ontvangende zijde moet dat pad verifiëren. Deze cryptografische bewerkingen kunnen een behoorlijke belasting vormen voor de routers in kwestie, vooral als het om oudere apparatuur met beperkte verwerkingscapaciteit gaat.

Daarnaast voeren sommige BGP-experts aan dat BGPsec het beoogde beveiligingsniveau alleen levert als iedereen het gebruikt. Ons doel is dan ook om inzicht te krijgen in hoe beheerders kunnen zorgen voor veilige paden als BGPsec niet door iedereen wordt gebruikt.

Hiertoe hebben we de volgende onderzoeksvragen geformuleerd:

• Wat is de impact van BGPsec op de propagatie van routes op het internet?

• Als er sprake is van negatieve impact, wat is dan de oorzaak van de achteruitgang in functioneren?

• Hoe kunnen we de negatieve impact verminderen?

• Welke AS'en zouden BGPsec moeten gebruiken om het aantal beschermde routes te maximaliseren?

In eerste instantie willen we deze onderzoeksvragen beantwoorden door BGPsec te implementeren en te testen in een lokaal testbed bij SIDN Labs. Onlangs hebben we ook ons eigen testnetwerk opgezet bij Nikhef. Dit stelt ons in staat om BGPsec-experimenten uit te voeren met partijen die onze interesse in onderzoek naar veilige routering delen en met ons willen samenwerken.

Onderzoeksgebied 3: Veilige routering voor klantnetwerken

De meeste netwerken op het internet zijn klantnetwerken, wat betekent dat ze geen connectiviteit leveren aan andere netwerken. Deze netwerken zouden hun IP-prefixen moeten beschermen, bijvoorbeeld door ROA- of ASPA-objecten te publiceren in de RPKI. Echter niet alle netwerken op het internet valideren die objecten en ongeldige aankondigingen worden dan niet verworpen. ROA- en ASPA-objecten kunnen daarom niet alle aanvallen voorkomen.

Beheerders hebben verschillende instrumenten tot hun beschikking om misbruik van hun eigen prefixen te detecteren. Voorbeelden hiervan zijn route collectors of toepassingen die daarop voortbouwen, zoals ARTEMIS. Hoewel deze instrumenten niet perfect zijn en mogelijk niet alle voorvallen kunnen detecteren, zijn ze betrekkelijk goed onderzocht. Om die reden is het ons doel om beheerders van wie de prefixen zijn misbruikt te helpen de impact van kapingen te beoordelen en de juiste actie te ondernemen.

Om dat doel te bereiken, moeten we het volgende weten:

• Is er bij kapingen sprake van patronen, en zo ja welke? Hoe worden ze bijvoorbeeld uitgevoerd en welke partijen zijn erbij betrokken?

• Welke impact heeft een kaping op het netwerk en de diensten van de getroffen beheerder?

• Als de impact 'significant' is (afhankelijk van de beheerder en de dienst), welke actie zou een beheerder dan moeten ondernemen om de impact te beperken?

• Welke maatregelen kunnen beheerders nemen om hun netwerken en diensten beter bestand te maken tegen toekomstige kapingen?

Bij het beantwoorden van deze vragen zullen we putten uit de eigen ervaring van SIDN als beheerder van een eindnetwerk dat kritieke diensten levert. Mogelijke onderzoeksproducten zijn aanbevelingen voor beheerders en meetwaarden voor het meten van de impact van routeringsbeveiliging op hun diensten.

Oproep

Hebben we belangrijke aspecten over het hoofd gezien? Wil je meewerken aan een van de hierboven genoemde onderwerpen? We willen graag feedback van beheerders en onderzoekers over onze onderzoeksagenda en we nodigen je uit om contact met ons op te nemen via moritz.muller@sidn.nl.

Met dank aan onze collega's Jeroen Bulten en Dennis Meijer voor hun inbreng.