RPKI un ROA: kas patiesībā jādara pircējiem un nomniekiem

Kāpēc tas vairs nav izvēles jautājums

Gadiem ilgi RPKI bija kaut kas, par ko operatori vienojās, ka tā ir laba ideja, bet līdz tam netika. Tas mainījās, kad lielie tīkli sāka to patiešām piemērot. Lielākie tranzīta sniedzēji, lielās mākoņu platformas un vairāki lieli satura tīkli tagad veic Route Origin Validation un atmet maršrutus, kas ir nederīgi (invalid).

Praktiskās sekas ir skarbas. Prefikss ar bojātu ROA nav vienkārši neaizsargāts, tas nav sasniedzams no augošas interneta daļas. Un kļūme ir daļēja un mulsinoša: daži lietotāji Jūs sasniedz, daži ne, un traceroute izskatās labi no jebkuras vietas, no kuras Jūs pārbaudāt.

Ja pērkat vai nomājat adrešu telpu, šī ir viena konfigurācijas detaļa, kas, visticamāk, Jums izmaksās dienu.

Kas patiesībā ir ROA

RPKI ir kriptogrāfisku apliecinājumu sistēma, kas piesaistīta adrešu reģistram. Objekts, kas ir svarīgs ikdienā, ir Route Origin Authorization jeb ROA, un tas satur tieši trīs lietas:

• Prefikss. Piemēram, 192.0.2.0/24.
• Izcelsmes AS. Autonomās sistēmas numurs, kuram atļauts to paziņot (announce).
• Maksimālais garums. Garākais prefikss, ko drīkst paziņot šajā blokā.

Tas ir viss objekts. Tas ir adreses turētāja parakstīts paziņojums, kas saka: „šai AS ir atļauts būt šīs telpas izcelsmei līdz šim konkrētajam izmēram”. Maršrutētāji to nelasa tieši. Validatori iegūst un pārbauda RPKI datus un nodod rezultātu maršrutētājiem, kas tad katru maršrutu klasificē kā valid, invalid vai not-found.

Katrs maršruts nonāk vienā no trim stāvokļiem. Valid: ROA aptver prefiksu, un paziņojums tam atbilst. NotFound, ko daudzi rīki rāda kā Unknown: prefiksu neaptver neviens ROA. Invalid: ROA aptver prefiksu, bet paziņojums tam ir pretrunā, vai nu no nepareizā AS, vai ar prefiksu, kas garāks, nekā atļauj maksimālais garums.

Šo stāvokļu secība ir svarīgāka, nekā cilvēki sagaida. Maršruts bez ROA joprojām tiek pieņemts gandrīz visur: tas ir neaizsargāts, bet tiek cauri. Maršrutu, kas ir Invalid, atmet katrs tīkls, kas piemēro validāciju. Nekāds ROA ir labāks par nepareizu ROA. Mērķis ir pareizs ROA, bet, ja detaļas paziņošanas dienā nav nokārtotas, paziņot bez ROA un pievienot to, kad tās ir nokārtotas, ir daudz drošāk nekā publicēt tādu, kas ir pretrunā ar to, ko sūtāt.

Kas to izveido, ir atkarīgs no tā, kā ieguvāt telpu

Te cilvēki pastāvīgi paklūp, tāpēc ir vērts runāt skaidri.

Ja nopirkāt bloku, tas ir reģistrēts uz Jums, un Jūs pats izveidojat ROA sava reģistra portālā vai lūdzat to izveidot savam sponsorējošajam LIR, ja tas Jūsu vārdā uztur attiecības ar reģistru. Dariet to pēc pārsūtīšanas pabeigšanas, nevis pirms, jo objekts jāizveido jaunā turētāja vārdā. Nopirktai legacy telpai RIPE NCC reģionā vajag līgumu ar RIPE NCC vai sponsorējošo LIR, pirms tai vispār var būt ROA (RIPE NCC).

Ja nomājat, bloks nav reģistrēts uz Jums, un Jūs nevarat izveidot ROA. To dara turētājs, norādot Jūsu ASN. Tas nozīmē, ka Jums iepriekš jāpasaka divas lietas: ASN, no kura paziņosiet, un vai plānojat paziņot kaut ko specifiskāku par visu bloku. Noma, kurā ROA nav izveidots Jūsu ASN, būs invalid tajā brīdī, kad to paziņosiet.

Ja paziņojat caur mākoņa sniedzēju, izmantojot BYOIP, ROA parasti jānorāda sniedzēja ASN, nevis Jūsu, jo maršruta izcelsme ir viņu tīkls: AS16509 un AS14618 pie AWS, AS8075 pie Azure, AS396982 pie Google Cloud tā Premium līmenī. Daži sniedzēji ļauj tā vietā būt izcelsmei Jūsu ASN, vai nu pa Jūsu BGP sesiju (Vultr, Cherry Servers), vai kā „bring your own ASN” iespēju papildus BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Tad ROA norāda Jūsu ASN, un AWS un Oracle Cloud vēlas arī ROA ar savu. Lielākā daļa sniedzēju dokumentē ASN, kas jānorāda ROA, un daži, starp tiem Gcore, to sniedz tikai pēc pieprasījuma, tāpēc pārbaudiet, pirms kaut ko izveidojat; mūsu sniedzēju ceļvežos tie ir uzskaitīti.

Divas kļūdas, kas izraisa pārtraukumus

Gandrīz visas reālās RPKI kļūmes ir saistītas ar maksimālo garumu.

Pārāk atļaujošs. ROA blokam 192.0.2.0/24 ar maksimālo garumu /32 nozīmē, ka jebkurš jebkura izmēra paziņojums šajā blokā ir valid. Tas lielā mērā izjauc jēgu: nolaupītājs, kas paziņo specifiskāku maršrutu no Jūsu AS numura, joprojām ir valid, un BGP uzvar specifiskāki maršruti. Drošais noklusējums ir iestatīt maksimālo garumu vienādu ar prefiksa garumu, ja vien Jums nav konkrēta iemesla to nedarīt.

Pārāk stingrs. Ja paziņojat ROA aptvertu /24 un vēlāk trafika inženierijai jāsadala divos /25, šie /25 uzreiz kļūst invalid un pazūd no lielas interneta daļas. Ja plānojat paziņot specifiskākus maršrutus, ROA tie jāatļauj, pirms sākat.

Noteikums, kas novērš abus: panāciet, lai ROA precīzi aprakstītu to, ko patiesībā paziņojat, un atjauniniet to tajā pašā izmaiņu logā kā jebkuras maršrutēšanas izmaiņas, nevis pēc tam.

ASPA: nākamais slānis

ROA aizsargā maršruta pirmo posmu: kas drīkst būt tā izcelsme. Tas neko nesaka par ceļu pēc tam, kur notiek maršrutu noplūdes (route leaks), kad tīkls nodod tālāk maršrutus, kas tam būtu jāpatur pie sevis. ASPA, Autonomous System Provider Authorization, aptver daļu no šīs plaisas.

ASPA objektu paraksta AS numura turētājs, un tajā uzskaitītas AS, kas ir tā upstream sniedzēji. Tīkli, kas to validē, var noraidīt ceļu, kurā Jūsu AS šķietami sasniedz internetu caur kādu, kas nav Jūsu sniedzējs. Tas ir topošs IETF standarts. RIPE NCC to raksturo kā gatavu lietošanai parakstīšanā, un arī ARIN un APNIC ļauj turētājiem parakstīt ASPA (reģistru salīdzinājums).

• Ja Jums ir savs ASN, publicējiet ASPA, kurā uzskaitīts katrs upstream, kas nes Jūsu maršrutus uz internetu. Neiekļaujiet peering partnerus un savus klientus.
• Uzturiet to aktuālu. Ja objektā trūkst sniedzēja, tīkli, kas piemēro ASPA, var noraidīt Jūsu maršrutus caur šo sniedzēju, tāpēc pievienojiet jaunu tranzītu, pirms to ieslēdzat, un noņemiet veco pēc tā izslēgšanas.
• Pievienojat savu ASN mākonim? AWS iesaka ASPA, kurā AS16509 un AS14618 norādīti kā Jūsu ASN sniedzēji; bez tiem maršruti, ko tas Jūsu vietā paziņo tālāk, neiztur ASPA validāciju.
• Nomājat? ASPA pieder Jūsu ASN, nevis prefiksam, tāpēc to publicējat Jūs, nevis mēs.

Kontrolsaraksts

Pirms telpa nes ražošanas trafiku:

• ROA eksistē pareizajam prefiksam un pareizajam izcelsmes AS.
• Maksimālais garums atbilst Jūsu reālajam paziņošanas plānam.
• Ir arī IRR route objekti. RPKI tos nav aizstājis. Daudzi upstream joprojām veido prefiksu filtrus no IRR datiem, tāpēc derīgs ROA bez atbilstoša route objekta joprojām tiek filtrēts.
• ASPA uzskaita katru upstream, ja to publicējat, un nevienu peering partneri vai klientu.
• Validējiet no ārpuses. Pārbaudiet no ārēja looking glass vai RPKI validatora, nevis no sava tīkla, kas labprāt pieņems Jūsu pašu maršrutus.
• Sakārtojiet, aizejot. Kad noma beidzas vai pārstājat paziņot bloku, ROA jāatsauc vai jāatjaunina. Novecojis ROA, kas norāda uz ASN, kas telpu vairs nepaziņo, ir problēma tam, kas to saņems nākamais.

Kur iederas RTM Networks

Mēs izveidojam un uzturam ROA gan nomas, gan sponsorēšanas ietvaros, nevis kā papildinājumu (IPv4 noma, PI un ASN sponsorēšana). Nomas gadījumā pasakiet mums ASN, no kura paziņosiet, vai mākoņa sniedzēju, pie kura pievienojat telpu, un vai Jums vajag specifiskākus maršrutus, un ROA tiek konfigurēts pirms nodošanas. Sponsorētiem resursiem mēs pārvaldām RPKI konfigurāciju kopā ar pārējiem reģistra objektiem.

Ja pārņemat telpu no citurienes, tas, kas iestata RPKI, ir atkarīgs no ceļa: pircējs to dara pats blokam, bet nomas gadījumā to dara iznomātājs. Mēs varam pārbaudīt, vai blokam ir ROA, un, ja ir, vai tas ir derīgs.