A adoção do RPKI na região tem crescido de forma constante nos últimos anos, e com ela surgiu uma confusão recorrente: as pessoas falam do “RPKI” como se fosse uma coisa só que pode ser ativada ou desativada. Na verdade, são várias peças diferentes, e a ASPA (Autorização de Provedores de Sistemas Autônomos), a incorporação mais recente, é muito melhor compreendida se primeiro as separarmos.
Três peças que não devem ser misturadas.
O RPKI é a infraestrutura de chave pública que associa recursos de numeração a certificados, seguindo a cadeia de delegação real desses recursos (RFC 6480). Por si só, não toma decisões de roteamento: é a base sobre a qual os objetos são assinados, quer dizer, afirmações verificáveis sobre esses recursos.
Um ROA é um desses objetos (RFC 9582). Nele, o titular de um bloco de endereços declara qual AS está autorizado a originar esse prefixo no BGP. Trata-se de uma afirmação publicada; não tem efeito por si só.
(Acesso livre, não requer assinatura)
ROV é o procedimento que a operadora executa em seus roteadores (RFC 6811): compara cada anúncio BGP recebido com os ROA validados e o classifica como Valid, Invalid o NotFound. O que fazer com esse resultado é uma decisão de política local.
A distinção tem uma consequência prática. Publicar um ROA protege os próprios prefixos contra quem faz ROV; fazer ROV protege a própria rede contra os anúncios incorretos de terceiros. São ações diferentes, com beneficiários diferentes, e nenhuma implica a outra.
O que a validação de origem (ROV) não consegue ver
ROV responde a uma única pergunta: o AS que origina este prefixo está autorizado a originar? Isso é suficiente para detectar o sequestro de origem clássico, e é motivo suficiente para implantá-lo.
ROV é o procedimento que a operadora executa em seus roteadores (RFC 6811): compara cada anúncio BGP recebido com os ROA validados e o classifica como Valid, Invalid o NotFound. O que fazer com esse resultado é uma decisão de política local.
A distinção tem uma consequência prática. Publicar um ROA protege os próprios prefixos contra quem faz ROV; fazer ROV protege a própria rede contra os anúncios incorretos de terceiros. São ações diferentes, com beneficiários diferentes, e nenhuma implica a outra.
O que a validação de origem (ROV) não consegue ver
ROV responde a uma única pergunta: o AS que origina este prefixo está autorizado a originar? Isso é suficiente para detectar o sequestro de origem clássico, e é motivo suficiente para implantá-lo.
Porém, o ROV olha apenas para a origem e não diz nada sobre o restante do AS_PATH. Daí derivam dois problemas que não consegue deter.
O primeiro são os vazamentos de rota ou route leaks: a propagação de um anúncio além do seu escopo previsto (RFC 7908), tipicamente um ASmultihomed que repassa a um provedor o que aprendeu de outro. A origem é legítima e o ROA coincide, de modo que para o ROV, o anúncio é Valid. O que está errado não é a origem, mas sim a forma do caminho
O segundo é o sequestro com origem falsificada. Um atacante não precisa anunciar o prefixo com seu próprio AS: só precisa colocar o AS legítimo antes do AS_PATH e anunciá-lo como se o tivesse aprendido com ele. O anúncio exibe a origem correta, satisfaz o ROA e fica como Valid. O ROV, por construção, não consegue distingui-lo de um anúncio genuíno.
Não se trata de uma falha de implementação. O ROV valida a origem, não o caminho.
O que o ASPA acrescenta?
O ASPA ataca precisamente esse ponto cego. O titular de um AS publica um objeto assinado que enumera os AS autorizados a atuar como seus provedores de trânsito: o mesmo tipo de afirmação de um ROA, mas referente a relações de peering em vez de origem de prefixos.
Com um conjunto suficiente de ASPA publicados, o operador pode verificar se cada salto do AS_PATH corresponde a uma relação cliente-fornecedor efetivamente autorizada. Não é mais preciso acreditar no caminho: ele é confrontado com declarações assinadas pelos titulares de cada AS.
A verificação se apoia na forma que tem um caminho legítimo. Ela sobe por uma cadeia de relacionamentos cliente-fornecedor, cruza opcionalmente um enlace lateral entre pares e desce por outra cadeia. São a rampa ascendente e a rampa descendente.
Estrutura de um AS_PATH legítimo. As setas indicam relações cliente-fornecedor, e não o sentido de propagação do anúncio.
O procedimento percorre o caminho recebido e verifica que ele tenha essa forma, usando um critério que depende de quem enviou a rota: se ela vier de um cliente ou de um peer, não deveria haver rampa descendente, e o seu aparecimento é justamente a assinatura de um route leak. O resultado é Valid, Invalid ou Unknown, sendo este último quando as informações do ASPA são insuficientes para tomar uma decisão.
É importante não misturar vocabulários: onde o ROV diz NotFound, o ASPA diz Unknown. Um anúncio pode ser perfeitamente Valid para o ROV e Invalid para o ASPA, e é esse exatamente o caso que o ASPA veio resolver.
Onde o ASPA está hoje
É importante ser explícito, porque há muita confusão circulando: O ASPA ainda não é um RFC. Os dois documentos principais continuam sendo Internet-Drafts no grupo de trabalho SIDROPS do IETF. Já existem implementações —FORT, Routinator e rpki-client processam objetos ASPA— e um número crescente de RIR permite publicá-los, mas os detalhes ainda podem mudar, principalmente em relação ao algoritmo de validação.
A cobertura ainda é logicamente baixa: no início de 2026, os ASPA publicados representavam consideravelmente menos de um por cento do espaço global de ASN. Hoje, a enorme maioria dos caminhos resultaria em Unknown. É a mesma curva que o ROA percorreu há uma década.
No entanto, acredito que o fato de existir um movimento incipiente de criação de ASPA, mesmo que o trabalho de padronização no IETF ainda não tenha concluído, demonstra um forte interesse da comunidade de operadores.
Para um operador que esteja avaliando o que fazer, a ordem de prioridades não mudou: publicar ROA corretos para os prefixos próprios e implantar ROV continuam sendo o primeiro passo. O ASPA se apoia sobre esse trabalho em vez de substituí-lo.
