Resumo

  • O projeto estruturou o teste em três confirmações: operação normal, proteção contra rotas Invalid e capacidade de resposta quando algo desse errado.
  • O registro público sustenta uma passagem limitada do experimento para uma diretriz. Não comprova rejeição em produção pelas 18 participantes, ausência de incidentes ou poder da JANOG ou da JPNIC sobre a política dos ASes.

Um controle de segurança de roteamento não está completo quando apenas sabemos ligá-lo. É preciso saber quem observa um efeito inesperado, quem pode mudar a política e como a rede volta a um estado conhecido. O experimento japonês de ROV de 2023 incorporou essas perguntas ao teste, antes de chamar a adoção de bem-sucedida.

As chamadas “três confirmações” perguntavam se a operação seguiria normal depois da introdução do mecanismo, se haveria proteção contra rotas Invalid e se o operador conseguiria reagir diante de uma falha. Isso não equivale a afirmar que ROV não oferece risco. Significa tratar a reversibilidade como requisito do próprio controle.

O trabalho chegou ao debate público na JANOG52, em 5 de julho de 2023. A JANOG reuniu a comunidade e publicou o programa e os materiais de Taiji Kimura, da JPNIC, Katsushi Yamaguchi, da BIGLOBE, e Osamu Nakamura, da Universidade Keio e da WIDE. Ser o fórum e publicar os documentos não tornou a JANOG dona do projeto, reguladora ou operadora das redes participantes.

A cadeia de autoridade tinha vários níveis. O Ministério de Assuntos Internos e Comunicações do Japão patrocinou o projeto. A NTT Communications foi a contratada principal. O Mitsubishi Research Institute e a JPNIC participaram como subcontratados de apoio. A JPNIC planejou partes dos experimentos de RPKI e DNSSEC, desenhou e operou ambientes, reuniu resultados e depois publicou a diretriz. As universidades Keio, Osaka por meio do Cyber Kansai Project e a Universidade de Nagasaki hospedaram instalações. As organizações participantes fizeram os testes. Cada sistema autônomo manteve a decisão sobre sua política de rotas.

O relatório da JPNIC para o ano fiscal de 2023 registra 18 empresas em RPKI, oito em DNSSEC e dez em DMARC. São contagens de participação em frentes do projeto, não de implantação em produção, ativação de rejeição ou certificação independente de sucesso.

Havia três caminhos: experiência prática, experimento no ambiente do projeto e verificação no ambiente do participante. A separação impede que todo o trabalho seja descrito como teste em produção. O material público não identifica qual empresa seguiu cada caminho nem se alguma sessão BGP com tráfego ou política ativa foi alterada.

Nos ambientes de teste, era possível introduzir deliberadamente rotas BGP Invalid e observar o ROV com dados de ROA. O conjunto incluía roteadores virtuais ou físicos de Arista, Cisco, Juniper e Nokia. Cobertura de vários fornecedores amplia o aprendizado; não comprova equivalência funcional, segurança em produção ou comportamento sem falhas em qualquer escala.

A diretriz atual da JPNIC preserva a ordem do exercício. Primeiro, recomenda aplicar a validação ainda aceitando rotas Invalid, para observar carga e rotas afetadas. Depois, verificar exemplos Invalid deliberados. Por fim, confirmar que SLURM ou uma política do roteador pode restaurar uma rota classificada como Invalid de forma não intencional.

A recuperação, portanto, integra o desenho. A diretriz descreve a retirada da política ROV, verificações depois da reinicialização do roteador, reconexão ao cache e tratamento de classificações Invalid inesperadas. Se uma desconexão do cache puder ultrapassar o tempo de retenção, ela considera parar ROV para um vizinho ou roteador ou usar SLURM para que rotas Invalid ou NotFound não sejam descartadas.

Reverter também exige governança. O SLURM cria uma visão local e personalizada das informações RPKI; não corrige o sistema global. Uma exceção pode manter a conectividade e, ao mesmo tempo, criar uma decisão local de confiança. As fontes não informam quem aprovou cada exceção, por quanto tempo ela permaneceu ou como foi reconciliada depois.

A RFC 6811 explica a fronteira da política. O estado de validação é uma propriedade local da rota. A validação, sozinha, não deve excluí-la; filtrar ou mudar a preferência requer política local explícita. O padrão ainda alerta que dados de validação manipulados podem criar um vetor de negação de serviço. ROV verifica a relação entre um prefixo e o AS de origem, não o caminho AS completo, e um estado tecnicamente correto não escolhe automaticamente a ação operacional.

Uma apresentação trouxe uma fotografia da RIB do AS2500 às 09h00 de 8 de março de 2023: 905.690 rotas IPv4, das quais 77 Invalid, e 170.405 IPv6, das quais 231 Invalid. É a visão armazenada de um AS em um instante. Não mede pacotes, clientes ou perda de alcance, nem representa o impacto de rejeitar essas rotas no Japão inteiro.

O aprendizado continuou. O relatório da JPNIC registra uma sessão JANOG52.5 sobre o experimento e a diretriz. A JPNIC depois publicou formalmente o documento; a versão 1.1 estava vigente em 27 de março de 2026 e era mantida por uma equipe de especialistas. Isso mostra memória institucional, não adoção universal.

O resultado mais defensável é contido: o operador deveria conseguir detectar um resultado indesejado, manter a autoridade para agir e voltar atrás. O registro não diz quantas participantes precisaram fazer isso, quanto demoraram ou que impacto enfrentaram.