{"id":34259,"date":"2026-09-09T16:13:46","date_gmt":"2026-09-09T16:13:46","guid":{"rendered":"https:\/\/blog.lacnic.net\/?p=34259"},"modified":"2026-09-09T16:16:55","modified_gmt":"2026-09-09T16:16:55","slug":"rpki-aspa","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/pt-br\/rpki-aspa\/","title":{"rendered":"Uma introdu\u00e7\u00e3o \u00e0 ASPA"},"content":{"rendered":"\n

Por Carlos Mart\u00ednez<\/a>, Chief Technology Strategist<\/em> do LACNIC<\/p>\n\n\n\n

A ado\u00e7\u00e3o do RPKI na regi\u00e3o tem crescido de forma constante nos \u00faltimos anos, e com ela surgiu uma confus\u00e3o recorrente: as pessoas falam do \u201cRPKI\u201d como se fosse uma coisa s\u00f3 que pode ser ativada ou desativada. Na verdade, s\u00e3o v\u00e1rias pe\u00e7as diferentes, e a ASPA (Autoriza\u00e7\u00e3o de Provedores de Sistemas Aut\u00f4nomos), a incorpora\u00e7\u00e3o mais recente, \u00e9 muito melhor compreendida se primeiro as separarmos.<\/p>\n\n\n\n

<\/a>Tr\u00eas pe\u00e7as que n\u00e3o devem ser misturadas.<\/h2>\n\n\n\n

O RPKI<\/strong> \u00e9 a infraestrutura de chave p\u00fablica que associa recursos de numera\u00e7\u00e3o a certificados, seguindo a cadeia de delega\u00e7\u00e3o real desses recursos (RFC 6480). Por si s\u00f3, n\u00e3o toma decis\u00f5es de roteamento: \u00e9 a base sobre a qual os objetos s\u00e3o assinados, quer dizer, afirma\u00e7\u00f5es verific\u00e1veis \u200b\u200bsobre esses recursos.<\/p>\n\n\n\n

Um ROA<\/strong> \u00e9 um desses objetos (RFC 9582). Nele, o titular de um bloco de endere\u00e7os declara qual AS est\u00e1 autorizado a originar esse prefixo no BGP. Trata-se de uma afirma\u00e7\u00e3o publicada; n\u00e3o tem efeito por si s\u00f3.<\/p>\n\n\n\n

ROV<\/strong> \u00e9 o procedimento que a operadora executa em seus roteadores (RFC 6811): compara cada an\u00fancio BGP recebido com os ROA validados e o classifica como Valid, Invalid o NotFound. O que fazer com esse resultado \u00e9 uma decis\u00e3o de pol\u00edtica local.<\/p>\n\n\n\n

A distin\u00e7\u00e3o tem uma consequ\u00eancia pr\u00e1tica. Publicar um ROA protege os pr\u00f3prios prefixos contra quem faz ROV; fazer ROV protege a pr\u00f3pria rede contra os an\u00fancios incorretos de terceiros. S\u00e3o a\u00e7\u00f5es diferentes, com benefici\u00e1rios diferentes, e nenhuma implica a outra.<\/p>\n\n\n\n

<\/a>O que a valida\u00e7\u00e3o de origem (ROV) n\u00e3o consegue ver<\/h2>\n\n\n\n

ROV responde a uma \u00fanica pergunta: o AS que origina este prefixo est\u00e1 autorizado a originar? Isso \u00e9 suficiente para detectar o sequestro de origem cl\u00e1ssico, e \u00e9 motivo suficiente para implant\u00e1-lo.<\/p>\n\n\n\n

Por\u00e9m, o ROV olha apenas para a origem e n\u00e3o diz nada sobre o restante do AS_PATH. Da\u00ed derivam dois problemas que n\u00e3o consegue deter.<\/p>\n\n\n\n

O primeiro s\u00e3o os vazamentos de rota<\/strong> ou route leaks<\/strong>: a propaga\u00e7\u00e3o de um an\u00fancio al\u00e9m do seu escopo previsto (RFC 7908), tipicamente um AS<\/em> multihomed<\/em> que repassa a um provedor o que aprendeu de outro. A origem \u00e9 leg\u00edtima e o ROA coincide, de modo que para o ROV, o an\u00fancio \u00e9 Valid. O que est\u00e1 errado n\u00e3o \u00e9 a origem, mas sim a forma do caminho<\/p>\n\n\n\n

O segundo \u00e9 o sequestro com origem falsificada<\/strong>. Um atacante n\u00e3o precisa anunciar o prefixo com seu pr\u00f3prio AS: s\u00f3 precisa colocar o AS leg\u00edtimo antes do AS_PATH e anunci\u00e1-lo como se o tivesse aprendido com ele. O an\u00fancio exibe a origem correta, satisfaz o ROA e fica como Valid. O ROV, por constru\u00e7\u00e3o, n\u00e3o consegue distingui-lo de um an\u00fancio genu\u00edno.<\/p>\n\n\n\n

N\u00e3o se trata de uma falha de implementa\u00e7\u00e3o. O ROV valida a origem, n\u00e3o o caminho.<\/p>\n\n\n\n

<\/a>O que o ASPA acrescenta?<\/h2>\n\n\n\n

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\u00e2nsito: o mesmo tipo de afirma\u00e7\u00e3o de um ROA, mas referente a rela\u00e7\u00f5es de peering<\/em> em vez de origem de prefixos.<\/p>\n\n\n\n

Com um conjunto suficiente de ASPA publicados, o operador pode verificar se cada salto do AS_PATH corresponde a uma rela\u00e7\u00e3o cliente-fornecedor efetivamente autorizada. N\u00e3o \u00e9 mais preciso acreditar no caminho: ele \u00e9 confrontado com declara\u00e7\u00f5es assinadas pelos titulares de cada AS.<\/p>\n\n\n\n

A verifica\u00e7\u00e3o se apoia na forma que tem um caminho leg\u00edtimo. Ela sobe por uma cadeia de relacionamentos cliente-fornecedor, cruza opcionalmente um enlace lateral entre pares e desce por outra cadeia. S\u00e3o a rampa ascendente e a rampa descendente.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Estrutura de um AS_PATH leg\u00edtimo. As setas indicam rela\u00e7\u00f5es cliente-fornecedor, e n\u00e3o o sentido de propaga\u00e7\u00e3o do an\u00fancio.<\/em><\/p>\n\n\n\n

O procedimento percorre o caminho recebido e verifica que ele tenha essa forma, usando um crit\u00e9rio que depende de quem enviou a rota: se ela vier de um cliente ou de um peer<\/em>, n\u00e3o deveria haver rampa descendente, e o seu aparecimento \u00e9 justamente a assinatura de um route leak<\/em>. O resultado \u00e9 Valid, Invalid ou Unknown, sendo este \u00faltimo quando as informa\u00e7\u00f5es do ASPA s\u00e3o insuficientes para tomar uma decis\u00e3o.<\/p>\n\n\n\n

\u00c9 importante n\u00e3o misturar vocabul\u00e1rios: onde o ROV diz NotFound, o ASPA diz Unknown. Um an\u00fancio pode ser perfeitamente Valid para o ROV e Invalid para o ASPA, e \u00e9 esse exatamente o caso que o ASPA veio resolver.<\/p>\n\n\n\n

<\/a>Onde o ASPA est\u00e1 hoje<\/h2>\n\n\n\n

\u00c9 importante ser expl\u00edcito, porque h\u00e1 muita confus\u00e3o circulando: O ASPA ainda n\u00e3o \u00e9 um RFC. Os dois documentos principais continuam sendo Internet-Drafts<\/em> no grupo de trabalho SIDROPS do IETF. J\u00e1 existem implementa\u00e7\u00f5es \u2014FORT, Routinator<\/em> e rpki-client<\/em> processam objetos ASPA\u2014 e um n\u00famero crescente de RIR permite public\u00e1-los, mas os detalhes ainda podem mudar, principalmente em rela\u00e7\u00e3o ao algoritmo de valida\u00e7\u00e3o.<\/p>\n\n\n\n

A cobertura ainda \u00e9 logicamente baixa: no in\u00edcio de 2026, os ASPA publicados representavam consideravelmente menos de um por cento do espa\u00e7o global de ASN. Hoje, a enorme maioria dos caminhos resultaria em Unknown. \u00c9 a mesma curva que o ROA percorreu h\u00e1 uma d\u00e9cada.<\/p>\n\n\n\n

No entanto, acredito que o fato de existir um movimento incipiente de cria\u00e7\u00e3o de ASPA, mesmo que o trabalho de padroniza\u00e7\u00e3o no IETF ainda n\u00e3o tenha conclu\u00eddo, demonstra um forte interesse da comunidade de operadores.<\/p>\n\n\n\n

Para um operador que esteja avaliando o que fazer, a ordem de prioridades n\u00e3o mudou: publicar ROA corretos para os prefixos pr\u00f3prios e implantar ROV continuam sendo o primeiro passo. O ASPA se apoia sobre esse trabalho em vez de substitu\u00ed-lo.<\/p>\n\n\n\n

<\/a>Refer\u00eancias:<\/h2>\n\n\n\n