Resumo

  • O proponente da ACSP 2026.4 disse que, depois de fazer uma Detailed Reassignment para outra Org, a chave da organização de origem não conseguia consultar o NET filho pelo handle. A chave da destinatária conseguia; a origem, segundo o relato, ainda podia DELETE o objeto e fazer GET via mostSpecificNet com início e fim exatos.
  • A ARIN encerrou a sugestão em 30 de março de 2026. Após discutir outros meios de obter a informação e planos futuros, considerou desnecessária uma mudança de permissão naquele momento. A resposta não confirma individualmente os testes relatados, e Closed não comprova implantação.
  • A assimetria protege uma separação real: a destinatária de uma reassignment detalhada administra o registro; o registrante direto retém o reclaim. Dados públicos de Whois/RDAP não são equivalentes ao NET Payload autenticado.
  • A solução proporcional é um preflight de reclaim com poucos campos, token de versão e previsão de dependências, acompanhado por uma matriz pública que relacione ator, vínculo, classe de NET, identificador, verbo, campos, condição e resultado.

Um registro de Internet não guarda apenas intervalos. Ele guarda relações de responsabilidade. Quando uma rede passa por uma Detailed Reassignment, a organização destinatária recebe autoridade de gestão; a organização de origem não deixa de responder pelo espaço que poderá precisar recuperar. O desenho de permissões precisa preservar as duas coisas sem fingir que elas são a mesma coisa.

A orientação de gestão da ARIN distingue reassignment simples, detalhada e reallocation. Um cliente simples não tem capacidade direta de gestão. Uma Org que recebe uma reassignment detalhada tem. O registrante direto mantém poder de reclaim, e alguns controles de DNS reverso e IRR podem ser compartilhados. Na reallocation, a destinatária pode seguir delegando.

Esse arranjo é a melhor defesa para permissões assimétricas. O pai não precisa ver nem editar todos os detalhes administrados pela Org receptora só porque conserva o direito de encerrar a relação. A própria especificação do NET Payload mostra o motivo: a carga pode reunir versão, comentários, data, identificador da Org ou do cliente, bloco, pai, nome, origin AS e vínculos POC. Um diretório público pode exibir parte da identidade registral sem abrir a mesma superfície de provisionamento.

Portanto, DELETE não precisa implicar GET completo, e GET não precisa implicar PUT. A pergunta mais estreita é se o ator que já tem uma autoridade destrutiva consegue verificar a identidade e o estado mínimo do alvo antes de usá-la.

O caso foi relatado, não certificado

Na ACSP 2026.4, apresentada em 3 de março de 2026, o autor descreveu a criação de uma Detailed Reassignment a partir de um NET próprio para outra Org. A tentativa de GET do filho pelo handle, usando a chave do pai, teria sido negada. Apenas a chave da destinatária obteria o objeto por esse caminho.

O autor disse ainda que a origem conseguia apagar o NET, consultá-lo pelo início e fim exatos com mostSpecificNet e ver informações públicas no Whois por handle ou endereço IP. Daí derivou a proposta de permitir GET e PUT ao pai, pois ele poderia apagar e recriar.

Em 30 de março, a ARIN respondeu que havia discutido outras formas de recuperar a informação com ferramentas existentes e planos de desenvolvimento futuros. Concluiu que mudar as verificações de permissão era desnecessário naquele momento. O proponente concordou com o encerramento.

Essa página é uma fonte oficial sobre o que foi alegado e sobre a decisão da ARIN. Não é um teste independente, um aviso de vulnerabilidade ou um relatório de incidente. A resposta não declara que cada passo foi reproduzido. Não há registro de exclusão indevida, interrupção ou exposição. Também não se pode afirmar que toda conta e todo NET atuais se comportem assim.

O limite probatório ajuda a formular a análise correta. Não se trata de acusar um defeito; trata-se de avaliar se a documentação pública dá aos operadores uma pré-condição segura para os comportamentos que a instituição pretende permitir.

O handle resolve identidade; a faixa exata confirma memória

O catálogo Reg-RWS descreve quatro métodos centrais. O GET por NETHANDLE devolve NET Payload. O GET mostSpecificNet recebe STARTIP/ENDIP e também devolve NET Payload. DELETE por handle devolve Ticketed Request Payload. PUT por handle recebe e devolve NET Payload.

Os dois GET não são substitutos perfeitos. O handle é uma identidade estável atribuída pelo registro. A faixa exata é uma propriedade que o cliente precisa conhecer antes da chamada. Whois e RDAP formam uma terceira superfície, pública e orientada a descoberta.

A ACSP 2023.13 registrou justamente a limitação de mostSpecificNet: fornecer início e fim exatos não equivale a partir de qualquer IP contido e descobrir o objeto. Quem consulta precisa ter as duas pontas corretas. Isso funciona como conferência quando o inventário local está bom. Quando ele está defasado, pode apenas repetir ao registro a crença antiga do operador.

Para um humano, ARIN Online pode fechar a lacuna com busca visual. Para um processo em lote, “há outra ferramenta” não define como provar que handle, faixa e relação continuam sincronizados no momento da execução.

A exclusão muda de natureza quando há descendentes

Segundo a ARIN, DELETE só vale para reassignments e reallocations. Se o NET não tiver redes alocadas ou redistribuídas abaixo dele, o processamento pode ser automático, com uma resposta contendo informações do objeto apagado. Se houver descendentes, surge um ticket; o espaço não deve ser redistribuído até o processamento bem-sucedido.

Os passos de exclusão exigem localizar a rede, selecionar seu Net Handle e confirmar uma ação sem volta. Isso demonstra que identidade e topologia são relevantes. O problema é receber a evidência mais completa apenas depois do compromisso.

Na modificação, a orientação de NET Modify recomenda obter primeiro o NET atual. É uma proteção contra estado antigo. O reclaim precisa do mesmo princípio, adaptado a um ator que não deve receber a carga administrativa inteira.

Um preflight limitado poderia devolver:

  • handle estável e faixa normalizada;
  • classe do NET e vínculo de filho direto;
  • tipo de destinatário sem POC privado;
  • presença de NETs descendentes;
  • previsão de processamento automático ou por ticket;
  • resumo de efeitos em DNS, IRR e objetos de rota;
  • notificações e evidência de auditoria esperadas;
  • token curto da versão observada.

O DELETE seguinte carregaria esse token. Alterações relevantes na faixa, hierarquia ou dependências fariam a requisição falhar e exigiriam nova prévia. A origem não obteria controle cotidiano da destinatária. Obteria apenas a informação necessária para confirmar um poder que já possui.

Permissão é uma tupla, não uma coluna

Uma matriz operacional deveria representar:

papel do ator × relação × classe de objeto × caminho de identificação × verbo × conjunto de campos × pré-condição × resultado

“O pai pode deletar NET” é insuficiente porque não informa se o objeto é simples, detalhado ou uma reallocation; se é filho direto; se o ator é administrador, POC ou titular; se a resolução veio de handle, faixa ou diretório; quais campos aparecem; se existe controle de versão; e se o resultado é automático ou ticketed.

A matriz versionada não precisa tornar as células iguais. Pelo contrário: explicaria onde a diferença é deliberada. A Org destinatária recebe a carga que administra. O pai recebe uma prévia de reclaim. O cliente simples não ganha gestão. A reallocation conserva suas regras próprias. Cada célula teria data de vigência, campos imutáveis e caminho seguro de correção.

Isso permitiria testes de contrato. Antes de automatizar, o operador confirmaria que sua combinação de conta, relação, classe e rota produz a resposta esperada. Um erro poderia diferenciar falta de vínculo, caminho inadequado, campo protegido e estado vencido sem revelar dados confidenciais.

Encerrar a sugestão não encerra o contrato

A decisão de não mudar a API pode ser razoável. Interfaces existentes atendem casos reais, e planos futuros competem por capacidade. O proponente aceitou a conclusão.

Mas Closed é o estado da sugestão. Não demonstra correção implantada, confirmação integral ou abandono permanente. A expressão “neste momento” mantém a decisão corretamente limitada no tempo.

Se a regra pretendida é que o registrante direto possa reclaim sem receber o NET Payload completo por handle, a documentação deve dizer isso de modo inequívoco. Se a faixa exata ou ARIN Online é o preflight recomendado, deve explicitar o inventário necessário, os campos retornados e a maneira de reconhecer mudança de estado.

Menor privilégio não é privar o ator de toda evidência. É entregar o mínimo suficiente para a finalidade autorizada. O mínimo de um DELETE irreversível inclui saber qual objeto atual será atingido e quais condições mudam sua execução.