RPKI och route origin validation är ett område där små designval ofta avgör om kontrollen blir robust eller bara ser bra ut på papper. RPKI och Route Origin Validation ger nätoperatörer ett sätt att kontrollera om ett autonomt system är auktoriserat att originera ett visst IP-prefix.
RPKI och route origin validation i praktiken
Första byggstenen: ROA binder prefix och max prefix length till ett tillåtet origin AS. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: BGP-route kan bli valid, invalid eller not found beroende på RPKI-data. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: ROV är en policy hos den validerande operatören och RPKI stoppar inte alla BGP-angrepp. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Fel maxLength eller fel origin kan oavsiktligt göra legitima annonser invalid. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Praktisk införandeordning
- Inventera egna annonserade prefix och origin AS.
- Skapa ROA med minsta nödvändiga maxLength.
- Övervaka valideringsstatus externt.
- Samordna förändringar med routingteam och upstreams.
- Testa ny prefixannonsering mot RPKI-status innan bred change.
För RPKI och route origin validation håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Så kan det se ut
Om ett /16 normalt annonseras från ett AS men verksamheten ibland annonserar /24 för trafikstyrning måste ROA-designen spegla det medvetet. Annars kan en legitim change se ut som en invalid route.
Tre risker i implementationen
- Att sätta maxLength bredare än routingdesignen kräver.
- Att ändra origin AS utan att uppdatera ROA.
- Att tro att valid RPKI-status betyder att hela AS-path är legitim.
När jag anser ändringen färdig
För RPKI och route origin validation vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Egna normala prefix visas som valid.
- Planerad deaggregation omfattas endast när den är avsedd.
- Invalid status larmar innan routingincident blir långvarig.
Ett negativt test hör också till RPKI och route origin validation: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
RPKI och route origin validation – minska risken för felaktiga BGP-rutter handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.