RPKI ir ROA: ką iš tikrųjų turi padaryti pirkėjai ir nuomininkai

Kodėl tai nebėra pasirinkimas

Ilgus metus RPKI buvo tai, ką operatoriai laikė gera idėja, bet iki to neprieidavo. Tai pasikeitė, kai dideli tinklai iš tikrųjų pradėjo tai taikyti. Pagrindiniai tranzito teikėjai, didžiosios debesijos platformos ir keli dideli turinio tinklai dabar atlieka maršruto kilmės patikrą (Route Origin Validation) ir atmeta maršrutus, kurie grąžinami kaip negaliojantys (invalid).

Praktinė pasekmė tiesmuka. Prefiksas su sugadintu ROA ne tik neapsaugotas, jis nepasiekiamas iš vis didesnės interneto dalies. O gedimas dalinis ir painus: vieni naudotojai Jus pasiekia, kiti ne, o traceroute atrodo gerai iš ten, kur tuo metu testuojate.

Jei perkate ar nuomojatės adresų erdvę, tai vienintelė konfigūracijos smulkmena, kuri greičiausiai kainuos Jums dieną.

Kas iš tikrųjų yra ROA

RPKI yra su adresų registru susietų kriptografinių patvirtinimų sistema. Kasdien svarbus objektas yra maršruto kilmės įgaliojimas (Route Origin Authorization, ROA), ir jame yra lygiai trys dalykai:

• Prefiksas. Pavyzdžiui, 192.0.2.0/24.
• Kilmės AS. Autonominės sistemos numeris, kuriam leidžiama jį skelbti.
• Didžiausias ilgis. Ilgiausias prefiksas, kurį galima skelbti tame bloke.

Tai visas objektas. Tai adresų turėtojo pasirašytas pareiškimas: „šiam AS leidžiama skelbti šią erdvę iki šio konkretaus dydžio“. Maršrutizatoriai jo neskaito tiesiogiai. Validatoriai parsisiunčia ir patikrina RPKI duomenis ir perduoda rezultatą maršrutizatoriams, kurie tada kiekvieną maršrutą priskiria būseną valid (galiojantis), invalid (negaliojantis) arba not-found (nerastas).

Kiekvienas maršrutas atsiduria vienoje iš trijų būsenų. Valid: prefiksą apima ROA, ir paskelbimas jį atitinka. NotFound, kurį daug įrankių rodo kaip Unknown: prefikso neapima joks ROA. Invalid: prefiksą apima ROA, bet paskelbimas jam prieštarauja, arba iš netinkamo AS, arba su ilgesniu prefiksu, nei leidžia didžiausias ilgis.

Šių būsenų tvarka svarbesnė, nei žmonės tikisi. Maršrutas be ROA vis dar priimamas beveik visur: jis neapsaugotas, bet praeina. Invalid maršrutą atmeta kiekvienas patikrą taikantis tinklas. Geriau jokio ROA nei neteisingas ROA. Tikslas yra teisingas ROA, bet jei paskelbimo dieną detalės dar nesutvarkytos, skelbti be ROA ir pridėti jį, kai jos sutvarkytos, gerokai saugiau nei paskelbti ROA, kuris prieštarauja tam, ką siunčiate.

Kas jį sukuria, priklauso nuo to, kaip gavote erdvę

Tai žmones nuolat suklaidina, todėl verta pasakyti aiškiai.

Jei bloką nusipirkote, jis įregistruotas Jūsų vardu, ir ROA sukuriate patys savo registro portale arba paprašote remiančiojo LIR, jei jis Jūsų vardu palaiko santykį su registru. Darykite tai po perleidimo, ne prieš, nes objektas turi būti sukurtas naujojo turėtojo vardu. Nupirktai legacy erdvei RIPE NCC regione, kad ji apskritai galėtų turėti ROA, reikia sutarties su RIPE NCC arba remiančiuoju LIR (RIPE NCC).

Jei nuomojatės, blokas neįregistruotas Jūsų vardu, ir ROA sukurti negalite. Tai padaro turėtojas, Jūsų ASN. Todėl iš anksto turite jam pasakyti du dalykus: iš kurio ASN skelbsite ir ar ketinate skelbti ką nors konkretesnio nei visas blokas. Nuoma, kurioje ROA Jūsų ASN nesukurtas, bus negaliojantis tą akimirką, kai ją paskelbsite.

Jei skelbiate per debesijos teikėją pagal BYOIP, ROA paprastai turi nurodyti teikėjo, o ne Jūsų ASN, nes maršrutą skelbia jo tinklas: AS16509 ir AS14618 AWS, AS8075 Azure, AS396982 Google Cloud Premium lygyje. Kai kurie teikėjai leidžia vietoj to skelbti iš Jūsų ASN, arba per Jūsų BGP sesiją (Vultr, Cherry Servers), arba kaip „bring your own ASN“ parinktį papildomai prie BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Tada ROA nurodo Jūsų ASN, o AWS ir Oracle Cloud nori ir jų ASN nurodančio ROA. Dauguma teikėjų dokumentuoja ASN, kurį turi nurodyti ROA, o keli, tarp jų Gcore, jį pateikia tik paklausus, todėl patikrinkite prieš ką nors kurdami; mūsų teikėjų vadovuose jie išvardyti.

Dvi klaidos, sukeliančios sutrikimus

Beveik visi realūs RPKI gedimai susiję su didžiausiu ilgiu.

Per daug leidžiantis. ROA 192.0.2.0/24 su didžiausiu ilgiu /32 reiškia, kad bet koks bet kokio dydžio paskelbimas tame bloke yra galiojantis. Tai paneigia didelę prasmės dalį: užgrobėjas, skelbiantis konkretesnį maršrutą iš Jūsų AS numerio, vis tiek grąžinamas kaip galiojantis, o konkretesni maršrutai BGP laimi. Saugi numatytoji reikšmė yra didžiausią ilgį nustatyti lygų prefikso ilgiui, nebent turite konkrečią priežastį to nedaryti.

Per griežtas. Jei skelbiate ROA apimamą /24, o vėliau srauto valdymui reikia jį išskaidyti į du /25, tie /25 akimirksniu tampa negaliojantys ir dingsta iš didelės interneto dalies. Jei planuojate skelbti konkretesnius prefiksus, ROA turi tai leisti prieš pradedant.

Abiejų išvengiančioji taisyklė: ROA turi aprašyti lygiai tai, ką iš tikrųjų skelbiate, ir būti atnaujinamas tame pačiame pakeitimų lange kaip ir bet koks maršrutizavimo pakeitimas, o ne po jo.

ASPA: kitas sluoksnis

ROA apsaugo pirmąją maršruto grandį: kas gali jį skelbti. Jis nieko nesako apie tolesnį kelią, kur ir vyksta maršrutų nutekėjimai, kai tinklas perduoda maršrutus, kuriuos turėjo pasilikti sau. ASPA (Autonomous System Provider Authorization) uždengia dalį šios spragos.

ASPA objektą pasirašo AS numerio turėtojas, ir jame išvardyti AS, kurie yra jo upstream teikėjai. Jį tikrinantys tinklai gali atmesti kelią, kuriame Jūsų AS atrodo pasiekiantis internetą per ką nors, kas nėra Jūsų teikėjas. Tai besiformuojantis IETF standartas. RIPE NCC jį apibūdina kaip paruoštą pasirašymui, o ARIN ir APNIC taip pat leidžia turėtojams pasirašyti ASPA (registrų palyginimas).

• Jei turite savo ASN, paskelbkite ASPA, išvardijantį kiekvieną upstream, kuris neša Jūsų maršrutus į internetą. Neįtraukite peer partnerių ir savo klientų.
• Laikykite jį aktualų. Iš objekto praleistas teikėjas gali lemti, kad ASPA taikantys tinklai atmes Jūsų maršrutus per tą teikėją, todėl naują tranzitą pridėkite prieš jį įjungdami, o seną pašalinkite jį išjungę.
• Atsinešate savo ASN į debesiją? AWS rekomenduoja ASPA, kuriame AS16509 ir AS14618 nurodyti kaip Jūsų ASN teikėjai; be jų maršrutai, kuriuos jis Jums perskelbia, ASPA patikros neišlaiko.
• Nuomojatės? ASPA priklauso Jūsų ASN, ne prefiksui, todėl jį skelbiate Jūs, ne mes.

Kontrolinis sąrašas

Prieš erdvei pradedant nešti gamybinį srautą:

• ROA yra tinkamam prefiksui ir tinkamam kilmės AS.
• Didžiausias ilgis atitinka Jūsų tikrąjį skelbimo planą.
• IRR route objektai taip pat yra. RPKI jų nepakeitė. Daugybė upstream teikėjų vis dar sudaro prefiksų filtrus iš IRR duomenų, todėl galiojantis ROA be atitinkamo route objekto vis tiek lemia filtravimą.
• ASPA išvardija kiekvieną upstream, jei jį skelbiate, ir jokių peer partnerių ar klientų.
• Tikrinkite iš išorės. Tikrinkite iš išorinio looking glass ar RPKI validatoriaus, ne iš savo tinklo, kuris mielai priims Jūsų pačių maršrutus.
• Sutvarkykite išeidami. Kai baigiasi nuoma ar nustojate skelbti bloką, ROA turėtų būti atšauktas arba atnaujintas. Pasenęs ROA, nurodantis ASN, kuris erdvės nebeskelbia, yra problema tam, kas ją gaus kitas.

Kur čia RTM Networks

ROA kuriame ir prižiūrime kaip nuomos ir rėmimo dalį, o ne kaip priedą (IPv4 nuoma, PI ir ASN rėmimas). Nuomos atveju nurodykite ASN, iš kurio skelbsite, arba debesijos teikėją, pas kurį atsinešate erdvę, ir ar Jums reikia konkretesnių prefiksų, ir ROA bus sukonfigūruotas prieš perdavimą. Remiamiems ištekliams RPKI konfigūraciją tvarkome kartu su kitais registro objektais.

Jei perimate erdvę iš kitur, kas nustato RPKI, priklauso nuo kelio: paties bloko atveju tai daro pirkėjas, o nuomos atveju nuomotojas. Galime patikrinti, ar blokui yra ROA ir, jei yra, ar jis galioja.