O que deveria realmente registar um registo de endereços de saída VPN?
Um registo de saídas só é útil se cada entrada declara o seu significado, o seu editor e a sua validade. A classificação não é a identificação do assinante.
Os registos de saída soam como listas, e a lista não é a parte difícil. A parte difícil é decidir o que cada entrada afirma, quem pode publicá-la e o que acontece quando a afirmação deixa de ser verdadeira. Nestas propostas confundem-se três papéis de endereço diferentes, e um registo que os mistura não consegue responder a nenhuma pergunta de forma fiável. Siga uma entrada desde a publicação até à retirada e os requisitos de conceção aparecem por si próprios.
Comece pelo registo, não pela lista
A primeira pergunta não é quantos endereços incluir, mas o que significa uma única linha. Descreve onde os clientes se ligam, que origem um destino pode ver, ou quem detém uma atribuição num registo? São três afirmações com três proprietários e três modos de falha. Um registo que não indica qual delas regista não pode ser validado, corrigido ou expirado. Acertar no significado é o trabalho de conceção, e a lista é apenas o resultado.
Escreva a definição da linha antes de escrever qualquer esquema. Se a definição precisar da palavra e, provavelmente são dois registos a fingir ser um.
Três papéis de endereço que se parecem
Os papéis são fáceis de confundir porque uma implementação pode usar os três ao mesmo tempo, e muitas vezes fá-lo. Um serviço pode terminar ligações num endereço e encaminhar tráfego de outro, enquanto um registo anota um terceiro facto completamente diferente.
| 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 |
Um bloco de alojamento pode conter saídas VPN e cargas de trabalho não relacionadas lado a lado, pelo que uma correspondência no registo não diz nada sobre o que um determinado endereço faz num determinado momento. Uma entrada que não nomeia o seu papel não é prova de nada em particular. É nomear o papel que torna o registo refutável. Indique também a família de endereços, porque um registo que só cobre IPv4 em silêncio enganará quem assumir o contrário.
Siga uma entrada desde a publicação até à retirada
Pegue numa saída hipotética e siga-a. Um operador publica o prefixo e o seu papel num momento de entrada em vigor declarado, os consumidores obtêm-no e, mais tarde, o endereço deixa de servir como saída. Cada passo exige uma regra: quem pode publicar, o que o prefixo cobre realmente, quando a entrada entra em vigor e como é retirada. Um feed sem caminho de retirada acumula afirmações desatualizadas que ninguém consegue distinguir das atuais.
Separe a autoridade para publicar da exatidão da etiqueta. Um registo que liga uma organização a um recurso prova a atribuição e não o uso atual, e são afirmações diferentes com provas diferentes. Os consumidores precisam de saber em qual das duas confiam.
Defina também a correção. Um endereço reatribuído a um cliente, ou um serviço não relacionado apanhado por uma etiqueta incorreta, precisa de um caminho documentado para uma correção em vez de uma discussão numa fila de tickets. O gatilho de retirada pertence ao mesmo documento que a regra de publicação.
O que um feed publicado pode e não pode suportar
Os atributos de prefixo publicados são um padrão consolidado, e os exemplos existentes descrevem geografia ou propriedade em vez de comportamento. Um feed VPN precisaria da sua própria semântica, das suas próprias regras de prova e do seu próprio processo de revisão, e renomear uma lista de países não fornece nada disso. O guia do registo ARIN mostra o que os registos de atribuição afirmam e não afirmam, e um novo feed tem de conquistar a mesma clareza sobre as suas próprias afirmações. É uma tarefa de especificação, não de reetiquetagem.
O que um tal feed pode suportar é uma decisão de classificação sobre uma origem de rede. O que não pode fazer é identificar uma pessoa por trás de um endereço partilhado, provar que todo o tráfego desse endereço é encaminhado por um túnel, ou decidir se um pedido concreto é abusivo. São três perguntas separadas com três requisitos de prova separados.
Mantenha a questão jurídica fora da especificação
Uma especificação técnica não pode decidir se um requisito de registo proposto é legal, proporcional ou sensato. Essa avaliação exige o texto legislativo real, os direitos afetados, a jurisdição e uma análise jurídica que um formato de dados não pode fornecer. Um formato pode estar bem concebido e ainda assim apoiar uma má política.
O que a especificação pode fazer é tornar o debate concreto. Defina primeiro os dados propostos, os seus limites e os seus modos de falha, para que o argumento político incida sobre um mecanismo real e não sobre uma lista indefinida que cada participante imagina de forma diferente. É o máximo que um documento técnico pode contribuir para uma questão jurídica.