RPKI a ROA: čo naozaj musia urobiť kupujúci a nájomcovia

Prečo to prestalo byť dobrovoľné

RPKI bolo roky niečím, na čom sa prevádzkovatelia zhodli, že je to dobrý nápad, a nedostali sa k tomu. Zmenilo sa to, keď ho veľké siete začali naozaj vymáhať. Hlavní poskytovatelia tranzitu, veľké cloudové platformy a viaceré veľké obsahové siete dnes vykonávajú Route Origin Validation a zahadzujú trasy, ktoré vyjdú ako neplatné.

Praktický dôsledok je tvrdý. Prefix s pokazeným ROA nie je len nechránený, je nedosiahnuteľný z rastúcej časti internetu. A zlyhanie je čiastočné a mätúce: niektorí používatelia sa k vám dostanú, iní nie, a traceroute vyzerá v poriadku odkiaľkoľvek, odkiaľ práve testujete.

Ak kupujete alebo prenajímate adresný priestor, toto je ten jediný detail konfigurácie, ktorý vás s najväčšou pravdepodobnosťou bude stáť deň.

Čo ROA v skutočnosti je

RPKI je systém kryptografických osvedčení naviazaných na register adries. Objekt, na ktorom záleží v každodennej praxi, je Route Origin Authorization, čiže ROA, a obsahuje presne tri veci:

• Prefix. Napríklad 192.0.2.0/24.
• Pôvodný AS. Číslo autonómneho systému, ktoré ho smie oznamovať.
• Maximálnu dĺžku. Najdlhší prefix, ktorý sa v rámci bloku smie oznamovať.

To je celý objekt. Je to podpísané vyhlásenie držiteľa adries, ktoré hovorí „tento AS smie oznamovať tento priestor, až do tejto konkrétnej veľkosti“. Routery ho nečítajú priamo. Validátory dáta RPKI stiahnu a overia a výsledok odovzdajú routerom, ktoré potom každú trasu zaradia ako platnú, neplatnú alebo nenájdenú.

Každá trasa vyjde v jednom z troch stavov. Valid: prefix pokrýva ROA a oznámenie mu zodpovedá. NotFound, ktorý mnohé nástroje zobrazujú ako Unknown: prefix nepokrýva vôbec žiadne ROA. Invalid: prefix pokrýva ROA, no oznámenie mu odporuje, buď z nesprávneho AS, alebo s prefixom dlhším, než maximálna dĺžka dovoľuje.

Poradie týchto stavov je dôležitejšie, než ľudia čakajú. Trasa bez ROA je stále takmer všade prijatá: je nechránená, ale prejde. Trasa, ktorá vyjde ako Invalid, je zahodená každou sieťou, ktorá validáciu vymáha. Žiadne ROA je lepšie ako zlé ROA. Cieľom je správne ROA, no ak v deň oznámenia nie sú podrobnosti dohodnuté, oznámiť bez ROA a pridať ho, keď budú, je oveľa bezpečnejšie ako zverejniť také, ktoré odporuje tomu, čo posielate.

Kto ho vytvára, závisí od toho, ako ste priestor získali

Tu sa ľudia neustále mýlia, preto sa oplatí byť konkrétny.

Ak ste blok kúpili, je registrovaný na vás a ROA si vytvoríte sami na portáli vášho registra, alebo požiadate vášho sponzorujúceho LIR, ak vo vašom mene drží vzťah s registrom. Urobte to po dokončení prevodu, nie skôr, pretože objekt musí byť vytvorený pod novým držiteľom. Kúpený priestor legacy v regióne RIPE NCC potrebuje zmluvu s RIPE NCC alebo so sponzorujúcim LIR, aby mohol mať ROA vôbec (RIPE NCC).

Ak máte priestor v prenájme, blok nie je registrovaný na vás a ROA vytvoriť nemôžete. Urobí to držiteľ, pre vaše ASN. To znamená, že mu vopred musíte povedať dve veci: ASN, z ktorého budete oznamovať, a či plánujete oznamovať niečo konkrétnejšie ako celý blok. Prenájom, pri ktorom ROA pre vaše ASN nebolo vytvorené, vyjde ako neplatný v momente, keď ho oznámite.

Ak oznamujete cez cloudového poskytovateľa v rámci BYOIP, ROA zvyčajne musí uvádzať ASN poskytovateľa, nie vaše, pretože trasu oznamuje jeho sieť: AS16509 a AS14618 pri AWS, AS8075 pri Azure, AS396982 pri Google Cloud na úrovni Premium. Niektorí poskytovatelia vám umožňujú namiesto toho oznamovať z vlastného ASN, buď cez vlastnú reláciu BGP (Vultr, Cherry Servers), alebo ako možnosť „bring your own ASN“ nad rámec BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Potom ROA uvádza vaše ASN a AWS a Oracle Cloud chcú aj také, ktoré uvádza ich ASN. Väčšina poskytovateľov dokumentuje ASN, ktoré musí ROA uvádzať, a niekoľko, medzi nimi Gcore, ho uvedie iba na požiadanie, preto si to overte skôr, než čokoľvek vytvoríte; naše návody k poskytovateľom ich uvádzajú.

Dve chyby, ktoré spôsobujú výpadky

Takmer všetky skutočné poruchy RPKI sa zúžia na maximálnu dĺžku.

Príliš voľné nastavenie. ROA pre 192.0.2.0/24 s maximálnou dĺžkou /32 znamená, že akékoľvek oznámenie akejkoľvek veľkosti vnútri bloku je platné. To popiera veľkú časť zmyslu: únosca, ktorý oznamuje konkrétnejšiu trasu z vášho čísla AS, stále vyjde ako platný a konkrétnejšie trasy v BGP vyhrávajú. Bezpečné predvolené nastavenie je nastaviť maximálnu dĺžku rovnú dĺžke prefixu, pokiaľ nemáte konkrétny dôvod inak.

Príliš prísne nastavenie. Ak oznamujete /24 pokrytý ROA a neskôr ho potrebujete pre riadenie prevádzky rozdeliť na dva /25, tieto /25 sa okamžite stanú neplatnými a zmiznú z veľkej časti internetu. Ak plánujete oznamovať konkrétnejšie prefixy, ROA s tým musí počítať skôr, než začnete.

Pravidlo, ktoré predíde obom: nech ROA opisuje presne to, čo naozaj oznamujete, a aktualizujte ho v tom istom okne zmien ako akúkoľvek zmenu smerovania, nie potom.

ASPA: ďalšia vrstva

ROA chráni prvý článok trasy: kto ju smie oznamovať ako pôvodca. O ceste potom nehovorí nič, a práve tam vznikajú úniky trás, keď sieť odovzdá ďalej trasy, ktoré si mala nechať pre seba. ASPA, Autonomous System Provider Authorization, pokrýva časť tejto medzery.

Objekt ASPA podpisuje držiteľ čísla AS a uvádza AS, ktoré sú jeho upstreamovými poskytovateľmi. Siete, ktoré ho validujú, môžu odmietnuť cestu, v ktorej sa zdá, že váš AS sa dostáva do internetu cez niekoho, kto nie je vaším poskytovateľom. Je to vznikajúci štandard IETF. RIPE NCC ho opisuje ako pripravený na podpisovanie a ARIN a APNIC tiež umožňujú držiteľom podpisovať ASPA (porovnanie registrov).

• Ak máte vlastné ASN, zverejnite ASPA so zoznamom všetkých upstreamov, ktoré nesú vaše trasy do internetu. Peerov a vlastných zákazníkov vynechajte.
• Udržiavajte ho aktuálne. Poskytovateľ, ktorý v objekte chýba, môže spôsobiť, že siete vymáhajúce ASPA odmietnu vaše trasy cez tohto poskytovateľa, preto nový tranzit pridajte pred jeho zapnutím a starý odstráňte po jeho vypnutí.
• Prinášate vlastné ASN do cloudu? AWS odporúča ASPA, ktoré uvádza AS16509 a AS14618 ako poskytovateľov vášho ASN; bez nich trasy, ktoré za vás ďalej oznamuje, neprejdú validáciou ASPA.
• Máte priestor v prenájme? ASPA patrí k vášmu ASN, nie k prefixu, takže ho zverejňujete vy, nie my.

Kontrolný zoznam

Skôr než priestor ponesie produkčnú prevádzku:

• ROA existuje pre správny prefix a správny pôvodný AS.
• Maximálna dĺžka zodpovedá vášmu skutočnému plánu oznámení.
• Objekty route v IRR sú tiež na mieste. RPKI ich nenahradilo. Mnohé upstreamy stále zostavujú filtre prefixov z dát IRR, takže platné ROA bez zodpovedajúceho objektu route vás aj tak nechá odfiltrovať.
• ASPA uvádza každý upstream, ak ho zverejňujete, a žiadnych peerov ani zákazníkov.
• Validujte zvonku. Kontrolujte z externého looking glass alebo validátora RPKI, nie z vlastnej siete, ktorá vaše vlastné trasy ochotne prijme.
• Pri odchode upracte. Keď prenájom skončí alebo prestanete blok oznamovať, ROA by malo byť stiahnuté alebo aktualizované. Zastarané ROA, ktoré ukazuje na ASN, ktoré priestor už neoznamuje, je problémom pre toho, kto ho dostane ďalej.

Kde pomôže RTM Networks

ROA vytvárame a udržiavame v rámci prenájmu aj sponzorstva, nie ako doplnok (prenájom IPv4, sponzorstvo PI a ASN). Pri prenájme nám povedzte ASN, z ktorého budete oznamovať, alebo cloudového poskytovateľa, ku ktorému priestor prinášate, a či potrebujete konkrétnejšie prefixy, a ROA bude nastavené pred odovzdaním. Pri sponzorovaných zdrojoch spravujeme konfiguráciu RPKI popri ostatných objektoch registra.

Ak preberáte priestor odinakiaľ, kto nastaví RPKI, závisí od cesty: kupujúci to robí pre samotný blok a pri prenájme prenajímateľ. Môžeme skontrolovať, či pre blok existuje ROA, a ak áno, či je platné.