Che cosa dovrebbe registrare davvero un registro degli indirizzi di uscita VPN?
Un registro delle uscite è utile solo se ogni voce dichiara il suo significato, il suo editore e la sua scadenza. La classificazione non è l’identificazione dell’abbonato.
I registri delle uscite suonano come elenchi, e l’elenco non è la parte difficile. La parte difficile è decidere che cosa afferma ogni voce, chi può pubblicarla e che cosa succede quando l’affermazione smette di essere vera. In queste proposte si confondono tre ruoli di indirizzo diversi, e un registro che li mescola non può rispondere a nessuna domanda in modo affidabile. Seguite una voce dalla pubblicazione al ritiro e i requisiti di progettazione appariranno da soli.
Cominciate dal record, non dall’elenco
La prima domanda non è quante informazioni includere, ma che cosa significa una singola riga. Descrive dove si connettono i client, quale origine può vedere una destinazione, o chi detiene un’allocazione in un registro? Sono tre affermazioni con tre proprietari e tre modalità di guasto. Un registro che non indica quale di esse registra non può essere convalidato, corretto o fatto scadere. Azzeccare il significato è il lavoro di progettazione, e l’elenco è solo il risultato.
Scrivete la definizione della riga prima di scrivere qualsiasi schema. Se la definizione ha bisogno della parola e, probabilmente sono due record che fingono di essere uno.
Tre ruoli di indirizzo che si somigliano
I ruoli sono facili da confondere perché un’implementazione può usarli tutti e tre insieme, e spesso lo fa. Un servizio può terminare le connessioni su un indirizzo e inoltrare il traffico da un altro, mentre un registro annota un terzo fatto del tutto diverso.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Un blocco di hosting può contenere uscite VPN e carichi di lavoro non correlati fianco a fianco, quindi una corrispondenza nel registro non dice nulla su che cosa faccia un dato indirizzo in un dato momento. Una voce che non nomina il proprio ruolo non è prova di nulla in particolare. È nominare il ruolo che rende il record confutabile. Indicate anche la famiglia di indirizzi, perché un registro che copre silenziosamente solo IPv4 ingannerà chiunque presuma il contrario.
Seguite una voce dalla pubblicazione al ritiro
Prendete un’uscita ipotetica e seguitela. Un operatore pubblica il prefisso e il suo ruolo in un momento di entrata in vigore dichiarato, i consumatori lo scaricano e, più tardi, l’indirizzo smette di servire come uscita. Ogni passo richiede una regola: chi può pubblicare, che cosa copre davvero il prefisso, quando la voce entra in vigore e come viene ritirata. Un feed senza percorso di ritiro accumula affermazioni obsolete che nessuno può distinguere da quelle attuali.
Separate l’autorità di pubblicare dall’accuratezza dell’etichetta. Un record di registro che collega un’organizzazione a una risorsa prova l’allocazione e non l’uso attuale, e sono affermazioni diverse con prove diverse. I consumatori devono sapere a quale delle due si affidano.
Definite anche la correzione. Un indirizzo riassegnato a un cliente, o un servizio non correlato colto da un’etichetta errata, ha bisogno di un percorso documentato verso una correzione invece di una discussione in una coda di ticket. Il fattore scatenante del ritiro appartiene allo stesso documento della regola di pubblicazione.
Che cosa può e non può sostenere un feed pubblicato
Gli attributi di prefisso pubblicati sono uno schema consolidato, e gli esempi esistenti descrivono la geografia o la proprietà anziché il comportamento. Un feed VPN avrebbe bisogno della propria semantica, delle proprie regole di prova e del proprio processo di revisione, e rinominare un elenco di paesi non ne fornisce nessuno. La guida del registro ARIN mostra che cosa affermano e non affermano i record di allocazione, e un nuovo feed deve guadagnarsi la stessa chiarezza sulle proprie affermazioni. È un compito di specifica, non un compito di rietichettatura.
Ciò che un tale feed può sostenere è una decisione di classificazione su un’origine di rete. Ciò che non può fare è identificare una persona dietro un indirizzo condiviso, dimostrare che tutto il traffico da quell’indirizzo passa per un tunnel, o decidere se una particolare richiesta sia abusiva. Sono tre domande separate con tre requisiti di prova separati.
Tenete la questione giuridica fuori dalla specifica
Una specifica tecnica non può stabilire se un requisito di registrazione proposto sia legittimo, proporzionato o saggio. Tale valutazione richiede il testo legislativo effettivo, i diritti coinvolti, la giurisdizione e un’analisi giuridica che un formato di dati non può fornire. Un formato può essere ben progettato e sostenere comunque una cattiva politica.
Ciò che la specifica può fare è rendere concreto il dibattito. Definite prima i dati proposti, i loro limiti e le loro modalità di guasto, così che l’argomento politico riguardi un meccanismo reale e non un elenco indefinito che ogni partecipante immagina diversamente. È il massimo che un documento tecnico possa offrire a una questione giuridica.