RPKI in ROA: kaj morajo kupci in najemniki dejansko storiti

Zakaj to ni več neobvezno

RPKI je bil leta nekaj, za kar so se operaterji strinjali, da je dobra zamisel, a se ga niso lotili. To se je spremenilo, ko so ga velika omrežja začela dejansko uveljavljati. Večji ponudniki tranzita, velike platforme v oblaku in več velikih omrežij za vsebine zdaj izvajajo validacijo izvora poti (Route Origin Validation) in zavržejo poti, ki so neveljavne (invalid).

Praktična posledica je neizprosna. Predpona z okvarjenim ROA ni le nezaščitena, temveč nedosegljiva iz vse večjega dela interneta. Napaka pa je delna in zmedena: nekateri uporabniki vas dosežejo, drugi ne, traceroute pa je videti v redu, od koderkoli pač testirate.

Če kupujete ali najemate naslovni prostor, je to tista podrobnost konfiguracije, ki vas bo med vsemi najverjetneje stala en dan.

Kaj ROA dejansko je

RPKI je sistem kriptografskih potrdil, vezanih na register naslovov. Objekt, ki je pomemben pri vsakdanjem delu, je Route Origin Authorization ali ROA, in vsebuje natanko tri stvari:

• Predpono. Na primer 192.0.2.0/24.
• Izvorni AS. Številko avtonomnega sistema, ki jo sme objaviti.
• Največjo dolžino. Najdaljšo predpono, ki se sme objaviti znotraj tega bloka.

To je ves objekt. Je podpisana izjava imetnika naslovov, ki pravi „ta AS sme biti izvor tega prostora, do te določene velikosti“. Usmerjevalniki je ne berejo neposredno. Validatorji podatke RPKI prenesejo in preverijo, rezultat pa posredujejo usmerjevalnikom, ki nato vsako pot razvrstijo kot valid, invalid ali not-found.

Vsaka pot konča v enem od treh stanj. Valid: ROA pokriva predpono in objava se z njim ujema. NotFound, ki ga mnoga orodja prikazujejo kot Unknown: predpone ne pokriva noben ROA. Invalid: ROA pokriva predpono, objava pa mu nasprotuje, bodisi z napačnega AS bodisi s predpono, daljšo, kot dovoljuje največja dolžina.

Vrstni red teh stanj je pomembnejši, kot ljudje pričakujejo. Pot brez ROA je še vedno sprejeta skoraj povsod: nezaščitena je, a gre skozi. Pot, ki je Invalid, zavrže vsako omrežje, ki uveljavlja validacijo. Brez ROA je bolje kot z napačnim ROA. Cilj je pravilen ROA, a če podrobnosti na dan objave niso urejene, je objava brez ROA in njegova dodaja, ko so, veliko varnejša od objave takega, ki nasprotuje temu, kar pošiljate.

Kdo ga ustvari, je odvisno od tega, kako ste dobili prostor

To ljudi nenehno spotakne, zato je vredno biti izrecen.

Če ste blok kupili, je registriran na vas in ROA ustvarite sami v portalu svojega registra ali prosite svoj sponzorski LIR, naj ga ustvari, če ta v vašem imenu vzdržuje razmerje z registrom. To storite po končanem prenosu, ne prej, ker mora biti objekt ustvarjen pod novim imetnikom. Kupljen prostor legacy v regiji RIPE NCC potrebuje pogodbo z RIPE NCC ali sponzorskim LIR, preden sploh lahko ima ROA (RIPE NCC).

Če najemate, blok ni registriran na vas in ROA ne morete ustvariti. To stori imetnik, za vaš ASN. To pomeni, da mu morate vnaprej povedati dve stvari: ASN, s katerim boste objavljali, in ali nameravate objavljati kaj bolj specifičnega od celega bloka. Najem, pri katerem ROA ni bil ustvarjen za vaš ASN, bo v trenutku, ko ga objavite, validiran kot invalid.

Če objavljate prek ponudnika v oblaku z BYOIP, mora ROA običajno navajati ASN ponudnika in ne vašega, ker je njegovo omrežje izvor poti: AS16509 in AS14618 pri AWS, AS8075 pri Azure, AS396982 pri Google Cloud na ravni Premium. Nekateri ponudniki vam namesto tega omogočajo izvor z vašim lastnim ASN, bodisi prek lastne seje BGP (Vultr, Cherry Servers) bodisi kot možnost „bring your own ASN“ poleg BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Tedaj ROA navaja vaš ASN, AWS in Oracle Cloud pa želita še enega z njunim. Večina ponudnikov dokumentira ASN, ki ga mora navajati ROA, nekateri, med njimi Gcore, pa ga povedo le, če vprašate, zato preverite, preden karkoli ustvarite; naši vodniki po ponudnikih jih navajajo.

Dve napaki, ki povzročata izpade

Skoraj vse resnične okvare RPKI se zvedejo na največjo dolžino.

Preveč ohlapna nastavitev. ROA za 192.0.2.0/24 z največjo dolžino /32 pomeni, da je veljavna vsaka objava katerekoli velikosti znotraj tega bloka. To izniči velik del smisla: ugrabitelj, ki objavi bolj specifično pot z vaše številke AS, je še vedno valid, bolj specifične poti pa v BGP zmagajo. Varna privzeta nastavitev je, da največjo dolžino nastavite enako dolžini predpone, razen če imate konkreten razlog za drugače.

Preveč stroga nastavitev. Če objavite /24, ki ga pokriva ROA, nato pa ga morate zaradi upravljanja prometa razdeliti na dva /25, ta /25 takoj postaneta invalid in izgineta iz velikega dela interneta. Če nameravate objavljati bolj specifične poti, mora ROA to dovoljevati, preden začnete.

Pravilo, ki prepreči obe: naj ROA opisuje natanko tisto, kar dejansko objavljate, posodobite pa ga v istem terminu kot vsako spremembo usmerjanja, ne pozneje.

ASPA: naslednja plast

ROA ščiti prvi člen poti: kdo sme biti njen izvor. O poti za tem ne pove ničesar, tam pa se zgodijo uhajanja poti (route leaks), ko omrežje posreduje poti, ki bi jih moralo obdržati zase. ASPA, Autonomous System Provider Authorization, pokrije del te vrzeli.

Objekt ASPA podpiše imetnik številke AS in navaja AS, ki so njegovi ponudniki povezljivosti. Omrežja, ki ga validirajo, lahko zavrnejo pot, v kateri se zdi, da vaš AS internet doseže prek nekoga, ki ni vaš ponudnik. To je nastajajoči standard IETF. RIPE NCC ga opisuje kot pripravljenega za podpisovanje, ARIN in APNIC pa imetnikom prav tako omogočata podpisovanje ASPA (primerjava registrov).

• Če imate lasten ASN, objavite ASPA z vsemi ponudniki povezljivosti, ki vaše poti prenašajo v internet. Izpustite peerje in svoje stranke.
• Ohranjajte ga ažurnega. Ponudnik, ki manjka v objektu, lahko povzroči, da omrežja, ki uveljavljajo ASPA, vaše poti prek tega ponudnika zavrnejo, zato nov tranzit dodajte, preden ga vključite, starega pa odstranite, ko ga izključite.
• Prinašate lasten ASN v oblak? AWS priporoča ASPA, ki AS16509 in AS14618 navaja kot ponudnika vašega ASN; brez njiju poti, ki jih ponovno oglašuje za vas, ne prestanejo validacije ASPA.
• Najemate? ASPA pripada vašemu ASN, ne predponi, zato ga objavite vi, ne mi.

Kontrolni seznam

Preden prostor prenaša produkcijski promet:

• ROA obstaja za pravo predpono in pravi izvorni AS.
• Največja dolžina se ujema z vašim dejanskim načrtom objave.
• Tudi objekti route v IRR so na mestu. RPKI jih ni nadomestil. Veliko ponudnikov povezljivosti filtre predpon še vedno gradi iz podatkov IRR, zato vašo pot ob veljavnem ROA brez ujemajočega objekta route filtri še vedno zavržejo.
• ASPA navaja vse ponudnike povezljivosti, če ga objavljate, in nobenih peerjev ali strank.
• Validirajte od zunaj. Preverite z zunanjim looking glass ali validatorjem RPKI, ne iz lastnega omrežja, ki bo vaše lastne poti z veseljem sprejelo.
• Pospravite ob odhodu. Ko se najem konča ali bloka ne objavljate več, je treba ROA umakniti ali posodobiti. Zastarel ROA, ki kaže na ASN, ki prostora ne objavlja več, je težava za tistega, ki ga dobi naslednji.

Kje nastopi RTM Networks

ROA ustvarjamo in vzdržujemo v okviru najema in sponzorstva, ne kot dodatek (najem IPv4, sponzorstvo PI in ASN). Pri najemu nam povejte ASN, s katerim boste objavljali, ali ponudnika v oblaku, h kateremu prinašate prostor, in ali potrebujete bolj specifične poti, ROA pa je nastavljen pred predajo. Pri sponzoriranih virih konfiguracijo RPKI upravljamo skupaj z drugimi objekti registra.

Če prevzemate prostor od drugod, je to, kdo nastavi RPKI, odvisno od poti: kupec to stori za blok sam, pri najemu pa najemodajalec. Preverimo lahko, ali za blok obstaja ROA in, če obstaja, ali je veljaven.