Come funziona la Resource Public Key Infrastructure
Segui un’autorizzazione RPKI dal titolare degli indirizzi al router e scopri perché Lu Heng propone di mantenere affidabile il servizio e sostituibile il suo amministratore.
Spostate un servizio su una nuova rete. I server sono in buono stato e gli indirizzi non sono cambiati, eppure alcuni visitatori non riescono più a raggiungerlo. Una possibile causa è sorprendentemente piccola: i dati di instradamento di Internet autorizzano ancora la vecchia rete ad annunciare quegli indirizzi.
RPKI trasforma quel permesso in qualcosa che altre reti possono verificare. Ecco come arriva dal titolare degli indirizzi a un router, e perché Lu Heng sostiene che mantenere in funzione questo meccanismo non debba mai dipendere dal mantenere al potere un unico amministratore. Per un’introduzione più breve, iniziate da che cosa protegge RPKI.
1. Stabilire chi può autorizzare l’uso degli indirizzi
Un gruppo di indirizzi IP si chiama prefisso. Una rete che annuncia quel prefisso si identifica con un numero di sistema autonomo, o ASN. RPKI, la Resource Public Key Infrastructure, utilizza certificati per stabilire chi possa rilasciare autorizzazioni per determinati intervalli di indirizzi.
Quei certificati formano una catena che risale a una radice fidata. La gerarchia segue l’assegnazione delle risorse di numerazione Internet, come descritto nell’RFC 6480. Fornisce prove sulle risorse all’interno di quel sistema; non attribuisce a un’autorità di certificazione un mandato politico sulle persone che utilizzano Internet.
2. Pubblicare un permesso firmato
Il titolare degli indirizzi pubblica una Route Origin Authorisation, o ROA. Il suo messaggio è preciso: questo ASN può originare questo prefisso. Originare significa essere la rete all’inizio della rotta annunciata, non ogni rete che trasporta il traffico in seguito.
Una ROA può anche impostare una lunghezza massima del prefisso, cioè fino a che punto l’intervallo di indirizzi possa essere suddiviso in intervalli più piccoli negli annunci. Senza questa impostazione facoltativa, consente soltanto la lunghezza del prefisso indicata. Si evita così che «il permesso per questo intervallo» diventi implicitamente il permesso per ogni suddivisione possibile. L’RFC 9582 definisce il dato firmato.
3. Trasformare i dati pubblicati in dati verificati
I dati firmati vengono messi a disposizione nei repository di pubblicazione. Il software di convalida li raccoglie e controlla la catena dei certificati, le firme, la scadenza e le informazioni di revoca, insieme ai manifesti che descrivono gli oggetti pubblicati. Un file leggibile, da solo, non basta: anche le prove a suo sostegno devono superare la convalida.
Il validatore produce dati di autorizzazione utilizzabili, spesso chiamati Validated ROA Payloads, o VRP. Contengono il prefisso, l’ASN di origine autorizzato e la lunghezza massima. I router ricevono i risultati da una cache fidata tramite il protocollo RPKI-to-Router descritto nell’RFC 8210. Non chiedono il permesso a un registro ogni volta che un visitatore apre una pagina.
4. Confrontare la rotta con il permesso
BGP è il protocollo con cui le reti annunciano le rotte. Un router che riceve una rotta ne confronta il prefisso e l’ASN di origine con le proprie autorizzazioni convalidate. Questa è la Route Origin Validation, o ROV.
Valid (valido): un’autorizzazione che copre il prefisso consente sia l’origine sia la lunghezza del prefisso. Invalid (non valido): esistono autorizzazioni che lo coprono, ma nessuna consente quella combinazione. NotFound (non trovato): nessuna autorizzazione copre il prefisso. Sono risultati di un confronto, non giudizi sulle intenzioni di qualcuno. L’operatore decide come usarli nella politica di instradamento. Si veda l’RFC 6811.
Torniamo allo spostamento del servizio. Se il vecchio ASN è ancora autorizzato e quello nuovo non lo è, il nuovo annuncio può risultare Invalid. Le reti che filtrano le rotte Invalid potrebbero rifiutarlo. La soluzione è coordinare la modifica dell’autorizzazione con lo spostamento, compreso l’eventuale periodo in cui entrambe le reti hanno bisogno del permesso, senza presumere che server funzionanti garantiscano la raggiungibilità. L’RFC 7115 tratta le precauzioni operative.
5. Mantenere in funzione l’intera catena
La convalida dell’origine aiuta a rifiutare false dichiarazioni di origine. Non verifica ogni passaggio, non cifra il traffico e non rileva ogni fuga di rotte. Una fuga può conservare un’origine autorizzata. Restano necessarie altre protezioni dell’instradamento.
Anche le prove richiedono manutenzione. I certificati scadono; permessi e dati pubblicati cambiano. Rimuovere una ROA non causa necessariamente un’interruzione immediata: l’esito finale della convalida dipende dagli altri dati disponibili e la conseguenza sull’instradamento dipende dalla politica locale. L’RFC 8211 esamina come errori o azioni dannose delle autorità di certificazione e dei gestori dei repository possano influire sul sistema.
La proposta di Lu Heng: preservare il servizio, sostituire l’amministratore
Nella Nota 70, Lu Heng contesta un salto logico comune: poiché il servizio di un registro è essenziale, chi lo gestisce oggi dovrebbe essere insostituibile. Le reti hanno bisogno di dati accurati e di una sicurezza funzionante. Questo non stabilisce il diritto permanente di un’istituzione a controllarle.
La sua alternativa fa della continuità una proprietà del sistema: dati verificabili in modo indipendente, un passaggio collaudato a un successore qualificato e un modo per trasferire l’amministrazione senza costringere le reti a cambiare indirizzi. Riconosce esplicitamente che RPKI non si trasferisce copiando una directory. Chiavi, certificati, pubblicazione e fiducia devono restare coerenti per tutta la transizione.
È un requisito progettuale che propone, non l’affermazione che questa portabilità sia già disponibile ovunque. Affronta entrambi i lati del problema: una sostituzione poco accorta può interrompere la verifica; un custode insostituibile dell’accesso può trasformare quella dipendenza in potere. L’affidabilità del servizio e la sostituibilità del suo amministratore devono essere progettate insieme.
Perché costruire questa possibilità prima di una crisi?
Quando una controversia raggiunge la catena dei certificati, può colpire persone ben oltre le parti coinvolte. I clienti non hanno scelto il conflitto, ma possono sopportare il costo della connettività interrotta. Improvvisare una successione durante un’interruzione è già troppo tardi per proteggerli da quell’incertezza.
Lu Heng propone di stabilire in anticipo la continuità e il diritto di uscita, impedendo che le controversie amministrative diventino un’arma contro reti funzionanti. Seguite l’argomento completo nella Nota 70: proteggere il registro, non chi ne controlla l’accesso.