Izvoz stanja registra: kako omogućiti oporavak zapisa o internet brojevnim resursima

Kada je registar dostupan, internet brojevni resurs može delovati kao jednostavan upit. Pretražite IP prefiks ili broj autonomnog sistema i dobijete zapis. Taj zapis je koristan, ali pruža samo jedan pogled na šire stanje: koga je registar priznavao, šta se promenilo, koje su usluge bile delegirane, koja su ovlašćenja za rutiranje postojala i koji dokazi podržavaju trenutni odgovor.

Teže pitanje pojavljuje se kada je registar nedostupan, osporavan, kompromitovan ili se zamenjuje. Može li legitimno stanje resursa i dalje razumeti i proveriti neko ko nema originalnu bazu podataka i interne procedure?

Pitanje kontinuiteta: ako trenutni sistem registra sutra prestane da odgovara, koje informacije bi legitimnom imaocu ili nasledniku bile potrebne da rekonstruiše poslednje provereno stanje, bez izmišljanja novog?

Najpre razdvojite tri različita stanja

Mnoge rasprave o registrima postaju zbunjujuće jer se tri različita pitanja tretiraju kao jedno:

• Stanje registra: ono što nadležni organ trenutno beleži o resursu, priznatom imaocu, kontaktima, događajima, delegiranju i statusu.
• Operativno stanje: način na koji se resurs zaista koristi, uključujući reverzni DNS, odnose sa pružaocima usluga i kontinuitet usluge.
• Stanje rutiranja: koji autonomni sistem je izvor rute i da li je odgovarajuće ovlašćenje za rutiranje važeće.

Ova stanja mogu biti usklađena, ali ne moraju da se menjaju istovremeno. Prefiks može prelaziti između pružalaca usluga dok priznati imalac ostaje isti. Zapis registra može biti tačan dok je ruta pogrešno konfigurisana. Ovlašćenje za rutiranje može biti važeće dok je objekat kontakta zastareo. Koristan izvoz mora očuvati odnose između ovih stanja i pokazati koju tvrdnju podržava svaki dokaz.

Šta RDAP pruža, a šta ne pruža

RDAP je standardni sloj za upite nad registracionim podacima. Njegov JSON model opisuje objekte kao što su IP mreže, brojevi autonomnih sistema, entiteti, događaji i veze. Time se aktuelni zapisi lakše pretražuju i tumače kroz različite registre. Strukturu definiše RFC 9083.

RDAP odgovara na pitanje o sadašnjem stanju: šta registar koji pruža uslugu sada vraća za ovaj objekat? Odgovor može uključiti trenutni zapis i informacije o događajima, ali odgovor uživo nije automatski nezavisan paket za kontinuitet. Sam po sebi ne garantuje da imalac ima prenosiv niz prethodnih stanja potvrđene autentičnosti, potpunu evidenciju prelazaka ili materijal potreban za uređen postupak nasleđivanja.

Ta razlika je važna. Aktivan imenik je prozor u sistem. Izvoz stanja registra je način da se sačuva dovoljno proverenog stanja za razmatranje kontinuiteta kada se prozor, sistem ili institucionalni odnos promene.

Šta RPKI dokazuje, a šta ne dokazuje

RPKI odgovara na pitanje rutiranja. Ovlašćenje za poreklo rute identifikuje autonomni sistem koji je imalac adresnog prostora ovlastio da bude izvor ruta za jedan ili više prefiksa. Profil i pravila validacije opisani su u RFC 9582.

To je vredan dokaz, ali nije potpun odgovor na svako pitanje registra. Važeći ROA sam po sebi ne dokazuje celokupnu pravnu ili administrativnu istoriju resursa, ne identifikuje svaki operativni kontakt, ne uspostavlja kontinuitet reverznog DNS-a i ne rešava spor o tome koje stanje registra treba priznati. RPKI ovlašćenje je jedan sloj evidencije kontinuiteta, a ne njena zamena.

Radna definicija izvoza stanja registra

Izvoz stanja registra je predloženi paket za kontinuitet koji čini suštinsko provereno stanje IPv4, IPv6 ili ASN resursa prenosivim, razumljivim i proverljivim. Trebalo bi da nezavisnom čitaocu omogući odgovore na četiri pitanja:

1. O kom resursu i kom priznatom imaocu govorimo?
2. Koje je bilo poslednje provereno stanje i kada je stupilo na snagu?
3. Koje su se bitne promene dogodile posle tog stanja?
4. Koji dokazi i ovlašćenja podržavaju legitiman prelazak ili postupak nasleđivanja?

Ovo je određenije od izvoza cele baze podataka i korisnije od snimka ekrana. Izvoz treba da sadrži stanje potrebno nasledniku, a da izostavi nepovezane podatke korisnika, privatnu poslovnu strategiju i detalje interne implementacije koji ne služe utvrđivanju resursa.

Minimalan koristan izvoz

Praktičan izvoz može se organizovati u mali skup povezanih zapisa. Svaki zapis treba da ima stabilan identifikator, vreme početka važenja, izvor i dovoljno informacija da se otkrije neobjašnjena promena.

• Identitet resursa: IPv4 prefiks, IPv6 prefiks ili ASN, odnos sa nadređenim resursom ili dodelom gde je to relevantno i identifikatori u registru.
• Priznati imalac: organizacija ili entitet priznat u proverenom stanju, identifikator u registru, datum početka važenja i status tog priznanja.
• Kontakti: administrativni, tehnički, bezbednosni i kontakti za prijavu zloupotrebe koji su nasledniku ili strani koja se oslanja na podatke zaista potrebni.
• Bitna istorija: prenosi, promene imena ili organizacije, delegiranja, promene statusa, sporovi i dokazi ili ovlašćenja povezani sa svakim događajem.
• Operativni odnosi: relevantni odnosi sa pružaocima usluga, delegiranim korisnicima, reverznim DNS-om i servisima, uz periode važenja i stanje prestanka.
• Reference za rutiranje i bezbednost: relevantni izvorni ASN, reference na ROA ili RPKI objekte, stanje objavljivanja i vreme kada je to stanje opaženo.
• Stanje sukoba: da li postoji spor, zadržavanje ili suprotstavljen zahtev, na koji resurs utiče i koje je poslednje stanje koje nije bilo sporno.
• Revizorski trag: ko je šta promenio, kada, po kom ovlašćenju, sa koje na koju vrednost i sa kojim rezultatom provere.
• Informacije o integritetu: brojevi verzija, vremenske oznake, heševi objekata, potpisi i manifest izvoza, kako bi primalac mogao da proveri izvor i otkrije izmenu.

Izvoz ne mora da reprodukuje svaku internu tabelu baze podataka. Mora da sačuva odnose koji javnom odgovoru daju smisao, a prelazak čine proverljivim.

Zašto rezervna kopija nije dovoljna

Rezervna kopija obično je namenjena obnovi sistema za istog operatora. Izvoz stanja registra namenjen je tome da druga ovlašćena strana razume i proveri stanje kada se originalni sistem, organizacija ili način rada ne mogu jednostavno obnoviti.

• Rezervna kopija može zahtevati vlasnički softver, nedokumentovane odnose i originalne pristupne podatke.
• Izvoz treba da bude čitljiv nezavisnom nasledniku i da identifikuje dokaze iza svake bitne tvrdnje.
• Rezervna kopija može sadržati mnogo više podataka nego što imalac resursa ima pravo ili želi da primi.
• Izvoz treba da bude ograničen na resurs, potvrđene autentičnosti, mašinski čitljiv i prenosiv.

Razlika nije stvar tehničke sklonosti. To je razlika između očuvanja mašine i očuvanja sposobnosti da se prepozna legitimno stanje.

Šta se dešava kada je kontinuitet potreban

Postupak kontinuiteta ne treba da počne dopuštanjem da dva sistema polažu pravo na isti resurs. Treba da počne zamrzavanjem poslednjeg proverenog stanja i jasnim definisanjem prelaska.

1. Identifikujte okidač: prekid rada, insolventnost, kompromitovanje, migracija, spor ili drugi definisani događaj kontinuiteta.
2. Sačuvajte poslednje provereno stanje: zabeležite resurs, priznatog imaoca, kontakte, bitnu istoriju i dokaze koji podržavaju taj presek.
3. Proverite izvoz: proverite potpise, heševe, vremenske oznake, reference na ovlašćenja i integritet manifesta.
4. Razdvojite slojeve dokaza: uporedite stanje registra sa operativnom upotrebom, reverznim DNS-om, zapažanjima o rutiranju i RPKI stanjem, umesto da jedan sloj tretirate kao dokaz svih ostalih.
5. Zabeležite naslednika: definišite kako se prethodno stanje zamenjuje, kako se rešavaju sukobi i kako sistemi koji se oslanjaju na podatke pronalaze priznatog naslednika.
6. Objavite prelazak: omogućite pronalaženje novog stanja i vremena njegovog stupanja na snagu, uz zadržavanje prethodnog stanja kao istorijskog zapisa koji se može proveriti.

Postupak je osmišljen da očuva kontinuitet bez pretvaranja prekida rada u priliku da neprovereni podnosilac zahteva prepiše istoriju.

Šta izvoz stanja registra ne sme da radi

Izvoz za kontinuitet nije drugi registar koji svakom primaocu daje moć da tvrdi vlasništvo. Ne treba da stvara paralelne zahteve, zaobilazi važeću politiku resursa, otkriva saobraćaj korisnika ili poverljivu strategiju, niti da neprimetno pretvara operativnu upotrebu u priznatu administrativnu kontrolu.

Izvoz treba da navede i svoja ograničenja. Ako polje nije dostupno, redigovano je ili sporno, zapis to treba da kaže. Pošteno označena nepoznanica bezbednija je od naizgled potpune vrednosti bez dokaza.

Kako proveriti izvoz pre krize

Imalac resursa ili operator može proveriti koncept jednostavnim pregledom:

• Može li nezavisan čitalac identifikovati tačan IPv4, IPv6 ili ASN resurs?
• Može li čitalac identifikovati poslednjeg proverenog priznatog imaoca i datum početka važenja?
• Može li čitalac rekonstruisati bitne prenose, delegiranja i promene organizacije?
• Može li čitalac razlikovati stanje registra od trenutnog rutiranja i operativne upotrebe?
• Može li čitalac pronaći relevantne RPKI dokaze i dokaze o reverznom DNS-u?
• Može li čitalac videti da li postoji spor ili suprotstavljen zahtev?
• Može li čitalac proveriti ko je izradio izvoz i da li je kasnije menjan?
• Može li legitiman naslednik koristiti zapis bez uvoza originalne privatne baze podataka?

Ako su odgovori na ova pitanja negativni, organizacija možda ima aktivnu pretragu ili rezervnu kopiju, ali još nema testiranu evidenciju kontinuiteta.

Kako se ovo uklapa u životni ciklus IPv4

IPv4 resurs ima životni ciklus koji uključuje zapise registra, prenose, operativno delegiranje, rutiranje i kasniju promenu upotrebe. Izvoz je vezivno tkivo između tih trenutaka. Počnite od toga šta podaci registra mogu pokazati o životnom ciklusu IPv4, a zatim razlikujte regionalno kretanje u prenosima između RIR-ova od promene rutiranja pri promeni izvorne mreže u BGP-u.

Isto razmišljanje važi i za šire pitanje upravljanja: kada sistem koordinira jedinstvene resurse, sposobnost provere i prenošenja stanja ne treba u potpunosti da zavisi od jedne nedostupne administrativne tačke. Zato izvoz stanja registra treba posmatrati uz praktična pitanja šta se dešava ako internet registar prestane da funkcioniše i šta dokaz kontrole zaista može da pokaže.

Zaključak

Izvoz stanja registra je način da se kontinuitet učini konkretnim. Ne zamenjuje RDAP, RPKI, podatke o rutiranju, reverzni DNS ni politiku registra. Povezuje relevantne dokaze u zapis potvrđene autentičnosti, sa verzijama i mogućnošću prenošenja, koji legitiman čitalac može razumeti kada se originalnom sistemu ne može jednostavno verovati ili se on ne može obnoviti.

Ako registar nestane, cilj nije dozvoliti svakome da polaže pravo na resurs. Cilj je sačuvati dovoljno proverenog stanja da se legitiman odgovor i dalje može prepoznati, proveriti i preneti dalje.