Resumo

  • O guia vigente da RIPE NCC exige todos os provedores upstream, vizinhos multirrole quando atuam como provedor e route servers não transparentes no ASPA, mas diz que o painel RPKI não dá nenhuma orientação sobre os provedores vistos no BGP.
  • O Plano de Atividades de 2026 prevê sugestões baseadas em quem a RIPE NCC acredita ser upstream. A formulação reconhece uma inferência e não cria prazo de entrega nem prova contratual.
  • Cada candidato deveria vir com fonte, pontos de observação, janela de tempo, família de endereços, posição no caminho, motivo e incerteza. O operador classifica; o ASPA publicado continua sendo a autorização.

A parte mais consequente de um ASPA acontece antes da assinatura: alguém decide quais números entram na lista.

Na RIPE NCC, o titular de um Sistema Autônomo já consegue criar um Autonomous System Provider Authorization. O objeto assinado declara quais ASes estão autorizados a agir como provedores de trânsito do Customer AS. A criptografia permite verificar a origem e a integridade da declaração. Ela não verifica se a equipe lembrou de todos os contratos, classificou corretamente cada sessão ou entendeu o comportamento de um route server.

O guia público é rigoroso. O operador deve incluir todos os seus provedores upstream e manter o objeto sincronizado com mudanças nessa composição. Um vizinho com relação complexa deve constar quando uma de suas funções for a de provedor. Um route server não transparente em um ponto de troca também aparece no caminho em papel de provedor e precisa ser incluído. Pares laterais e clientes não entram.

O risco da omissão é explícito: rotas enviadas por um provedor não listado podem ser rejeitadas. Em seguida vem a frase que define o limite atual do produto. O painel RPKI da RIPE NCC não oferece pistas nem orientação sobre quais provedores são vistos para o AS no BGP; o próprio operador precisa garantir isso.

Há, portanto, uma assimetria. O serviço entrega a capacidade de assinar e publicar, mas não coloca diante do signatário o inventário de evidências de roteamento que poderia revelar uma ausência. Preencher o campo é fácil. Saber se uma adjacência observada é uma relação autorizável é o trabalho real.

A lista pode errar para os dois lados

O perfil ASPA do IETF capturado nesta apuração estava na revisão 29 e seguia como Internet-Draft. Ele determina que um Customer AS com vários provedores liste todos, inclusive ASes de route servers não transparentes, e recomenda um único objeto com o conjunto completo.

O rascunho de verificação, na revisão 28, descreve consequências opostas. Incluir um provedor por engano reduz a capacidade de detectar vazamentos de rota. Omitir um provedor pode fazer rotas legítimas parecerem ASPA Invalid no futuro. Os documentos ainda podem mudar antes de se tornarem RFCs, mas a tensão operacional já é inequívoca.

Uma ferramenta otimizada apenas para preencher lacunas pode autorizar demais. Outra, limitada ao que apareceu com frequência em uma janela curta, pode esquecer o trânsito de contingência. No primeiro caso, a proteção fica mais permissiva. No segundo, uma rota necessária pode enfrentar uma falsa invalidez quando finalmente aparecer.

O principal upstream costuma estar na memória da equipe. Os casos difíceis são discretos: backup frio, trânsito regional, provedor apenas de IPv6, sessão herdada de uma aquisição, contraparte que exerce papéis diferentes, route server cuja transparência depende da configuração. Justamente essas relações são sub-representadas numa fotografia curta e fáceis de esquecer numa revisão manual.

O AS_PATH não conhece o acordo comercial

Toda observação BGP pertence a um lugar e a um instante. Um coletor público recebe o que seus participantes escolheram exportar, depois de várias políticas já terem atuado. Um ponto pode ver uma adjacência que outro jamais recebe. IPv4 e IPv6 podem seguir caminhos distintos. Uma manutenção curta pode ativar um provedor que permaneceu invisível por meses.

Nem toda sequência observada é legítima. Vazamento, erro de configuração ou estado transitório pode aproximar dois ASes sem que exista relação autorizada entre eles. Frequência mede persistência do sinal, não consentimento. O AS_PATH não transporta contrato, fatura, direção do pagamento nem intenção das partes.

O BMP do próprio operador oferece uma visão mais rica porque pode registrar, antes da política local, o que cada roteador recebeu de cada vizinho. Ele ajuda a localizar backups e diferenças entre famílias. Ainda assim, telemetria descreve comportamento de roteamento; não decide se alguém é provedor, par, cliente ou mais de uma coisa ao mesmo tempo.

A separação correta tem quatro níveis. Coletores e telemetria produzem observações. Contratos, inventário de sessões e desenho da rede classificam relações. O titular do AS autoriza. A RIPE NCC publica o objeto, que validadores e roteadores usarão segundo padrões em evolução e política local.

Quando o painel mistura esses níveis, uma sugestão toma emprestada a autoridade do registro. Quando os mantém separados, a sugestão vira uma pergunta que deixa rastro.

O plano de 2026 já usa o tom adequado

O Plano de Atividades e Orçamento de 2026 da RIPE NCC promete melhorar a informação BGP utilizada na gestão de ROAs e ASPAs. Para ROAs, fala em aproximar-se de dados em tempo real. Para ASPA, descreve sugestões semelhantes com base em quem a organização acredita serem os upstreams.

“Acredita” é uma escolha importante. O texto não afirma que a RIPE NCC sabe quem ocupa o papel comercial nem que a observação pode ser assinada sem revisão. Ele abre espaço para uma interface de evidência, não para um cadastro paralelo de relações privadas.

O plano não informa uma data de entrega dessa função. A página trimestral de RPKI capturada para o terceiro trimestre de 2026, atualizada em 11 de junho, lista quatro frentes: revogação automática de autoridades certificadoras delegadas persistentemente inoperantes, substituição das chaves de API por OpenID Connect, trabalho de conformidade e possível suporte por API a Resource Signed Checklists. As sugestões de upstream para ASPA não aparecem nessa relação.

Isso prova somente a ausência entre os quatro itens publicados para o trimestre. Não prova atraso, cancelamento ou abandono. Criar um prazo que o plano anual não fixou tornaria uma verificação legítima em acusação sem base.

O Relatório Anual de 2025 registra uma data concreta: o suporte a ASPA no painel RPKI foi lançado em 26 de novembro de 2025. A capacidade de publicar veio antes do auxílio probatório previsto no plano seguinte. Como lançamento conservador, a ordem faz sentido. Para os primeiros usuários, deixa toda a conciliação dentro de casa.

O melhor argumento a favor da tela em branco

Não sugerir pode ser uma forma de contenção institucional. A RIPE NCC não vê todos os contratos de trânsito, enlaces privados, esquemas de contingência ou configurações de route server. O mesmo ASN pode ser provedor em uma sessão, par em outra e contraparte de outro produto numa terceira. Chamar tudo isso de “seu upstream” a partir do caminho seria extrapolar o dado.

O lugar onde a sugestão aparece agrava o problema. Uma lista pré-preenchida ao lado do botão de assinatura parece ter passado por validação do registro. O usuário pode aceitá-la em massa por deferência ao sistema. Um campo vazio acompanhado de um alerta honesto é mais seguro do que uma recomendação inexplicável.

Contenção, porém, não exige cegueira. O painel pode mostrar o que observou, declarar o que não sabe e pedir a classificação do operador.

Um comprovante para cada candidato

Uma sequência nua de “provedores prováveis” não basta. Cada ASN candidato precisa de uma ficha curta de evidência.

Ela deve começar pela proveniência: RIS, outro coletor público ou telemetria cedida pelo operador; conjunto de pontos de observação; momento do retrato e intervalo analisado. Precisa indicar IPv4 ou IPv6, posição no caminho, primeira e última ocorrência, número de aparições e distribuição entre perspectivas.

Depois vêm as exceções. O candidato aparece continuamente ou só em falha e manutenção? Está limitado a uma região ou família? Há indício de route server e ele parece transparente ou não transparente? O ASN aparece repetidamente fora do ASPA existente, ou permanece no objeto apesar de não ser observado há muito tempo?

O limite deve ficar visível. Adjacência observada não prova contrato, papel de provedor, autorização ou completude. Uma nota de confiança deve medir a robustez da observação, não a verdade da relação comercial. A versão da regra ou do modelo que produziu o candidato também pertence ao registro.

O operador precisa poder aceitar como provedor, rejeitar como par ou cliente, marcar uma relação multirrole, identificar arranjo temporário ou de backup e adiar para conferência. Uma referência interna pode apontar para a sessão ou o contrato sem publicar material confidencial no RPKI.

Na assinatura, o serviço guardaria a proposta inicial, cada decisão, a diferença entre o conjunto anterior e o novo, o usuário responsável, a hora e o hash do objeto. A próxima correção se ligaria à versão anterior. O histórico mostraria se uma exclusão foi deliberada, provisória ou esquecida.

O ASPA público continua sendo a autorização. O comprovante documenta como uma evidência imperfeita chegou — ou não chegou — até ela.

Ver o efeito depois é outra tarefa

Uma contribuição comunitária publicada no RIPE Labs em 29 de junho de 2026 aborda a falta de visibilidade após a criação do objeto. Seus autores apresentam o RAVEN, que combina telemetria BMP com dados RPKI fornecidos por RTR v2 para anotar rotas e explorar cenários hipotéticos.

O texto é identificado como contribuição da comunidade, não como compromisso de produto da RIPE NCC. Mesmo assim, ajuda a separar dois controles. Antes de assinar, pergunta-se se o conjunto representa as relações pretendidas. Depois, pergunta-se como esse conjunto classificaria as rotas de fato recebidas.

Uma simulação pode mostrar que um caminho seria Invalid, mas não decide se o defeito está no ASPA, na rota ou na cobertura da observação. Ela revela consequência; não comprova a relação. O fluxo maduro reúne inventário, observação e teste de impacto sem permitir que um substitua o outro.

O esquecimento fica adormecido até a contingência

Um upstream principal ausente tende a ser notado cedo. Um backup pode permanecer invisível por meses. O objeto é publicado e nada falha de imediato. Depois, uma fibra rompe, uma manutenção desloca o tráfego ou um route server muda de comportamento. A relação rara passa a ser a relação necessária.

As fontes examinadas não demonstram que isso ocorreu com um membro específico da RIPE NCC nem que uma rota foi rejeitada por causa de um ASPA existente. A especificação está em desenvolvimento, e a aplicação depende de software e política local. Trata-se de um mecanismo de risco, não da atribuição de um incidente.

Levar a conciliação para antes da assinatura reduz esse risco. Uma sugestão datada chama atenção para o provedor silencioso. O registro da decisão explica por que ele entrou ou ficou de fora. Em nenhum momento o sistema precisa fingir que “visto no BGP” significa “autorizado como provedor”.

A RIPE NCC pode concluir a ponte esboçada em seu plano sem aumentar o próprio poder. Mostrar quem apareceu, de onde veio a observação, quando ocorreu e o que permanece desconhecido; exigir classificação; conservar a diferença assinada. O registro enxerga caminhos. O operador conhece o arranjo. Um ASPA confiável preserva a distância entre ambos.

Fontes