Resumo

  • Em 20 de julho, a LACNIC disse que o FORT 1.7.0 valida objetos ASPA e compartilha a informação com roteadores; o texto também reconhece que a tecnologia ainda não foi publicada oficialmente como padrão e permanece experimental.
  • Na versão 1.7.0.experimental, --server.max-rtr-version vale 0 por padrão, embora a documentação reserve a entrega de ASPAs aos roteadores para o RTRv2. A saída em arquivo --output.aspa também nasce desabilitada.
  • Um registro confiável deve distinguir código disponível, configuração, versão negociada, objetos validados, resultado do caminho e política aplicada.

O recurso novo veio acompanhado de uma trava, e a posição inicial da trava é zero.

O post da LACNIC apresenta o FORT 1.7.0 como um validador que processa objetos ASPA já encontrados em alguns repositórios RPKI e compartilha a informação com os roteadores. A versão publicada no GitHub em 16 de julho de 2026 usa o nome completo 1.7.0.experimental, informa que implementa ASPA e RTRv2 e deixa claro que a versão RTR máxima do servidor é zero por padrão.

O primeiro documento conta o que o programa é capaz de fazer. O segundo conta o que ocorre antes de uma escolha do operador. Não há motivo para chamar o anúncio de falso, nem para transformar uma opção cautelosa em defeito. A própria LACNIC diz que ASPA ainda pode mudar. O release explica que o FORT não entrega chaves de roteador, reduzindo a utilidade do RTRv1 nesse produto, e que o RTRv2 continua em elaboração.

A pergunta de governança é outra: quais evidências ligam o pacote divulgado à política de roteamento que de fato entrou em vigor?

Um recurso, três superfícies

O manual preso à tag 1.7.0.experimental separa três decisões.

Parâmetro Padrão Efeito
--aspa.max-providers 4.000 Limita os ASN provedores aceitos para um ASN cliente em cada ciclo
--output.aspa NULL (desabilitado) Define se os ASPAs válidos serão gravados em JSON num arquivo ou enviados à saída padrão quando recebe um hífen ()
--server.max-rtr-version 0 Define a maior versão RPKI-to-Router negociável com clientes

O limite de validação não abre a saída de arquivo. A saída de arquivo não abre o protocolo para roteadores. E elevar o protocolo não define a política de seleção de rotas.

O manual diz que RTRv0 fornece registros de validação de prefixos, RTRv1 acrescenta chaves de roteador e RTRv2 acrescenta ASPAs. Assim, com a configuração inicial, o FORT pode reconhecer um objeto ASPA, e pode exportá-lo para um arquivo ou para a saída padrão quando --output.aspa recebe um hífen (), mas uma sessão negociada em v0 não recebe o PDU ASPA pertencente à v2.

Isso não demonstra que todos deixaram o recurso desligado. Basta um operador ajustar o teto para 2 e usar um cliente compatível para abrir o caminho. O que a documentação demonstra é somente a fronteira do comportamento inicial.

A versão negociada é parte do fato

A revisão 27 do RTRv2 manda o roteador começar pela maior versão que implementa. O cache responde nessa versão quando pode; em certas combinações, a sessão desce para uma versão compatível inferior. Após o rebaixamento, os recursos mais novos não ficam disponíveis naquela sessão.

Portanto, escrever max-rtr-version=2 registra intenção, não entrega. O roteador ainda precisa solicitar v2, concluir a negociação, receber os dados e executar o próximo estágio. Uma auditoria que olha apenas o arquivo de configuração perde o resultado do handshake; uma auditoria que olha apenas a sessão perde o uso posterior.

A cadeia pode parar em pelo menos seis lugares: pacote errado, objeto rejeitado, saída não configurada, teto abaixo de 2, cliente em versão menor ou ausência de política sobre o estado calculado. Cada falha exige uma correção diferente. Colocá-las sob o rótulo ASPA ativo só esconde a causa.

Objeto válido, caminho válido e rota aceita são fatos diferentes

O perfil ASPA define o objeto assinado pelo titular do ASN cliente para autorizar seus provedores. A validação confirma se o objeto satisfaz as regras da RPKI e do perfil. Ela ainda não julgou o AS_PATH visto por um roteador.

Esse julgamento aparece no texto de verificação ASPA, que produz Valid, Unknown ou Invalid. A recomendação torna Invalid inelegível e trata Unknown com a mesma preferência de Valid, mas a mitigação específica fica a critério do operador.

Consequentemente, contar objetos aceitos comprova a camada de relying party. Negociar v2 comprova o transporte. Contar os três estados comprova o cálculo. Só RIB, FIB e política documentada mostram a ação. Receber dados não equivale a rejeitar uma rota.

Também seria injusto concluir que v0 significa ausência de segurança. A validação de origem continua nos protocolos anteriores, e a saída JSON pode apoiar testes. A conclusão sustentada é menor: o FORT contém uma implementação experimental de ASPA, mas o percurso até uma decisão exige ativação explícita e autoridade local.

Software experimental precisa carregar a revisão

O manual identifica draft-ietf-sidrops-8210bis-25 como base da implementação. No corte desta pesquisa, o documento atual era a revisão 27. O perfil ASPA estava na revisão 29, enquanto a verificação do caminho chegou à 28.

Essa sequência não prova quebra de compatibilidade. Revisões podem mudar apenas texto ou podem mudar comportamento; é preciso comparar e testar. Mas ela impede que suporta RTRv2 seja aceito como procedência suficiente. Para repetir um resultado, é necessário conhecer revisão, commit, binário e par interoperável.

RFC 8210 documenta a versão 1 publicada. O PDU ASPA pertence ao trabalho de versão 2 ainda em forma de Internet-Draft. O padrão zero torna-se compreensível nesse contexto e, ao mesmo tempo, torna indispensável registrar a migração futura.

Número de downloads não resolve o problema. Download não é instalação; instalação não é processo; processo não é sessão v2; sessão v2 não é mitigação.

Ficha pública e recibo local

O projeto pode publicar uma ficha de capacidade sem observar redes privadas. Ela registra tag e commit, nomes e hashes de pacotes, revisões de perfil, protocolo e verificação, padrões e limites, desvios conhecidos, clientes testados e caminho de substituição ou rollback.

O operador gera o recibo de ativação. Ele liga hash do pacote, início do processo e impressão da configuração ao teto RTR; resume clientes por versão negociada; registra horário e serial do ciclo, ASPAs aceitos e rejeitados por classe, saída JSON e hash, modo de verificação, contagem de estados, política de mitigação, exceções e retorno.

Identidade de roteador e topologia podem permanecer protegidas. Para comunicação pública, agregados por versão e razão bastam. Para resposta a incidente, o recibo detalhado permanece sob controle da rede.

O vínculo entre os registros deve usar o hash do pacote, a revisão implementada e a impressão da configuração. Sem isso, a ficha descreve comportamento possível e o recibo descreve um processo sem nome. Juntos, eles provam qual capacidade atravessou a fronteira operacional.

O que não pode ser inferido

As fontes não informam quantas organizações instalaram o release, elevaram o teto, negociaram v2, validaram um objeto pertinente ou alteraram a escolha de rota. Não provam que a LACNIC exagerou, que a opção correta seria ativar v2 para todos ou que as revisões 25 e 27 são incompatíveis.

ASPA tampouco cobre toda a segurança do BGP. Ele oferece evidência sobre provedores e ajuda a detectar vazamentos; não valida o plano de encaminhamento, não elimina estado Unknown e não substitui decisões locais.

O conjunto comprova algo mais preciso: FORT 1.7.0.experimental trouxe ASPA e RTRv2, manteve a interface para roteadores em v0 e a saída em arquivo desligada por padrão, e deixou a mitigação sob autoridade do operador. Esse é o ponto em que tem a função deixa de responder a função foi usada.

Fontes