Resumo

  • A versão 03 do Internet-Draft Current Options for Securing Global Routing, do grupo GROW e datada de 2 de outubro, acrescenta uma seção sobre a forma de aplicar configurações. Ela diferencia a confirmação atômica de uma transação da execução imediata de cada comando. O documento ainda não é um RFC aprovado.
  • No exemplo, action permit passa a funcionar antes de set large-community add 65536:0:0. Se a nova regra ficar antes daquela que recusa rotas aprendidas de um provedor upstream, anúncios indevidos podem sair para pares nesse meio-tempo. O texto apresenta uma possibilidade, não relata um vazamento observado.

Em muitas revisões de mudança, o operador compara o estado anterior com o posterior. O que acontece entre eles recebe menos atenção. draft-ietf-grow-routing-ops-sec-inform-03 põe justamente essa sequência em primeiro plano. Segundo o Datatracker, trata-se de um Internet-Draft ativo do grupo de trabalho GROW, com estado IESG I-D Exists e intenção de publicação Informational. A própria apresentação limita seu objetivo: compilar opções não exaustivas, sem julgar a eficácia individual de cada técnica nem prescrever uma implementação.

A nova seção “Impact of the Configuration Paradigm” separa duas formas de chegar ao mesmo texto final. Em uma interface transacional, alterações são preparadas e confirmadas em conjunto. Em outra, cada linha atua imediatamente. A route-map do exemplo recebe primeiro action permit; a instrução para adicionar a Large Community 65536:0:0 vem depois. Se a regra nova aparecer antes de uma regra que rejeita rotas recebidas de redes upstream, o primeiro comando pode autorizar exportações para pares. A comunidade numérica não é prova de autorização ou de retenção das rotas: ela compõe a sequência ilustrativa.

Não se deve confundir a novidade da seção com a descoberta do risco. A versão 02 já alertava, ao tratar da consistência de filtros de prefixos, que edições não atômicas poderiam deixar passar prefixos indesejados por um período ou produzir uma política inconsistente se interrompidas. A versão 03 amplia essa advertência para a semântica de aplicação da configuração e inclui um exemplo de ordem dos comandos numa route-map. Não oferece prova de um incidente nem uma receita validada para todos os roteadores.

RFC 8212 estabelece rejeição por padrão quando uma sessão EBGP carece de política explícita de importação ou exportação. A ressalva do próprio RFC é decisiva: essa exigência não impede uma configuração explícita incorreta. Um permit provisório é uma configuração explícita. Portanto, a existência de uma política final restritiva ou de uma regra geral de rejeição na ausência de política não comprova o que foi anunciado enquanto uma política existente era editada.

Há três momentos distintos a registrar. O equipamento aceitou o comando; a política completa pretendida foi instalada; o vizinho recebeu apenas rotas autorizadas. O diff final é evidência sobretudo do segundo momento. Construir uma política completa separadamente e só então trocar sua referência pode ser uma opção, desde que a plataforma suporte esse método e que a troca seja testada. Uma única linha de referência não equivale, por definição, a uma operação atômica. Os testes e recibos sugeridos aqui são inferências de operação, não uma obrigação de telemetria criada pelo GROW.

As fontes não identificam operadora afetada, falha de produto nem proporção de redes expostas. O ganho editorial do rascunho é outro: torna insuficiente aprovar apenas o destino da mudança. Cada estado intermediário capaz de produzir um anúncio é parte do poder de exportação que a organização decidiu conceder.

Fontes