RPKI i ROA: šta kupci i zakupci zaista treba da urade

Zašto ovo više nije opciono

Godinama je RPKI bio nešto za šta su se operateri slagali da je dobra ideja, a do čega nisu stizali. To se promenilo kada su velike mreže počele da ga zaista sprovode. Veliki tranzitni provajderi, velike cloud platforme i nekoliko velikih mreža za sadržaj sada sprovode Route Origin Validation i odbacuju rute koje se vrate kao nevažeće.

Praktična posledica je surova. Prefiks sa pokvarenim ROA nije samo nezaštićen, nego je nedostupan sa sve većeg dela interneta. A kvar je delimičan i zbunjujući: neki korisnici stižu do Vas, neki ne, a traceroute izgleda u redu odakle god da testirate.

Ako kupujete ili zakupljujete adresni prostor, ovo je detalj konfiguracije koji će Vas najverovatnije koštati jedan dan.

Šta je zapravo ROA

RPKI je sistem kriptografskih potvrda vezanih za registar adresa. Objekat koji je važan iz dana u dan jeste Route Origin Authorization, ili ROA, i on sadrži tačno tri stvari:

• Prefiks. Na primer 192.0.2.0/24.
• AS porekla. Broj autonomnog sistema kome je dozvoljeno da ga najavljuje.
• Maksimalnu dužinu. Najduži prefiks koji sme da se najavljuje unutar tog bloka.

To je ceo objekat. To je potpisana izjava nosioca adresa koja kaže „ovom AS-u je dozvoljeno da bude poreklo ovog prostora, do ove određene veličine“. Ruteri ga ne čitaju direktno. Validatori preuzimaju i proveravaju RPKI podatke i rezultat prosleđuju ruterima, koji zatim svaku rutu svrstavaju kao važeću, nevažeću ili nepronađenu.

Svaka ruta izlazi u jednom od tri stanja. Valid: ROA pokriva prefiks i najava mu odgovara. NotFound, koje mnogi alati prikazuju kao Unknown: nijedan ROA uopšte ne pokriva prefiks. Invalid: ROA pokriva prefiks, ali mu najava protivreči, bilo sa pogrešnog AS-a, bilo sa prefiksom dužim nego što maksimalna dužina dozvoljava.

Redosled tih stanja važniji je nego što ljudi očekuju. Ruta bez ROA i dalje se prihvata skoro svuda: nezaštićena je, ali prolazi. Ruta koja se vrati kao Invalid odbacuje se u svakoj mreži koja sprovodi validaciju. Bolje je bez ROA nego sa pogrešnim ROA. Cilj je ispravan ROA, ali ako detalji nisu rešeni na dan najave, najava bez ROA i njegovo dodavanje kada budu rešeni daleko je bezbednija od objavljivanja onog koji protivreči onome što šaljete.

Ko ga pravi zavisi od toga kako ste dobili prostor

Ovo ljude stalno zbunjuje, pa vredi biti izričit.

Ako ste blok kupili, on je registrovan na Vas i ROA pravite sami u portalu svog registra, ili tražite od svog sponzorskog LIR-a da ga napravi ako on drži odnos sa registrom u Vaše ime. Uradite to posle završetka transfera, ne pre, jer objekat mora da se napravi pod novim nosiocem. Kupljeni legacy prostor u regionu RIPE NCC-a mora imati ugovor sa RIPE NCC-om ili sponzorskim LIR-om pre nego što uopšte može imati ROA (RIPE NCC).

Ako zakupljujete, blok nije registrovan na Vas i ne možete da napravite ROA. To radi nosilac, za Vaš ASN. To znači da mu unapred morate reći dve stvari: ASN sa kog ćete najavljivati i da li nameravate da najavljujete išta specifičnije od celog bloka. Zakup kod kojeg ROA nije napravljen za Vaš ASN validiraće se kao nevažeći u trenutku kada ga najavite.

Ako najavljujete preko cloud provajdera putem BYOIP-a, ROA obično mora da navede ASN provajdera umesto Vašeg, jer je njegova mreža poreklo rute: AS16509 i AS14618 kod AWS-a, AS8075 kod Azure-a, AS396982 kod Google Cloud-a na njegovom Premium nivou. Neki provajderi Vam dozvoljavaju da umesto toga budete poreklo sa sopstvenog ASN-a, bilo preko sopstvene BGP sesije (Vultr, Cherry Servers), bilo kao opciju „bring your own ASN“ povrh BYOIP-a (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Tada ROA navodi Vaš ASN, a AWS i Oracle Cloud žele i jedan koji navodi njihov. Većina provajdera dokumentuje ASN koji ROA mora da navede, a nekoliko, među njima Gcore, daje ga samo kada pitate, pa proverite pre nego što išta napravite; naši vodiči po provajderima ih navode.

Dve greške koje izazivaju prekide

Skoro svi stvarni kvarovi RPKI-ja svode se na maksimalnu dužinu.

Previše popustljiva. ROA za 192.0.2.0/24 sa maksimalnom dužinom /32 znači da se validira svaka najava bilo koje veličine unutar tog bloka. To poništava velik deo smisla: otmičar koji najavljuje specifičniju rutu sa Vašeg AS broja i dalje se vraća kao važeći, a specifičnije rute pobeđuju u BGP-u. Bezbedna podrazumevana vrednost je maksimalna dužina jednaka dužini prefiksa, osim ako nemate konkretan razlog za drugačije.

Previše stroga. Ako najavljujete /24 pokriven ROA-om, a kasnije morate da ga podelite na dva /25 radi upravljanja saobraćajem, ti /25 odmah postaju nevažeći i nestaju sa velikog dela interneta. Ako planirate da najavljujete specifičnije rute, ROA to mora da dozvoli pre nego što počnete.

Pravilo koje izbegava oba: neka ROA opisuje tačno ono što zaista najavljujete, i ažurirajte ga u istom prozoru za izmene kao i svaku izmenu rutiranja, a ne posle.

ASPA: sledeći sloj

ROA štiti prvu kariku rute: ko sme da bude njeno poreklo. Ne kaže ništa o putanji posle toga, a tu nastaju curenja ruta (route leaks), kada mreža prosledi rute koje je trebalo da zadrži za sebe. ASPA, Autonomous System Provider Authorization, pokriva deo te praznine.

ASPA objekat potpisuje nosilac AS broja i on navodi AS-ove koji su njegovi upstream provajderi. Mreže koje ga validiraju mogu da odbiju putanju u kojoj Vaš AS naizgled stiže do interneta preko nekoga ko nije Vaš provajder. To je IETF standard u nastajanju. RIPE NCC ga opisuje kao spreman za upotrebu pri potpisivanju, a ARIN i APNIC takođe dozvoljavaju nosiocima da potpisuju ASPA (poređenje registara).

• Ako imate sopstveni ASN, objavite ASPA koji navodi svaki upstream koji Vaše rute nosi ka internetu. Izostavite peer-ove i sopstvene klijente.
• Održavajte ga ažurnim. Provajder koji nedostaje u objektu može dovesti do toga da mreže koje sprovode ASPA odbiju Vaše rute preko tog provajdera, pa dodajte novi tranzit pre nego što ga uključite, a uklonite stari posle isključenja.
• Unosite sopstveni ASN u cloud? AWS preporučuje ASPA koji navodi AS16509 i AS14618 kao provajdere Vašeg ASN-a; bez njih, rute koje on ponovo najavljuje za Vas ne prolaze ASPA validaciju.
• Zakupljujete? ASPA pripada Vašem ASN-u, ne prefiksu, pa ga objavljujete Vi, a ne mi.

Kontrolna lista

Pre nego što prostor ponese produkcioni saobraćaj:

• ROA postoji za ispravan prefiks i ispravan AS porekla.
• Maksimalna dužina odgovara Vašem stvarnom planu najave.
• IRR route objekti su takođe na mestu. RPKI ih nije zamenio. Mnogi upstream-ovi i dalje prave filtere prefiksa iz IRR podataka, pa Vas važeći ROA bez odgovarajućeg route objekta i dalje dovodi do filtriranja.
• ASPA navodi svaki upstream, ako ga objavljujete, i nijedan peer ili klijent.
• Validirajte spolja. Proverite preko spoljnog looking glass-a ili RPKI validatora, a ne iz sopstvene mreže, koja će rado prihvatiti Vaše sopstvene rute.
• Počistite na izlasku. Kada se zakup završi ili prestanete da najavljujete blok, ROA treba povući ili ažurirati. Zastareli ROA koji pokazuje na ASN koji više ne najavljuje prostor problem je za onoga ko ga sledeći dobije.

Gde se uklapa RTM Networks

ROA pravimo i održavamo kao deo i zakupa i sponzorstva, a ne kao dodatak (zakup IPv4, sponzorstvo za PI i ASN). Kod zakupa, recite nam ASN sa kog ćete najavljivati, ili cloud provajdera kod kog unosite prostor, i da li Vam trebaju specifičnije rute, i ROA se podešava pre predaje. Za sponzorisane resurse, RPKI konfiguracijom upravljamo zajedno sa ostalim objektima u registru.

Ako preuzimate prostor od nekog drugog, ko podešava RPKI zavisi od puta: kupac to radi za sam blok, a kod zakupa to radi zakupodavac. Možemo da proverimo da li za blok postoji ROA i, ako postoji, da li je važeći.