Kako radi infrastruktura javnih ključeva za internetske resurse
Pratite RPKI ovlaštenje od nositelja adresa do usmjerivača i upoznajte Lu Hengov argument za pouzdanu uslugu čiji je administrator zamjenjiv.
Premjestite uslugu u novu mrežu. Poslužitelji rade ispravno, adrese se nisu promijenile, a neki posjetitelji ipak joj više ne mogu pristupiti. Jedan mogući uzrok iznenađujuće je malen: internetski zapisi o usmjeravanju još uvijek ovlašćuju staru mrežu da oglašava te adrese.
RPKI pretvara to ovlaštenje u nešto što druge mreže mogu provjeriti. Evo kako ono putuje od nositelja adresa do usmjerivača i zašto Lu Heng tvrdi da rad tog mehanizma nikada ne smije ovisiti o zadržavanju jednog administratora na vlasti. Za kraći uvod počnite od teksta o tome što RPKI štiti.
1. Utvrditi tko može izdavati ovlaštenja za adrese
Skupina IP adresa naziva se prefiksom. Mreža koja oglašava taj prefiks identificira se brojem autonomnog sustava, odnosno ASN-om. RPKI, infrastruktura javnih ključeva za resurse, koristi certifikate da bi utvrdio tko može izdavati ovlaštenja za određene raspone adresa.
Ti certifikati tvore lanac do pouzdanog korijena. Hijerarhija prati dodjelu internetskih brojčanih resursa, kako je opisano u RFC-u 6480. Ona pruža dokaze o resursima unutar tog sustava; ne daje certifikacijskom tijelu politički mandat nad ljudima koji koriste internet.
2. Objaviti potpisano ovlaštenje
Nositelj adresa objavljuje ovlaštenje za ishodište rute, odnosno ROA (Route Origin Authorisation). Poruka je precizna: ovaj ASN smije biti ishodište ovog prefiksa. Ishodište je mreža na početku oglašene rute, a ne svaka mreža koja kasnije prenosi promet.
ROA može odrediti i najveću duljinu prefiksa: koliko se raspon adresa smije podijeliti na manje oglašene raspone. Bez te neobavezne postavke dopuštena je samo navedena duljina prefiksa. Time se sprječava da „ovlaštenje za ovaj raspon” prešutno postane ovlaštenje za svaku moguću podjelu. Potpisani zapis definira RFC 9582.
3. Pretvoriti objavljene zapise u provjerene podatke
Potpisani zapisi dostupni su u repozitorijima za objavu. Softver za validaciju prikuplja ih i provjerava lanac certifikata, potpise, podatke o isteku i opozivu te manifeste koji opisuju objavljene objekte. Sama čitljiva datoteka nije dovoljna: i dokazi koji je podupiru moraju proći validaciju.
Validator stvara upotrebljive podatke o ovlaštenjima, koji se često nazivaju Validated ROA Payloads, odnosno VRP. Oni sadrže prefiks, dopušteni ishodišni ASN i najveću duljinu. Usmjerivači primaju rezultate iz pouzdane predmemorije putem protokola RPKI-to-Router, opisanog u RFC-u 8210. Ne traže dopuštenje od registra svaki put kada posjetitelj otvori stranicu.
4. Usporediti rutu s ovlaštenjem
BGP je protokol kojim mreže oglašavaju rute. Usmjerivač koji primi rutu uspoređuje njezin prefiks i ishodišni ASN sa svojim validiranim ovlaštenjima. To je validacija ishodišta rute, odnosno ROV (Route Origin Validation).
Valid (valjano): ovlaštenje koje obuhvaća prefiks dopušta i ishodište i duljinu prefiksa. Invalid (nevaljano): postoje ovlaštenja koja obuhvaćaju prefiks, ali nijedno ne dopušta tu kombinaciju. NotFound (nije pronađeno): nijedno ovlaštenje ne obuhvaća prefiks. To su rezultati usporedbe, a ne presude o nečijim namjerama. Operator odlučuje kako će ih koristiti u politici usmjeravanja. Pogledajte RFC 6811.
Vratimo se premještanju usluge. Ako je stari ASN i dalje ovlašten, a novi nije, novo oglašavanje može dobiti rezultat Invalid. Mreže koje filtriraju nevaljane rute mogu ga odbiti. Rješenje je uskladiti promjenu ovlaštenja s premještanjem, uključujući eventualno razdoblje u kojem je ovlaštenje potrebno objema mrežama, a ne pretpostaviti da ispravni poslužitelji jamče dostupnost. Operativne mjere opreza obrađuje RFC 7115.
5. Održavati cijeli lanac u radu
Validacija ishodišta pomaže odbaciti lažne tvrdnje o ishodištu. Ne provjerava svaki mrežni skok, ne šifrira promet i ne otkriva svako curenje ruta. Ruta koja je procurila može zadržati ovlašteno ishodište. Ostale zaštite usmjeravanja i dalje su potrebne.
I dokaze treba održavati. Certifikati istječu; ovlaštenja i objavljeni podaci mijenjaju se. Uklanjanje ROA zapisa ne mora uzrokovati trenutačni prekid: konačan rezultat validacije ovisi o drugim dostupnim zapisima, a posljedica za usmjeravanje o pravilima pojedinog operatora. RFC 8211 ispituje kako pogreške ili štetni postupci certifikacijskih tijela i operatora repozitorija mogu utjecati na sustav.
Lu Hengov prijedlog: sačuvati uslugu, omogućiti zamjenu administratora
U Bilješci 70 Lu Heng osporava poznat logički skok: budući da je usluga registra neophodna, njezin sadašnji operator mora biti nezamjenjiv. Mrežama trebaju točni zapisi i sigurnost koja funkcionira. To ne uspostavlja trajno pravo neke institucije da ih kontrolira.
Njegov alternativni prijedlog čini kontinuitet svojstvom sustava: zapisi koji se mogu neovisno revidirati, iskušana primopredaja kvalificiranom nasljedniku i način prijenosa upravljanja bez prisiljavanja mreža da mijenjaju adrese. Izričito priznaje da se RPKI ne može prenijeti kopiranjem jednog direktorija. Ključevi, certifikati, objava i povjerenje moraju ostati usklađeni tijekom cijelog prijelaza.
To je zahtjev za projektiranje koji on zagovara, a ne tvrdnja da je takva prenosivost već svugdje dostupna. Obuhvaća obje strane problema: neoprezna zamjena može poremetiti provjeru; nezamjenjivi čuvar pristupa može pretvoriti tu ovisnost u moć. Pouzdana usluga i zamjenjiv administrator moraju se projektirati zajedno.
Zašto izgraditi tu mogućnost prije krize?
Kada spor zahvati lanac certifikata, može utjecati na ljude daleko izvan kruga sukobljenih strana. Korisnici nisu izabrali sukob, ali mogu snositi trošak prekinute povezanosti. Postupak nasljeđivanja upravljanja improviziran tijekom prekida dolazi prekasno da bi ih zaštitio od te neizvjesnosti.
Lu Heng zagovara unaprijed uspostavljen kontinuitet i pravo na odlazak, uz sprječavanje da administrativni sporovi postanu oružje protiv mreža koje rade. Cijeli argument pročitajte u Bilješci 70: zaštitite evidenciju, a ne čuvara pristupa.