RPKI/ROV-beveiligingsprotocol maakt razendsnelle adoptie door

Figuur 1: RPKI/ROV aantallen van unieke prefix-origin-paren (IPv4). [bron: NIST]

RPKI is een cryptografische beveiligingsstandaard die houders van IP-adresblokken de mogelijkheid geeft om de door hun gepubliceerde routes van een digitale handtekening te voorzien. Daarmee wordt het voor kwaadwillenden moeilijker om valse routeinformatie in het systeem te injecteren, om op die manier IP-adressen te kapen of internetverkeer om te leiden. Bovendien voorkomt RPKI dat vergissingen van netwerkbeheerders verder propageren en belangrijke onderdelen en diensten worden afgekoppeld.

Kijken we naar het aandeel van de RPKI-beveiligde webservers onder het .nl-domein, dan komen we uit op bijna 90 procent. RPKI is sinds vorig jaar ook een belangrijk onderwerp op de onderzoeksagenda van SIDN Labs. En sinds eind januari wordt het RPKI-testresultaat van je domeinnaam ook meegenomen in de score van Internet.nl.

https://images.ctfassets.net/yj8364fopk6s/qFVNISVydYfkZflRaU158/2d175d0981eb971448eb4d4815718dff/stats.sidnlabs.nl-WebRPKI-20250305.png

Figuur 2: Het aandeel RPKI-beveiligde webservers onder het .nl-domein. [bron: SIDN Labs]

Beveiligingsinfrastructuur

Wat wij hierboven RPKI noemen is eigenlijk maar een deel van het verhaal. Strikt genomen refereert RPKI alleen naar de PKI-infrastructuur zoals die door de RIR's en LIR's is opgetuigd. Op deze infrastructuur is vervolgens de Route Origin Validation (ROV)-beveiliging ontwikkeld, die middels Route Origination Authorization (ROA)-records een cryptografische koppeling legt tussen AS-nummers en prefixen (een autorisatie). Alle ROA-informatie wordt verzameld en gevalideerd door lokale RPKI-caches, die de gevalideerde informatie vervolgens via RTR beschikbaar stellen voor de lokale routers (de routeinformatie zelf wordt nog steeds via BGP gedistribueerd).

ROV-validatie wordt nu al door alle backbone-providers en grote internetdienstenaanbieders toegepast. Bijna iedereen die veel dataverkeer doorgeeft gebruikt ROV. Daarmee is de adoptie door kleinere spelers minder van belang. Foutieve route-aankondigingen beschermd met ROV worden nu immers hogerop in de infrastructuur tegengehouden.

Verschillende RPKI-gebaseerde beveiligingsprotocollen

Naast het ROV-protocol zijn er nog 2 aanvullende beveiligingsprotocollen op de RPKI-infrastructuur ontwikkeld, die de internetroutering verder moeten beveiligen. De eerste is BGPsec, dat het BGP-protocol uitbreidt met Secure Paths. Daarbij wordt de pad-informatie die bij elke hop wordt aangevuld opnieuw ondertekend, net als het AS-nummer van de ontvangende partij. Zo kan een router verifiëren dat een BGP update-bericht inderdaad voor hem (dat wil zeggen: voor zijn netwerk) bestemd is, en dat het opgebouwde pad vanaf de origin authentiek is.

Het tweede protocol is ASPA (Autonomous System Provider Authorization), dat cryptografisch vastlegt welke AS-nummers route-aankondigingen van een bepaald AS-nummer mogen propageren. Het idee is dat organisaties publiceren wie hun upstream (transit) providers zijn, en dat routers die informatie kunnen gebruiken om de individuele schakels in een pad te verifiëren.

Wat dat betreft lijkt RPKI qua architectuur wel op de DNSSEC-beveiliging voor het DNS-systeem: met RPKI wordt een gedistribueerde PKI-infrastructuur aangelegd, waarop vervolgens allerlei verschillende beveiligingsprotocollen gebouwd kunnen worden. Bovendien is RPKI een aanvulling op DNSSEC: DNSSEC garandeert de juiste vertaling van domeinnamen naar IP-adressen, terwijl RPKI zorgt dat verkeer naar die IP-adressen inderdaad op de juiste plek belandt.

Route-beveiliging

De stack van RPKI-beveiligingsprotocollen lost 3 categorieën van problemen op:

• Zogenaamde "misoriginated destinations": route-aankondigingen waarbij een beheerder een (type)fout heeft gemaakt en een aankondiging voor een verkeerd prefix de wereld instuurt (e.g. onbedoeld een bestemming claimt die niet bij hem thuishoort). Dit is gelijk het meest voorkomende probleem (orde grootte 100 keer per dag) en wordt opgelost met ROV.

• Routelekken (in detail besproken in RFC 7908), waarbij door een misconfiguratie bij een legitieme partij de route naar de ene upstream provider of peer per ongeluk naar een andere upstream provider of peer wordt doorgegeven. Op die manier ontstaat een sluiproute die technisch misschien wel werkt maar niet de bedoeling is. Verkeer tussen 2 onafhankelijke upstream providers kan zo bijvoorbeeld over een smalbandige interne verbinding binnendoor geleid worden. Dit probleem komt veel minder voor (orde grootte eens per dag) en wordt opgelost met ASPA.

• Spoofing, waarbij kwaadwillenden via BGP proberen om routes van anderen naar zich toe te halen (BGP hijacking), typisch bedoeld voor criminele activiteiten. Dit probleem komt gelukkig zelden voor (een paar keer per jaar) en wordt opgelost met BGPsec (en met ASPA als dat op grote schaal toegepast zou worden).

Complementair

Hoewel ASPA regelmatig wordt neergezet als een efficiënter alternatief voor BGPsec, benadrukt Snijders dat de 3 RPKI-beveiligingsprotocollen complementair zijn en verschillende problemen oplossen. "Het mooie aan RPKI is dat de makkelijkst te implementeren beveiliging (ROV) gelijk de meest voorkomende problemen oplost. ASPA vraagt al wat meer verwerkingscapaciteit op de BGP-systemen, maar het leeuwendeel van het werk vindt nog steeds plaats op de RPKI-infrastructuur. BGPsec ten slotte is een zwaar protocol, dat vanwege de benodigde verwerkingskracht waarschijnlijk pas op een volgende generatie router-systemen ingezet zal kunnen worden. Waar ASPA geen cryptografische bewerkingen vereist op de routers zelf, moeten de routers voor BGPsec wel steeds een digitale handtekening genereren bij het doorzetten van een route-aankondiging. Spoofing vereist echter een geavanceerde aanval en vanwege die hoge kennisdrempel komen dit soort aanvallen gelukkig zelden voor."

Waar ROV een heel snelle adoptie heeft doorgemaakt, is het voor de andere 2 RPKI-protocollen nog net te vroeg. "Wie nu RPKI met ROV heeft draaien, zal een dezer jaren de vervolgstap naar ASPA kunnen maken," zegt Snijders. "Op dit moment is de adoptie nog verwaarloosbaar, maar ASPA wordt nu al breder ondersteund dan BGPsec in de open-source pakketten OpenBGPD, BIRD en FFRouting. Deze pakketten worden vooral gebruikt door de internetexchanges. Als 100 van die grote exchanges ASPA aanzetten, heeft dat gelijk een enorme impact. De laatste generatie routersystemen die door andere partijen worden ingezet, heeft inmiddels ook genoeg verwerkingskracht voor ASPA aan boord. De grote leveranciers ondersteunen deze mogelijkheid echter nog niet omdat ASPA zelf nog niet volledig uitontwikkeld is." Snijders verwacht dat het leeuwendeel van de ASPA-specificatie op zijn best volgend jaar als RFC gepubliceerd kan worden. Met name de uitwerking van het RTR-protocol heeft nog aandacht nodig.

BGPsec daarentegen is in theoretisch opzicht allang klaar, maar de tooling op internetschaal is er nog niet. "Als idee is BGPsec zijn tijd vooruit," aldus Snijders. "De implementatie vraagt te veel rekenkracht van de huidige apparatuur, wat de toepassing ervan nogal prijzig zou maken. Vandaar ook dat de afgelopen jaren nauwelijks vooruitgang is gemaakt met de doorontwikkeling van het BGPsec-protocol. Ik verwacht dat de volgende generatie routersystemen wel genoeg rekenkracht aan boord zal hebben om BGPsec te kunnen draaien."

Laaghangend fruit

"Routebeveiliging is sowieso een probleem dat meerdere decennia nodig heeft om volledig geïmplementeerd te worden," aldus Snijders. "En we zijn nog maar net begonnen om het laaghangende fruit te plukken. De markt voor de grootste routersystemen van Cisco en Juniper is maar honderden tot duizenden systemen groot, dus op de ontwikkeling van die apparatuur kunnen veel minder ingenieurs ingezet worden dan op kleinere computersystemen waarvan er honderdduizenden verkocht worden. Vandaar ook dat de productcycli in deze markt veel langer zijn. De ontwikkeling van een major softwarerelease bij Cisco duurt al meerdere jaren, waarna die update voor de uitrol bij bedrijven als KPN en Ziggo ook nog eens uitgebreid getest moet worden. Daarmee kom je op een doorlooptijd van idee naar gebruik die misschien wel 5 jaar bedraagt. En voor de hardware van de core-routers in de internet-backbone moet je echt denken aan een update-cyclus van 10, 15 jaar."

Het goede nieuws is dat afgelopen jaar diverse nieuwe inzichten in de vorm van RFC's zijn gepubliceerd, welke de RPKI-stack completer en robuuster maken. En na RPKI/ROV krijgt ASPA nu echt momentum. "Het gaat heel goed met de adoptie van RPKI," zegt Snijders. "Voor wie nu ROV gebruikt is ASPA de volgende stap. Ik verwacht dat de ondersteuning ervan deze jaren middels een software-update in de bestaande moderne routersystemen beschikbaar zal komen."