RPKI og ROA'er: hvad købere og lejere faktisk skal gøre

Hvorfor det holdt op med at være valgfrit

I årevis var RPKI noget, operatører var enige om var en god idé, men ikke fik gjort noget ved. Det ændrede sig, da de store netværk begyndte faktisk at håndhæve det. Store transitudbydere, de store cloudplatforme og flere store indholdsnetværk udfører nu Route Origin Validation og kasserer routes, der kommer tilbage som ugyldige.

Den praktiske konsekvens er barsk. Et præfiks med en defekt ROA er ikke bare ubeskyttet, det kan ikke nås fra en voksende del af internettet. Og fejlen er delvis og forvirrende: nogle brugere når dig, andre gør ikke, og traceroutes ser fine ud, uanset hvorfra du tilfældigvis tester.

Køber eller lejer du adresser, er dette den konfigurationsdetalje, der med størst sandsynlighed koster dig en dag.

Hvad en ROA faktisk er

RPKI er et system af kryptografiske attesteringer knyttet til adresseregistret. Det objekt, der betyder noget i hverdagen, er Route Origin Authorization, eller ROA, og den indeholder præcis tre ting:

• Præfikset. For eksempel 192.0.2.0/24.
• Origin-AS'et. Det autonomous system number, der har lov til at annoncere det.
• En maksimal længde. Det længste præfiks, der må annonceres inden for blokken.

Det er hele objektet. Det er en signeret erklæring fra adresseindehaveren, der siger “dette AS har lov til at annoncere disse adresser som origin, op til denne bestemte størrelse”. Routere læser den ikke direkte. Validatorer henter og verificerer RPKI-dataene og sender resultatet til routerne, som så klassificerer hver route som gyldig, ugyldig eller ikke fundet.

Hver route ender i en af tre tilstande. Valid: en ROA dækker præfikset, og annonceringen passer med den. NotFound, som mange værktøjer viser som Unknown: ingen ROA dækker præfikset overhovedet. Invalid: en ROA dækker præfikset, men annonceringen modsiger den, enten fra det forkerte AS eller med et præfiks, der er længere, end den maksimale længde tillader.

Rækkefølgen af de tilstande betyder mere, end folk forventer. En route uden ROA accepteres stadig næsten overalt: den er ubeskyttet, men den kommer igennem. En route, der kommer tilbage som Invalid, smides væk af hvert netværk, der håndhæver validering. Ingen ROA er bedre end en forkert ROA. Målet er en korrekt, men er detaljerne ikke på plads den dag, du annoncerer, er det langt sikrere at annoncere uden ROA og tilføje den, når de er, end at offentliggøre en, der modsiger det, du sender.

Hvem der opretter den, afhænger af, hvordan du fik adresserne

Det her snubler folk konstant over, så det er værd at være tydelig.

Har du købt blokken, er den registreret til dig, og du opretter selv ROA'en i dit registers portal eller beder din sponsoring LIR om at oprette den, hvis den har forholdet til registret på dine vegne. Gør det, efter at overdragelsen er gennemført, ikke før, fordi objektet skal oprettes under den nye indehaver. Købte legacy-adresser i RIPE NCC's region kræver en kontrakt med RIPE NCC eller en sponsoring LIR, før de overhovedet kan have en ROA (RIPE NCC).

Lejer du, er blokken ikke registreret til dig, og du kan ikke oprette ROA'en. Indehaveren gør det for dit ASN. Det betyder, at du på forhånd skal fortælle to ting: det ASN, du vil annoncere fra, og om du har tænkt dig at annoncere noget mere specifikt end hele blokken. En lejeaftale, hvor ROA'en ikke er oprettet for dit ASN, validerer som ugyldig i det øjeblik, du annoncerer.

Annoncerer du via en cloududbyder under BYOIP, skal ROA'en som regel nævne udbyderens ASN frem for dit, fordi dens netværk er origin for routen: AS16509 og AS14618 hos AWS, AS8075 hos Azure, AS396982 hos Google Cloud på dets Premium-niveau. Nogle udbydere lader dig i stedet annoncere fra dit eget ASN, enten over din egen BGP-session (Vultr, Cherry Servers) eller som en “bring your own ASN”-mulighed oven på BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Så nævner en ROA dit ASN, og AWS og Oracle Cloud vil også have en, der nævner deres. De fleste udbydere dokumenterer det ASN, ROA'en skal nævne, og nogle få, blandt dem Gcore, oplyser det kun, når du spørger, så tjek, før du opretter noget; vores vejledninger pr. udbyder lister dem.

De to fejl, der skaber nedbrud

Næsten alle RPKI-fejl i den virkelige verden handler om den maksimale længde.

For tilladende. En ROA for 192.0.2.0/24 med en maksimal længde på /32 betyder, at enhver annoncering af enhver størrelse inden for blokken validerer. Det ødelægger meget af pointen: en kaprer, der annoncerer en mere specifik route fra dit AS-nummer, kommer stadig tilbage som gyldig, og mere specifikke routes vinder i BGP. Den sikre standard er at sætte den maksimale længde lig med præfiksets længde, medmindre du har en konkret grund til andet.

For streng. Annoncerer du en /24, der er dækket af en ROA, og skal du senere dele den op i to /25'er til trafikstyring, bliver de /25'er ugyldige med det samme og forsvinder fra en stor del af internettet. Planlægger du at annoncere mere specifikke præfikser, skal ROA'en tillade det, før du begynder.

Reglen, der undgår begge: lad ROA'en beskrive præcis det, du faktisk annoncerer, og opdater den i samme ændringsvindue som enhver routingændring, ikke bagefter.

ASPA: det næste lag

En ROA beskytter det første led i en route: hvem der må være origin for den. Den siger intet om stien derefter, og det er der, route leaks sker, når et netværk sender routes videre, som det burde have holdt for sig selv. ASPA, Autonomous System Provider Authorization, dækker en del af det hul.

Et ASPA-objekt signeres af indehaveren af et AS-nummer og lister de AS'er, der er dets upstream-udbydere. Netværk, der validerer det, kan afvise en sti, hvor dit AS ser ud til at nå internettet gennem en, der ikke er din udbyder. Det er en kommende IETF-standard. RIPE NCC beskriver det som klar til brug ved signering, og ARIN og APNIC lader også indehavere signere ASPA'er (registrene sammenlignet).

• Har du dit eget ASN, så offentliggør en ASPA, der lister hver upstream, som bærer dine routes til internettet. Udelad peers og dine egne kunder.
• Hold den opdateret. En udbyder, der mangler i objektet, kan få dine routes via den udbyder afvist af netværk, der håndhæver ASPA, så tilføj en ny transit, før du tænder den, og fjern en gammel, efter du har slukket den.
• Tager du dit eget ASN med til en cloud? AWS anbefaler en ASPA, der lister AS16509 og AS14618 som udbydere af dit ASN; uden dem fejler de routes, den genannoncerer for dig, ASPA-valideringen.
• Lejer du? ASPA hører til dit ASN, ikke til præfikset, så det er dit at offentliggøre, ikke vores.

Tjeklisten

Før adresserne bærer produktionstrafik:

• ROA'en findes for det korrekte præfiks og det korrekte origin-AS.
• Den maksimale længde passer med din reelle plan for annonceringer.
• IRR route-objekter er også på plads. RPKI har ikke erstattet dem. Masser af upstreams bygger stadig præfiksfiltre ud fra IRR-data, så en gyldig ROA uden et matchende route-objekt får dig stadig filtreret.
• ASPA lister hver upstream, hvis du offentliggør en, og ingen peers eller kunder.
• Valider udefra. Tjek fra et eksternt looking glass eller en RPKI-validator, ikke fra dit eget netværk, som gladeligt accepterer dine egne routes.
• Ryd op, når du går. Når en lejeaftale slutter, eller du holder op med at annoncere en blok, bør ROA'en trækkes tilbage eller opdateres. En forældet ROA, der peger på et ASN, som ikke længere annoncerer adresserne, er et problem for den, der får dem næste gang.

Hvor RTM Networks passer ind

Vi opretter og vedligeholder ROA'er som en del af både leje og sponsorat frem for som et tillæg (lej IPv4, PI- og ASN-sponsorat). Ved leje fortæller du os det ASN, du vil annoncere fra, eller den cloududbyder, du tager adresserne med til, og om du har brug for mere specifikke præfikser, så er ROA'en konfigureret før overleveringen. For sponsorerede ressourcer styrer vi RPKI-konfigurationen sammen med de andre registerobjekter.

Overtager du adresser fra et andet sted, afhænger det af vejen, hvem der sætter RPKI op: en køber gør det selv for blokken, og ved leje gør udlejeren det. Vi kan tjekke, om der findes en ROA for blokken, og om den i så fald er gyldig.