Resumo

  • Em 22 de junho de 2026, o IESG aprovou como Best Current Practice a orientação de que estados de validação derivados de RPKI não devem ser sinalizados em atributos BGP transportados por EBGP entre administrações. A revisão 12 está na fila do RFC Editor.
  • O estado nasce de dados, tempo e política locais. Levá-lo em atributo não assinado não transporta a prova, mas faz mudanças de ROA, cache ou RTR alterarem rotas externas e consumirem recursos de vizinhos sem ganho verificável.

O relógio do vizinho cria a segunda onda

O documento aprovado monta um cenário com AS65536 como cliente do AS65537. Os dois consultam um serviço RTR central a cada 300 segundos e os dois acrescentam Communities às rotas conforme o estado de validação. É uma ilustração técnica, não um incidente real relatado.

O AS65536 atualiza sua visão um segundo antes de o serviço cair. O AS65537 deveria atualizá-la um segundo depois. O provedor perde primeiro os payloads validados, muda várias rotas de Valid para NotFound e, como as Communities também mudam, envia UPDATE para seu cone de clientes. O AS65536 processa e repassa esse movimento.

Cerca de 300 segundos mais tarde, expira a visão do próprio AS65536. Suas Communities mudam e surge uma segunda onda causada pela mesma falha. Um cache mais longo apenas adia a sequência; se a interrupção superar o TTL, não elimina as duas etapas.

Nada exige que o prefixo, o Origin AS ou a alcançabilidade tenham mudado. A pane está no fornecimento de evidência RPKI. Ao incorporar o resultado local à identidade externa da rota, o operador transfere o impacto para o plano de controle BGP.

Valid é uma conclusão comprimida

RFC 6811 define NotFound, Valid e Invalid a partir da comparação entre a rota recebida e os Validated ROA Payloads armazenados localmente. O próprio RFC orienta a tratar esse resultado como propriedade local da rota.

A conclusão depende de quais objetos assinados foram obtidos, quais passaram pela validação, quando o cache foi atualizado, se a sessão RPKI-to-Router está íntegra e como a política local usa o resultado. Dois domínios podem ter visões distintas por algum tempo sem que uma delas seja fraudulenta.

A Community leva o rótulo, não o conjunto de VRPs, o horário, o trust anchor, a saúde do cache ou a regra decisória. O receptor não consegue reproduzir a conclusão apenas com o atributo.

Além disso, atributos comuns de BGP enviados por EBGP não são assinados. Um terceiro pode acrescentar ou alterar o estado alegado. Receber Valid com a rota não comprova quem fez a validação nem se a visão ainda corresponde ao presente do receptor.

O compartilhamento previsto era interno

RFC 8097 criou uma Extended Community não transitiva para distribuir o Origin Validation State dentro de um AS. Falantes IBGP sob a mesma confiança poderiam reutilizar o cálculo. Por padrão, a implementação deve descartar a Community quando a recebe de um peer EBGP e não deveria enviá-la a peers EBGP.

O RFC admite configuração quando dois AS adjacentes pertencem à mesma administração. A fronteira relevante é onde permanecem evidência, controle e responsabilidade, não apenas o número do AS.

A nova orientação generaliza a regra para Communities comuns, estendidas, grandes, valores específicos de operador e futuros atributos que provoquem UPDATE ao mudar. Ela também alcança resultados locais derivados de ASPA ou BGPsec quando alguém tenta exportá-los da mesma forma.

Uma plataforma pode depender do atributo internamente. Nesse caso, o operador deve removê-lo antes de anunciar NLRI a outro domínio administrativo. Conveniência interna não cria autoridade do lado de fora.

A escala transforma detalhe em carga sistêmica

O texto cita uma medição do RIS feita em fevereiro de 2024: de 8% a 10% dos BGP UPDATE observados continham Communities públicas associadas a NotFound ou Valid. A criação ou remoção de um objeto ROA também gerou uma cadeia de atualizações por cerca de uma hora. É uma fotografia temporal.

Para meados de 2026, o documento usa uma tabela IPv4 e IPv6 de aproximadamente 1,3 milhão de prefixos, com cerca de 65% cobertos por ROAs. Uma falha de cache poderia exigir o reenvio de mais de 850 mil rotas quando os estados são carregados externamente.

Revalidar localmente é correto. O desperdício aparece quando a mudança de evidência altera um atributo externo e obriga vizinhos a receber, armazenar e processar novamente rotas cuja alcançabilidade continua igual. Ciclos desencontrados ainda espalham a carga no tempo.

Há também uma alavanca ofensiva. Quem pode emitir e retirar objetos assinados para seus próprios prefixos pode alternar estados. Quem readvertise NLRI pode modificar atributos não assinados. Transformar o estado em identidade externa converte esses atos em churn.

O efeito da política já está na rota exportada

Se uma rede valida RPKI e rejeita Invalid, tais rotas não deveriam ser repassadas aos clientes. O conjunto anunciado já revela o efeito da política. A Community adicional não entrega ao vizinho uma justificativa autenticada.

Quem recebe e precisa de segurança deve validar com sua própria visão atual. Assim preserva a ligação entre prova, tempo e decisão. Usar o resultado alheio como comando confunde cooperação com delegação: uma rede pode descrever sua prática, mas não decide pela próxima.

A disciplina operacional é direta: obter e validar RPKI localmente, aplicar política local, conter atributos de estado na mesma administração e removê-los em todas as bordas externas. Exportar a rota aprovada; manter dentro de casa a explicação não assinada.

Fontes