RPKI og ROA-er: hva kjøpere og leietakere faktisk må gjøre

Hvorfor dette ikke lenger er valgfritt

I årevis var RPKI noe operatører var enige om var en god idé, men ikke fikk gjort. Det endret seg da de store nettverkene faktisk begynte å håndheve det. Store transittleverandører, de store skyplattformene og flere store innholdsnettverk utfører nå Route Origin Validation og forkaster ruter som kommer tilbake som ugyldige.

Den praktiske konsekvensen er brutal. Et prefiks med en ødelagt ROA er ikke bare ubeskyttet, det er utilgjengelig fra en voksende del av internettet. Og feilen er delvis og forvirrende: noen brukere når deg, andre ikke, og traceroutes ser fine ut fra der du tilfeldigvis tester.

Kjøper eller leier du adresserom, er dette den konfigurasjonsdetaljen som mest sannsynlig koster deg en dag.

Hva en ROA faktisk er

RPKI er et system av kryptografiske attester knyttet til adresseregisteret. Objektet som betyr noe i hverdagen, er Route Origin Authorization, eller ROA, og det inneholder nøyaktig tre ting:

• Prefikset. For eksempel 192.0.2.0/24.
• Opprinnelses-AS-et. AS-nummeret som har lov til å kunngjøre det.
• En maksimal lengde. Det lengste prefikset som kan kunngjøres innenfor blokken.

Det er hele objektet. Det er en signert erklæring fra adresseinnehaveren som sier «dette AS-et har lov til å kunngjøre dette adresserommet, opp til denne bestemte størrelsen». Rutere leser det ikke direkte. Validatorer henter og verifiserer RPKI-dataene og gir resultatet til ruterne, som så klassifiserer hver rute som gyldig, ugyldig eller ikke funnet.

Hver rute ender i én av tre tilstander. Valid: en ROA dekker prefikset, og kunngjøringen stemmer med den. NotFound, som mange verktøy viser som Unknown: ingen ROA dekker prefikset i det hele tatt. Invalid: en ROA dekker prefikset, men kunngjøringen motsier den, enten fra feil AS eller med et prefiks som er lengre enn den maksimale lengden tillater.

Rekkefølgen på disse tilstandene betyr mer enn folk tror. En rute uten ROA godtas fortsatt nesten overalt: den er ubeskyttet, men den kommer gjennom. En rute som kommer tilbake som Invalid, forkastes av hvert nettverk som håndhever validering. Ingen ROA er bedre enn en feil ROA. Målet er en riktig, men er detaljene ikke avklart den dagen du kunngjør, er det langt tryggere å kunngjøre uten ROA og legge den til når de er det, enn å publisere en som motsier det du sender.

Hvem som oppretter den, avhenger av hvordan du fikk adresserommet

Dette får folk til å snuble hele tiden, så det er verdt å være tydelig.

Har du kjøpt blokken, er den registrert på deg, og du oppretter ROA-en selv i registerets portal, eller ber sponsor-LIR-en din om å opprette den hvis en slik holder forholdet til registeret på dine vegne. Gjør det etter at overføringen er fullført, ikke før, fordi objektet må opprettes under den nye innehaveren. Kjøpt legacy-adresserom i RIPE NCC-regionen trenger en avtale med RIPE NCC eller en sponsor-LIR før det i det hele tatt kan ha en ROA (RIPE NCC).

Leier du, er blokken ikke registrert på deg, og du kan ikke opprette ROA-en. Innehaveren gjør det, for ditt ASN. Det betyr at du må fortelle innehaveren to ting på forhånd: ASN-et du skal kunngjøre fra, og om du har tenkt å kunngjøre noe mer spesifikt enn hele blokken. En leieavtale der ROA-en ikke er opprettet for ditt ASN, valideres som ugyldig i det øyeblikket du kunngjør.

Kunngjør du gjennom en skyleverandør med BYOIP, må ROA-en som regel nevne leverandørens ASN og ikke ditt, fordi leverandørens nettverk er opprinnelsen til ruten: AS16509 og AS14618 hos AWS, AS8075 hos Azure, AS396982 hos Google Cloud på Premium-nivået. Noen leverandører lar deg i stedet kunngjøre fra ditt eget ASN, enten over en egen BGP-sesjon (Vultr, Cherry Servers) eller som et «bring your own ASN»-alternativ i tillegg til BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Da nevner en ROA ditt ASN, og AWS og Oracle Cloud vil i tillegg ha en som nevner deres. De fleste leverandører dokumenterer hvilket ASN ROA-en må nevne, og noen få, blant dem Gcore, oppgir det bare når du spør, så sjekk før du oppretter noe; leverandørguidene våre lister dem.

De to feilene som fører til nedetid

Nesten all RPKI-svikt i praksis handler om maksimal lengde.

For romslig. En ROA for 192.0.2.0/24 med en maksimal lengde på /32 betyr at enhver kunngjøring av enhver størrelse innenfor blokken valideres. Det undergraver mye av poenget: en kaprer som kunngjør en mer spesifikk rute fra AS-nummeret ditt, kommer fortsatt tilbake som gyldig, og mer spesifikke ruter vinner i BGP. Den trygge standarden er å sette maksimal lengde lik prefikslengden, med mindre du har en konkret grunn til noe annet.

For streng. Kunngjør du en /24 dekket av en ROA, og senere må dele den i to /25-er for trafikkstyring, blir disse /25-ene ugyldige med en gang og forsvinner fra en stor del av internettet. Planlegger du å kunngjøre mer spesifikke ruter, må ROA-en tillate det før du begynner.

Regelen som unngår begge: la ROA-en beskrive nøyaktig det du faktisk kunngjør, og oppdater den i samme endringsvindu som enhver rutingendring, ikke etterpå.

ASPA: neste lag

En ROA beskytter det første leddet i en rute: hvem som kan være opprinnelsen. Den sier ingenting om veien etter det, som er der rutelekkasjer skjer, når et nettverk sender videre ruter det burde ha holdt for seg selv. ASPA, Autonomous System Provider Authorization, dekker en del av det hullet.

Et ASPA-objekt signeres av innehaveren av et AS-nummer og lister AS-ene som er dets upstream-leverandører. Nettverk som validerer det, kan avvise en vei der AS-et ditt ser ut til å nå internettet gjennom noen som ikke er leverandøren din. Det er en IETF-standard under utvikling. RIPE NCC beskriver det som klart til bruk for signering, og ARIN og APNIC lar også innehavere signere ASPA-er (registrene sammenlignet).

• Har du ditt eget ASN, publiser en ASPA som lister hver upstream-leverandør som frakter rutene dine til internettet. Utelat peerer og dine egne kunder.
• Hold den oppdatert. En leverandør som mangler i objektet, kan føre til at rutene dine gjennom den leverandøren avvises av nettverk som håndhever ASPA, så legg til en ny transitt før du slår den på, og fjern en gammel etter at du har slått den av.
• Tar du med eget ASN til en sky? AWS anbefaler en ASPA som lister AS16509 og AS14618 som leverandører for ditt ASN; uten dem feiler ASPA-valideringen for rutene AWS kunngjør videre for deg.
• Leier du? ASPA hører til ditt ASN, ikke til prefikset, så det er ditt å publisere, ikke vårt.

Sjekklisten

Før adresserommet frakter produksjonstrafikk:

• ROA finnes for riktig prefiks og riktig opprinnelses-AS.
• Maksimal lengde stemmer med den faktiske kunngjøringsplanen din.
• IRR-route-objekter er også på plass. RPKI har ikke erstattet dem. Mange upstream-leverandører bygger fortsatt prefiksfiltre fra IRR-data, så en gyldig ROA uten et matchende route-objekt gjør likevel at du blir filtrert.
• ASPA lister hver upstream-leverandør, hvis du publiserer en, og ingen peerer eller kunder.
• Valider eksternt. Sjekk fra et eksternt looking glass eller en RPKI-validator, ikke fra ditt eget nettverk, som gjerne godtar dine egne ruter.
• Rydd opp på vei ut. Når en leieavtale slutter eller du slutter å kunngjøre en blokk, bør ROA-en trekkes tilbake eller oppdateres. En utdatert ROA som peker på et ASN som ikke lenger kunngjør adresserommet, er et problem for den som får det neste gang.

Hvor RTM Networks passer inn

Vi oppretter og vedlikeholder ROA-er som del av både leie og sponsing, ikke som et tillegg (lei IPv4, PI- og ASN-sponsing). Ved leie, fortell oss ASN-et du skal kunngjøre fra, eller skyleverandøren du tar adresserommet med til, og om du trenger mer spesifikke ruter, så er ROA-en konfigurert før overleveringen. For sponsede ressurser styrer vi RPKI-konfigurasjonen sammen med de andre registerobjektene.

Overtar du adresserom fra et annet sted, avhenger det av veien hvem som setter opp RPKI: en kjøper gjør det for selve blokken, og ved leie gjør utleieren det. Vi kan sjekke om det finnes en ROA for blokken, og i så fall om den er gyldig.