RPKI och ROA: vad köpare och hyresgäster faktiskt behöver göra

Varför det inte längre är frivilligt

I åratal var RPKI något operatörer var överens om var en bra idé och aldrig kom sig för med. Det ändrades när de stora näten faktiskt började tillämpa det. Stora transitleverantörer, de stora molnplattformarna och flera stora innehållsnät utför nu Route Origin Validation och kastar routes som blir invalid.

Den praktiska följden är brutal. Ett prefix med en trasig ROA är inte bara oskyddat, det är onåbart från en växande del av internet. Och felet är partiellt och förvirrande: vissa användare når dig, andra inte, och traceroutes ser bra ut varifrån du än råkar testa.

Köper eller hyr du adressutrymme är det här den enskilda konfigurationsdetalj som mest sannolikt kostar dig en dag.

Vad en ROA faktiskt är

RPKI är ett system av kryptografiska intyg kopplade till adressregistret. Objektet som spelar roll i vardagen är Route Origin Authorization, eller ROA, och den innehåller exakt tre saker:

• Prefixet. Till exempel 192.0.2.0/24.
• Ursprungs-AS:et. Det AS-nummer som får annonsera det.
• En maximal längd. Det längsta prefix som får annonseras inom blocket.

Det är hela objektet. Det är ett signerat intyg från adressinnehavaren som säger ”det här AS:et får vara ursprung för det här utrymmet, upp till den här storleken”. Routrar läser det inte direkt. Validerare hämtar och verifierar RPKI-datan och matar resultatet till routrarna, som sedan klassar varje route som valid, invalid eller not-found.

Varje route hamnar i ett av tre tillstånd. Valid: en ROA täcker prefixet och annonseringen stämmer med den. NotFound, som många verktyg visar som Unknown: ingen ROA täcker prefixet alls. Invalid: en ROA täcker prefixet, men annonseringen motsäger den, antingen från fel AS eller med ett prefix längre än den maximala längden tillåter.

Ordningen mellan tillstånden spelar större roll än folk tror. En route utan ROA godtas fortfarande nästan överallt: den är oskyddad, men den kommer fram. En route som blir Invalid kastas av varje nät som tillämpar validering. Ingen ROA är bättre än en felaktig ROA. Målet är en korrekt, men om detaljerna inte är klara den dag du annonserar är det mycket säkrare att annonsera utan ROA och lägga till den när de är det än att publicera en som motsäger det du skickar.

Vem som skapar den beror på hur du fick utrymmet

Det här ställer ständigt till det för folk, så det är värt att vara tydlig.

Om du köpte blocket är det registrerat på dig och du skapar ROA:n själv i registrets portal, eller ber din sponsrande LIR skapa den om en sådan håller relationen med registret åt dig. Gör det efter att överföringen är klar, inte före, eftersom objektet måste skapas under den nya innehavaren. Köpt legacy-utrymme i RIPE NCC:s region behöver ett avtal med RIPE NCC eller en sponsrande LIR innan det över huvud taget kan ha en ROA (RIPE NCC).

Om du hyr är blocket inte registrerat på dig och du kan inte skapa ROA:n. Innehavaren gör det, för ditt ASN. Det betyder att du måste tala om två saker från början: det ASN du ska annonsera från, och om du tänker annonsera något mer specifikt än hela blocket. En hyra där ROA:n inte har skapats för ditt ASN blir invalid i samma ögonblick som du annonserar.

Om du annonserar via en molnleverantör med BYOIP måste ROA:n oftast ange leverantörens ASN i stället för ditt, eftersom deras nät är routens ursprung: AS16509 och AS14618 hos AWS, AS8075 hos Azure, AS396982 hos Google Cloud på dess Premium-nivå. Vissa leverantörer låter dig i stället vara ursprung från ditt eget ASN, antingen över en egen BGP-session (Vultr, Cherry Servers) eller som ett alternativ med ”bring your own ASN” ovanpå BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Då anger en ROA ditt ASN, och AWS och Oracle Cloud vill dessutom ha en som anger deras. De flesta leverantörer dokumenterar vilket ASN ROA:n måste ange, och några få, bland dem Gcore, uppger det bara när du frågar, så kontrollera innan du skapar något; våra leverantörsguider listar dem.

De två misstagen som orsakar avbrott

Nästan allt verkligt RPKI-strul handlar om maximal längd.

För tillåtande. En ROA för 192.0.2.0/24 med en maximal längd på /32 betyder att varje annonsering av vilken storlek som helst inom blocket blir valid. Det motverkar mycket av poängen: en kapare som annonserar en mer specifik route från ditt AS-nummer blir fortfarande valid, och mer specifika routes vinner i BGP. Det säkra standardvalet är att sätta den maximala längden lika med prefixlängden om du inte har ett konkret skäl att låta bli.

För strikt. Om du annonserar ett /24 som täcks av en ROA och senare behöver dela upp det i två /25 för trafikstyrning, blir de /25:orna invalid direkt och försvinner från en stor del av internet. Planerar du att annonsera mer specifika routes måste ROA:n tillåta det innan du börjar.

Regeln som undviker båda: låt ROA:n beskriva exakt det du faktiskt annonserar, och uppdatera den i samma ändringsfönster som varje routingändring, inte efteråt.

ASPA: nästa lager

En ROA skyddar en routes första länk: vem som får vara dess ursprung. Den säger inget om vägen därefter, där route leaks uppstår, när ett nät skickar vidare routes som det borde ha behållit för sig själv. ASPA, Autonomous System Provider Authorization, täcker en del av det glappet.

Ett ASPA-objekt signeras av innehavaren av ett AS-nummer och listar de AS som är dess upstreamleverantörer. Nät som validerar det kan avvisa en väg där ditt AS verkar nå internet via någon som inte är din leverantör. Det är en framväxande IETF-standard. RIPE NCC beskriver det som klart att användas för signering, och ARIN och APNIC låter också innehavare signera ASPA (registren jämförda).

• Har du ett eget ASN, publicera en ASPA som listar varje upstream som bär dina routes till internet. Utelämna peers och dina egna kunder.
• Håll den aktuell. En leverantör som saknas i objektet kan få dina routes via den leverantören avvisade av nät som tillämpar ASPA, så lägg till en ny transit innan du slår på den och ta bort en gammal efter att du har stängt av den.
• Tar du med ditt eget ASN till ett moln? AWS rekommenderar en ASPA som listar AS16509 och AS14618 som leverantörer för ditt ASN; utan dem misslyckas ASPA-valideringen för de routes som AWS annonserar vidare åt dig.
• Hyr du? ASPA hör till ditt ASN, inte till prefixet, så det är ditt att publicera, inte vårt.

Checklistan

Innan utrymmet bär produktionstrafik:

• ROA finns för rätt prefix och rätt ursprungs-AS.
• Den maximala längden stämmer med din verkliga plan för annonseringen.
• Route-objekt i IRR finns också på plats. RPKI har inte ersatt dem. Många upstreams bygger fortfarande prefixfilter från IRR-data, så en giltig ROA utan matchande route-objekt gör ändå att du filtreras.
• ASPA listar varje upstream, om du publicerar en, och inga peers eller kunder.
• Validera externt. Kontrollera från en extern looking glass eller en RPKI-validerare, inte från ditt eget nät, som gärna godtar dina egna routes.
• Städa upp när du lämnar. När en hyra upphör eller du slutar annonsera ett block ska ROA:n dras tillbaka eller uppdateras. En inaktuell ROA som pekar på ett ASN som inte längre annonserar utrymmet är ett problem för den som får det härnäst.

Var RTM Networks passar in

Vi skapar och underhåller ROA:er som en del av både hyra och sponsring, inte som ett tillägg (hyr IPv4, sponsring av PI och ASN). För en hyra, berätta vilket ASN du ska annonsera från, eller vilken molnleverantör du tar med utrymmet till, och om du behöver mer specifika routes, så är ROA:n konfigurerad före överlämnandet. För sponsrade resurser hanterar vi RPKI-konfigurationen tillsammans med de andra registerobjekten.

Tar du över utrymme från annat håll beror det på vägen vem som sätter upp RPKI: en köpare gör det för själva blocket, och vid en hyra gör uthyraren det. Vi kan kontrollera om det finns en ROA för blocket och, om den finns, om den är giltig.