RPKI i ROA: što kupci i najmoprimci zapravo trebaju napraviti

Zašto to više nije neobavezno

Godinama je RPKI bio nešto za što su se operateri slagali da je dobra ideja, a do čega nisu stizali. To se promijenilo kada su ga velike mreže počele stvarno provoditi. Veliki tranzitni pružatelji, velike platforme u oblaku i nekoliko velikih mreža sadržaja sada provode validaciju ishodišta rute (Route Origin Validation) i odbacuju rute koje se vrate kao nevaljane.

Praktična posljedica je gruba. Prefiks s neispravnim ROA-om nije samo nezaštićen, nego je nedostupan iz sve većeg dijela interneta. A kvar je djelomičan i zbunjujuć: neki korisnici do vas dolaze, neki ne, a traceroute izgleda u redu odakle god testirali.

Ako kupujete adresni prostor ili ga uzimate u najam, ovo je pojedinost konfiguracije koja će vas najvjerojatnije stajati cijelog dana posla.

Što je ROA zapravo

RPKI je sustav kriptografskih potvrda vezan uz registar adresa. Objekt koji je svakodnevno važan je Route Origin Authorization, ili ROA, i sadrži točno tri stvari:

• Prefiks. Primjerice 192.0.2.0/24.
• AS ishodišta. Broj autonomnog sustava kojemu je dopušteno najavljivati ga.
• Najveću duljinu. Najdulji prefiks koji se smije najaviti unutar tog bloka.

To je cijeli objekt. Riječ je o potpisanoj izjavi nositelja adresa koja kaže „ovaj AS smije biti ishodište ovog prostora, do ove određene veličine“. Usmjerivači ga ne čitaju izravno. Validatori dohvaćaju i provjeravaju RPKI podatke te rezultat prosljeđuju usmjerivačima, koji zatim svaku rutu razvrstavaju kao valid, invalid ili not-found.

Svaka ruta završava u jednom od tri stanja. Valid: ROA pokriva prefiks i najava mu odgovara. NotFound, što mnogi alati prikazuju kao Unknown: nijedan ROA uopće ne pokriva prefiks. Invalid: ROA pokriva prefiks, ali mu najava proturječi, bilo s pogrešnog AS-a, bilo s prefiksom duljim od dopuštene najveće duljine.

Redoslijed tih stanja važniji je nego što ljudi očekuju. Ruta bez ROA-a i dalje se prihvaća gotovo posvuda: nezaštićena je, ali prolazi. Rutu koja se vrati kao Invalid odbacuje svaka mreža koja provodi validaciju. Bolje je bez ROA-a nego s pogrešnim ROA-om. Cilj je ispravan ROA, ali ako pojedinosti na dan najave nisu riješene, najava bez ROA-a i njegovo dodavanje kada budu riješene daleko je sigurnije od objave ROA-a koji proturječi onome što šaljete.

Tko ga izrađuje ovisi o tome kako ste dobili prostor

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

Ako ste blok kupili, registriran je na vas i ROA izrađujete sami na portalu svog registra ili zamolite svoj sponzorski LIR da ga izradi ako on u vaše ime drži odnos s registrom. Učinite to nakon što se prijenos dovrši, a ne prije, jer se objekt mora izraditi pod novim nositeljem. Kupljeni legacy prostor u regiji RIPE NCC-a treba ugovor s RIPE NCC-om ili sponzorskim LIR-om prije nego što uopće može imati ROA (RIPE NCC).

Ako blok uzimate u najam, blok nije registriran na vas i ne možete izraditi ROA. Izrađuje ga nositelj, za vaš ASN. To znači da mu unaprijed morate reći dvije stvari: ASN s kojeg ćete najavljivati i namjeravate li najavljivati išta specifičnije od cijelog bloka. Najam kod kojeg ROA nije izrađen za vaš ASN validirat će se kao invalid u trenutku kada ga najavite.

Ako najavljujete preko pružatelja oblaka putem BYOIP-a, ROA obično mora navesti ASN pružatelja, a ne vaš, jer ishodište rute je njegova mreža: AS16509 i AS14618 kod AWS-a, AS8075 kod Azurea, AS396982 kod Google Clouda na njegovoj razini Premium. Neki pružatelji umjesto toga dopuštaju da ishodište bude vaš vlastiti ASN, bilo preko vaše vlastite BGP sesije (Vultr, Cherry Servers), bilo kao mogućnost „bring your own ASN“ uz BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Tada ROA navodi vaš ASN, a AWS i Oracle Cloud žele i ROA koji navodi njihov. Većina pružatelja dokumentira ASN koji ROA mora navesti, a nekoliko njih, među njima Gcore, daje ga samo na upit, pa provjerite prije nego što išta izradite; naši vodiči po pružateljima ih navode.

Dvije pogreške koje uzrokuju prekide

Gotovo svi stvarni kvarovi RPKI-ja svode se na najveću duljinu.

Previše popustljiva postavka. ROA za 192.0.2.0/24 s najvećom duljinom /32 znači da se svaka najava bilo koje veličine unutar tog bloka validira. To poništava velik dio smisla: otmičar koji najavljuje specifičniju rutu s vašeg AS broja i dalje se vraća kao valid, a specifičnije rute u BGP-u pobjeđuju. Sigurna zadana postavka je najveća duljina jednaka duljini prefiksa, osim ako nemate konkretan razlog za drukčije.

Prestroga postavka. Ako najavljujete /24 pokriven ROA-om, a kasnije ga morate razdvojiti u dva /25 radi upravljanja prometom, ti /25 odmah postaju invalid i nestaju iz velikog dijela interneta. Ako planirate najavljivati specifičnije prefikse, ROA to mora dopuštati prije nego što počnete.

Pravilo koje izbjegava oboje: neka ROA opisuje točno ono što stvarno najavljujete, a ažurirajte ga u istom terminu promjene kao i svaku promjenu usmjeravanja, a ne poslije.

ASPA: sljedeći sloj

ROA štiti prvu kariku rute: tko smije biti njezino ishodište. Ne govori ništa o putu nakon toga, a upravo se ondje događaju curenja ruta, kada mreža prosljeđuje rute koje je trebala zadržati za sebe. ASPA, Autonomous System Provider Authorization, pokriva dio te praznine.

Objekt ASPA potpisuje nositelj AS broja i navodi AS-ove koji su njegovi upstream pružatelji. Mreže koje ga validiraju mogu odbiti put u kojem se čini da vaš AS do interneta dolazi preko nekoga tko nije vaš pružatelj. To je IETF standard u nastajanju. RIPE NCC ga opisuje kao spremnog za potpisivanje, a ARIN i APNIC također nositeljima omogućuju potpisivanje ASPA objekata (usporedba registara).

• Ako imate vlastiti ASN, objavite ASPA koji navodi svaki upstream koji vaše rute prenosi do interneta. Izostavite peerove i vlastite klijente.
• Održavajte ga ažurnim. Pružatelj koji nedostaje u objektu može dovesti do toga da mreže koje provode ASPA odbiju vaše rute preko tog pružatelja, pa novi tranzit dodajte prije nego što ga uključite, a stari uklonite nakon što ga isključite.
• Donosite vlastiti ASN u oblak? AWS preporučuje ASPA koji AS16509 i AS14618 navodi kao pružatelje vašeg ASN-a; bez njih rute koje ponovno oglašava za vas ne prolaze ASPA validaciju.
• Iznajmljujete? ASPA pripada vašem ASN-u, a ne prefiksu, pa ga objavljujete vi, a ne mi.

Kontrolni popis

Prije nego što prostor počne prenositi produkcijski promet:

• ROA postoji za ispravan prefiks i ispravan AS ishodišta.
• Najveća duljina odgovara vašem stvarnom planu najave.
• IRR route objekti također su postavljeni. RPKI ih nije zamijenio. Mnogi upstreamovi i dalje grade filtre prefiksa iz IRR podataka, pa vas valjan ROA bez odgovarajućeg route objekta i dalje dovodi do filtriranja.
• ASPA navodi svaki upstream, ako ga objavljujete, i nijednog peera ni klijenta.
• Validirajte izvana. Provjerite iz vanjskog looking glassa ili RPKI validatora, a ne iz vlastite mreže, koja će rado prihvatiti vaše vlastite rute.
• Počistite na odlasku. Kada najam završi ili prestanete najavljivati blok, ROA treba povući ili ažurirati. Zastarjeli ROA koji pokazuje na ASN koji više ne najavljuje prostor problem je za onoga tko ga sljedeći dobije.

Gdje se uklapa RTM Networks

ROA zapise izrađujemo i održavamo u sklopu i najma i sponzorstva, a ne kao dodatak (najam IPv4, sponzorstvo PI i ASN). Za najam nam javite ASN s kojeg ćete najavljivati ili pružatelja oblaka kojem donosite prostor te trebaju li vam specifičniji prefiksi, a ROA se konfigurira prije predaje. Za sponzorirane resurse RPKI konfiguracijom upravljamo zajedno s ostalim objektima registra.

Ako preuzimate prostor odnekud drugdje, tko postavlja RPKI ovisi o putu: kupac to radi za sam blok, a kod najma to radi najmodavac. Možemo provjeriti postoji li ROA za blok i, ako postoji, je li valjan.