Què hauria de registrar realment un registre d’adreces de sortida VPN?
Un registre de sortides només és útil si cada entrada n’exposa el significat, l’editor i la caducitat. La classificació no és la identificació del subscriptor.
Els registres de sortida sonen a llistes, i la llista no és la part difícil. La part difícil és decidir què afirma cada entrada, qui la pot publicar i què passa quan l’afirmació deixa de ser certa. En aquestes propostes es confonen tres rols d’adreça diferents, i un registre que els barreja no pot respondre cap pregunta de manera fiable. Seguiu una entrada des de la publicació fins a la retirada i els requisits de disseny apareixeran sols.
Comenceu pel registre, no per la llista
La primera pregunta no és quantes adreces incloure, sinó què significa una sola fila. Descriu on es connecten els clients, quina font pot veure una destinació o qui té una assignació en un registre? Són tres afirmacions amb tres propietaris i tres maneres de fallar. Un registre que no indica quina de les tres enregistra no es pot validar, corregir ni fer caducar. Encertar el significat és la feina de disseny, i la llista només és el resultat.
Escriviu la definició de la fila abans d’escriure cap esquema. Si la definició necessita la paraula i, probablement són dos registres que es fan passar per un.
Tres rols d’adreça que semblen iguals
Els rols són fàcils de confondre perquè un desplegament pot fer servir tots tres alhora, i sovint ho fa. Un servei pot acabar les connexions en una adreça i reenviar el trànsit des d’una altra, mentre que un registre enregistra un tercer fet completament diferent.
| 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 bloc d’allotjament pot contenir sortides VPN i càrregues de treball no relacionades costat a costat, així que una coincidència al registre no diu res sobre què fa una adreça concreta en un moment concret. Una entrada que no anomena el seu rol no és prova de res en particular. Anomenar el rol és el que fa que el registre sigui refutable. Indiqueu també la família d’adreces, perquè un registre que només cobreix silenciosament IPv4 enganyarà qualsevol que assumeixi el contrari.
Seguiu una entrada des de la publicació fins a la retirada
Agafeu una sortida hipotètica i seguiu-la. Un operador publica el prefix i el seu rol en un moment d’entrada en vigor declarat, els consumidors el recullen i, més tard, l’adreça deixa de servir com a sortida. Cada pas necessita una regla: qui pot publicar, què cobreix realment el prefix, quan entra en vigor l’entrada i com es retira. Un feed sense camí de retirada acumula afirmacions obsoletes que ningú no pot distingir de les actuals.
Separeu l’autoritat per publicar de l’exactitud de l’etiqueta. Un registre que vincula una organització amb un recurs demostra l’assignació i no l’ús actual, i són afirmacions diferents amb proves diferents. Els consumidors han de saber en quina de les dues confien.
Definiu també la correcció. Una adreça reassignada a un client, o un servei no relacionat atrapat per una etiqueta incorrecta, necessita un camí documentat cap a una solució en lloc d’una discussió en una cua de tiquets. El desencadenant de la retirada pertany al mateix document que la regla de publicació.
Què pot i què no pot suportar un feed publicat
Els atributs de prefix publicats són un patró consolidat, i els exemples existents descriuen geografia o propietat, no comportament. Un feed VPN necessitaria la seva pròpia semàntica, les seves pròpies regles de prova i el seu propi procés de revisió, i canviar el nom d’una llista de països no en proporciona cap. La guia del registre ARIN mostra què afirmen i què no els registres d’assignació, i un feed nou ha de guanyar la mateixa claredat sobre les seves pròpies afirmacions. Això és una tasca d’especificació, no de reetiquetatge.
El que un feed així pot suportar és una decisió de classificació sobre una font de xarxa. El que no pot fer és identificar una persona darrere d’una adreça compartida, demostrar que tot el trànsit d’aquella adreça va per un túnel o decidir si una petició concreta és abusiva. Són tres preguntes separades amb tres requisits de prova separats.
Manteniu la qüestió legal fora de l’especificació
Una especificació tècnica no pot resoldre si un requisit de registre proposat és legal, proporcionat o assenyat. Aquesta avaluació necessita el text legislatiu real, els drets afectats, la jurisdicció i una anàlisi jurídica que un format de dades no pot proporcionar. Un format pot estar ben dissenyat i tot i així donar suport a una mala política.
El que l’especificació pot fer és fer concret el debat. Definiu primer les dades proposades, els seus límits i les seves maneres de fallar, perquè l’argument polític giri al voltant d’un mecanisme real i no d’una llista indefinida que cada participant imagina de manera diferent. Això és el màxim que un document tècnic pot aportar a una qüestió legal.