Resumo

  • A página principal de certificação de recursos da AFRINIC chama um link ativo de “RIPE NCC Validator”, mas o destino se identifica como Routinator; outra página da própria AFRINIC já usa o nome atual.
  • A URL contínua evita um beco sem saída, mas não preserva a identidade do software. Um manifesto deve ligar rótulo, implementação, mantenedor, operador, suporte, versão testada, uso pretendido e migração.

Há uma diferença importante entre conservar um serviço e conservar sua identidade. Na página Resource Certification Program da AFRINIC, a seção de validadores apresenta “RIPE NCC Validator”. O endereço apontado, https://rpki-validator.ripe.net/ui/, responde normalmente. Só que o título do documento é “Routinator”, e a descrição informa que se trata da interface do Routinator.

O link não está quebrado. A história que o rótulo conta é que ficou incompleta.

Em 15 de junho de 2021, o RIPE NCC anunciou que encerraria o suporte ao seu RPKI Validator em 1º de julho. Recomendou a migração para alternativas e explicou que continuar executando um software sem atualizações poderia levar a incidentes de segurança. Em 10 de setembro, publicou como a continuidade do serviço seria tratada: a interface pública em rpki-validator.ripe.net passaria para o Routinator em 16 de setembro.

A troca foi explícita. O domínio permaneceu como ponto de acesso; a implementação mudou.

A segunda página já conhece o nome novo

A AFRINIC mantém validator.afrinic.net, uma página intitulada “RPKI Relying Party Software”. Ela lista AFRINIC Rcynic e AFRINIC Routinator como serviços hospedados localmente. Entre as outras opções, o mesmo endereço do RIPE aparece como “RIPE NCC: Routinator”. O destino, a página secundária e o relato histórico do RIPE NCC concordam entre si.

Na página principal, ficou o nome do produto anterior. O bloco também menciona RPKI.net rcynic e RPSTIR sem exibir versão, mantenedor, estado de suporte ou data de verificação. Esses campos ausentes não autorizam concluir que os projetos estejam abandonados, vulneráveis ou em uso pela AFRINIC. A evidência permite uma afirmação menor: o catálogo não oferece dados públicos para que o leitor faça essa distinção.

A resposta mais favorável à AFRINIC é convincente. A pessoa que clica chega ao Routinator, não a um pacote antigo. A outra página dá o nome correto. Equipes maduras escolhem software de produção nos canais do projeto e nos repositórios mantidos, consultam notas de versão e validam sua configuração. Nessa prática, um rótulo atrasado parece um defeito editorial de baixo impacto.

Mas documentos públicos viram dependências indiretas. Um nome é copiado para inventários, treinamentos, especificações de compra e planos de resposta. “RIPE NCC Validator” aponta para uma linhagem encerrada; “Routinator” aponta para outro código, outro mantenedor e outro ciclo de lançamento. A estabilidade da URL não transforma essas identidades em equivalentes. Ela apenas reduz a chance de alguém perceber a substituição.

O leitor RPKI participa da cadeia de prova

A RFC 8897 descreve o software de relying party como o componente que adquire e verifica dados de recursos numéricos nos repositórios RPKI. A informação validada pode apoiar decisões BGP. O documento reúne requisitos espalhados por treze RFCs em quatro grupos: busca e cache de objetos, processamento de certificados e listas de revogação, processamento de objetos assinados e distribuição do conjunto validado.

Por isso, o nome do produto não é mera apresentação. Ele identifica uma implementação com padrões, valores predefinidos, correções, formatos de saída e responsáveis. Saber o nome não garante que uma decisão de rota esteja certa, mas permite reconstruir qual leitor produziu o resultado.

A documentação estável da NLnet Labs dá a identidade atual. O Routinator 0.15.2 publica sua interface HTTP no caminho /ui, com Prefix Check e informações sobre a última rodada de validação, conexões HTTP e RPKI-to-Router. O título, a descrição e o caminho do serviço vivo do RIPE correspondem a essa documentação.

Há ainda uma diferença entre software e instância hospedada. O RIPE NCC registrou que sua página pública era um serviço de melhor esforço e não deveria ser usada como dependência de produção com disponibilidade garantida. Assim, uma lista responsável precisa separar o mantenedor do código, o operador daquela instância e o uso que está sendo sugerido.

Registrar a troca sem certificar o mundo

Não cabe à AFRINIC prometer a segurança de todo projeto de terceiros ou escolher um único validador para todos. Cabe tornar verificável a associação que sua página já apresenta.

Um manifesto versionado de orientação para relying parties pode guardar, por item:

  • rótulo exibido e nome canônico do produto;
  • projeto de implementação e mantenedor atual;
  • operador do serviço hospedado, URL solicitada e destino final;
  • situação do ciclo de vida, linha suportada e data da última revisão;
  • função que a AFRINIC de fato conferiu;
  • finalidade declarada: demonstração, consulta de melhor esforço, avaliação ou produção;
  • produto anterior, destino da migração e aviso oficial;
  • data e motivo de correção, retirada ou arquivamento.

O histórico precisa continuar público. Uma edição silenciosa para “Routinator” melhora a orientação de hoje, mas apaga a resposta sobre quando a AFRINIC incorporou a migração de 2021. Encerrar a linha antiga e abrir outra cria uma trilha de decisão.

Também é preciso limitar o significado dos testes. HTTP 200 prova resposta do servidor. O título ajuda a identificar a aplicação. Uma validação de versão exige número e função. Aprovação para produção é uma decisão diferente. Um único selo “verificado” não pode absorver todos esses níveis.

O limite factual

Nada nas páginas mostra a AFRINIC distribuindo ou operando o RIPE NCC Validator aposentado. O link funciona e chega ao Routinator. Não há prova de que um operador instalou o software errado, de falha no repositório da AFRINIC, de ROA ou VRP incorreto, de mudança indevida em rota ou de incidente de segurança.

A falta de uma data pública de revisão também não prova que ninguém revisou a página. Pode haver controle interno recente. O ponto é que um terceiro não consegue verificá-lo.

O caso é pequeno, mas completo. O RIPE NCC encerrou o suporte a um produto, preservou o endereço público, migrou o serviço e documentou a mudança. Uma página da AFRINIC reconhece a nova implementação; outra mantém a identidade anterior. Se o RPKI existe para tornar alegações de recursos verificáveis, a identidade do software que as interpreta não deveria depender de uma inferência a partir do destino atual.

Fontes