Resumo

  • Uma política BGP pode estar correta antes e depois de uma mudança e, ainda assim, ficar insegura no intervalo. Em interfaces de execução imediata, uma permissão pode entrar em vigor antes de receber suas condições, ou uma regra removida pode continuar ausente se a atualização falhar.
  • A revisão 03 une ordem de regras, custo de processamento, substituição atômica, idempotência e falha do gerador. O recibo útil não é apenas o “commit aceito”, mas a política efetiva e a diferença observada nas rotas durante todo o processo.

Na tela de revisão, a mudança parecia banal: trocar a posição de dois filtros. No roteador, a mesma intenção podia se decompor em apagar uma regra, inserir outra, apagar a segunda e recriar a primeira. Durante um desses intervalos, uma rota bogon encontrava passagem. Se o processo parasse após a remoção, o intervalo virava estado permanente.

O arquivo final continuava impecável.

Essa diferença entre o artefato aprovado e a autoridade em execução é o ponto mais consequente da revisão 03 de Current Options for Securing Global Routing. Publicado em 2 de outubro de 2026, o texto é um Internet-Draft ativo do grupo GROW, no fluxo IETF, com status pretendido Informational e expiração em 5 de abril de 2027. Não é RFC, consenso final, BCP, certificação de produto nem relato de vazamento em uma rede identificada. O próprio rascunho se apresenta como um repositório contemporâneo, não exaustivo e não normativo de opções.

Seu mérito é tornar o tempo parte da análise de segurança.

Construir uma regra pode ativá-la cedo demais

Há plataformas em que um conjunto de comandos fica em uma área candidata até ser validado e aplicado como transação. Em outras, cada comando altera imediatamente a configuração efetiva. As duas podem receber o mesmo resultado desejado, mas não percorrem os mesmos estados.

O rascunho usa um route-map para expor o risco. O operador cria uma regra, configura action permit e só depois adiciona uma large community. Num sistema de execução imediata, a permissão já opera após o segundo passo. Se estiver antes da regra que rejeita rotas aprendidas de upstreams, a entrada incompleta pode aceitar tudo e exportar essas rotas para peers.

Não basta dizer que a ordem dos comandos foi ruim. O problema é que uma representação ainda em construção recebeu autoridade de produção. A revisão prévia inspeciona a intenção; a coleta posterior enxerga o estado convergido. Nenhuma das duas, sozinha, mostra o estado que tomou a decisão no meio da mudança.

A política desejada pertence ao controlador. A política efetiva pertence ao roteador e decide, naquele instante, o que pode ser aceito ou anunciado. Durante uma edição in-place, elas podem divergir. É a segunda que exerce autoridade real.

Reordenar não é um gesto indivisível

O exemplo mais claro contém quatro decisões: rejeitar prefixos recebidos de upstreams, rejeitar bogons, rejeitar NLRI RPKI Invalid e aceitar o restante. O objetivo do operador é apenas inverter as posições das verificações de bogon e RPKI.

Sem atomicidade, isso pode virar quatro operações. Primeiro se apaga a regra antiga de bogon; depois se adiciona a regra de RPKI na posição liberada; em seguida se remove a regra RPKI anterior; por fim se cria a regra de bogon na posição nova. Entre as duas primeiras ações, o bogon pode passar. Uma falha depois da exclusão deixa a abertura em vigor, sem qualquer promessa de que seja breve.

O rascunho alerta que carga e limitação do plano de controle podem alongar o intervalo. Um timeout no sistema de gestão não demonstra rollback no equipamento. Uma nova tentativa pode chegar a um estado parcialmente modificado e repetir apenas parte da intenção.

A mitigação proposta é montar um conjunto novo e completo, mudar a referência do vizinho para ele e remover o antigo somente após a confirmação. Isso reduz muitas edições sensíveis a uma troca de referência.

Ainda assim, é preciso provar o que essa troca significa na plataforma. O modelo candidate/running e o commit do NETCONF ilustram como oferecer staging; não garantem que toda avaliação de rotas mude de forma simultânea em todo produto. A separação entre estado intended e operational no NMDA faz a pergunta correta: o que realmente estava valendo, e em qual momento?

A ordem também consome orçamento operacional

Uma sequência de predicados pode chegar à mesma decisão com custos radicalmente diferentes. A revisão 03 descreve um peer que envia um milhão de NLRI IPv4, dos quais apenas 60 pertencem ao cone autorizado.

Na ordem ineficiente, a política adiciona duas communities, testa AS privados, bogons e invalidez RPKI e só então rejeita o que está fora do cone. O exemplo soma 5.986.500 operações. Colocar a rejeição de alta seletividade do cone primeiro reduz o total para 1.000.300.

Esses números são uma ilustração do rascunho, não medições de um equipamento conhecido. O custo real varia por implementação. A sugestão de considerar operações escalares antes de árvores, listas e expressões regulares também não é uma tabela universal de desempenho.

Mas a relação operacional é importante. Trabalho desperdiçado em rotas que poderiam ser eliminadas cedo ocupa o mesmo plano de controle que precisa concluir a atualização. Vizinhos adicionais multiplicam a entrada. Quanto mais lentamente as regras entram em vigor, mais tempo um estado intermediário perigoso pode permanecer. Ordem de regra é semântica, capacidade e duração de risco ao mesmo tempo.

Idempotência não fecha a janela

Gerar filtros em sistemas dedicados e só aplicar uma política quando seu conteúdo mudou é uma boa disciplina. Evita trabalho repetido no roteador e dá uma base para comparar artefatos.

Porém, idempotência significa que repetições chegam ao mesmo resultado. Não significa que a primeira execução seja indivisível. Um processo pode ser perfeitamente idempotente e atravessar estados inseguros toda vez que há uma mudança real. Também não atesta a correção do conteúdo: uma política errada e estável pode ser ignorada com muita eficiência.

Por isso o registro deve separar evidências. Dados usados pelo gerador, política desejada, configuração gerada para o equipamento, estado efetivo anterior, validação em staging, resposta de ativação, estado efetivo posterior e delta de rotas observado precisam de hashes e horários próprios. Uma única etiqueta “deployed” não explica qual fronteira foi verificada.

O fallback do gerador é uma decisão de roteamento

A geração pode falhar. O rascunho recomenda detectar saídas surpreendentes: um conjunto que cresce ou encolhe abruptamente, ou que chega vazio. Não escolhe um fallback universal, porque cada alternativa gasta uma propriedade diferente.

Aceitar tudo preserva conectividade ao custo da segurança. Rejeitar tudo protege a fronteira, mas pode empurrar tráfego demais para upstreams e agravar a falha. Reutilizar o conjunto anterior conserva estabilidade e acumula desatualização, aceitando ou negando prefixos que já mudaram.

O efeito depende da classe do vizinho. Cliente, peer, upstream e route server não precisam compartilhar a mesma resposta. A organização deve decidir antecipadamente a idade tolerada, o impacto de tráfego, o responsável pela exceção e a evidência necessária para retomar a política gerada.

O default reject do RFC 8212 para eBGP sem política é uma proteção essencial. Ele não demonstra uma transição segura entre duas políticas existentes. RPKI origin validation, BGP Roles e OTC fornecem predicados valiosos; não transformam a instalação desses predicados em transação atômica.