Resumo

  • O IESG abriu em 17 de setembro de 2026 a Last Call da revisão 21 do diagnóstico interdomínios do SAVNET, com comentários até 1º de outubro. Trata-se de um Internet-Draft destinado a publicação informativa, não de um RFC aprovado.
  • A proposta examina bloqueio indevido de pacotes legítimos e permissão indevida de endereços falsificados. A seção 6 reconhece que o roteador de borda não consegue perceber todas as falhas de sua própria tabela SAV.
  • Uma reclamação de rede cliente ou par pode revelar o problema. Um registro ligando o relato à decisão e à correção é recomendação desta análise, não um procedimento já padronizado.

Quando uma política de validação de endereço de origem descarta um pacote, o equipamento sabe qual regra aplicou. Isso não significa que saiba se a regra tinha todos os fatos necessários. O documento do grupo SAVNET, agora em consulta final no IESG, separa essas duas perguntas. Uma se refere à execução local da tabela; a outra, à legitimidade de tráfego que atravessa relações entre sistemas autônomos. Confundir as duas transforma um controle de segurança em uma resposta aparentemente conclusiva para um problema que pode estar fora do campo de visão do roteador.

O próprio diagnóstico explica como a informação pode faltar. Um prefixo legítimo pode ser anunciado seletivamente a algumas redes. Outros prefixos podem servir como origem, inclusive em arranjos de anycast com retorno direto, sem aparecer nas rotas BGP visíveis ao filtro da forma esperada. Ausência de anúncio naquele ponto não é prova de falsificação. Montar uma tabela restritiva com base nessa visão parcial pode produzir bloqueio indevido. O movimento oposto também tem preço: afrouxar as direções aceitas para impedir falsos bloqueios pode permitir mais endereços de origem forjados.

Mesmo a adoção parcial exige cautela na promessa. A filtragem de um operador não elimina toda falsificação que pode ocorrer dentro do conjunto de redes clientes se as demais partes não têm proteção equivalente. Por isso, o texto pede a futuros métodos mais precisão nos dois sentidos, atualizações menos manuais da tabela, benefício para quem adota cedo, convergência eficiente e proteção de informações específicas de SAV eventualmente utilizadas. Não apresenta esses resultados como já medidos em produção.

Na seção sobre solução de problemas, a diferença entre decisão e conhecimento fica explícita. O roteador de borda de um AS não detecta por si só todos os seus bloqueios incorretos ou permissões incorretas. A informação pode vir de quem teve o tráfego afetado a jusante ou em uma conexão de paridade. A queixa não demonstra automaticamente que a filtragem errou. Também não basta responder que a máquina obedeceu à tabela. É necessário recuperar a interface, a relação com o vizinho, a versão da tabela e os insumos usados na decisão naquele instante.

Uma disciplina operacional possível seria abrir um registro com hora do relato, prefixo e classe de tráfego alegados, interface de entrada, versão da tabela e dos dados de origem, pessoa responsável pela análise, justificativa para alterar ou manter a regra e teste de encerramento. Daniel Kade propõe esse encadeamento como mecanismo de responsabilização, não como mensagem obrigatória criada pelo IETF. O compartilhamento de pacotes e detalhes comerciais deve ser limitado; uma investigação não precisa transformar a topologia de clientes em informação pública.

A revisão 21 é datada de 19 de julho. O acontecimento de setembro é a abertura da Last Call em 17 de setembro, até 1º de outubro. O material ainda descreve lacunas e requisitos, não um protocolo operacional pronto, uma implantação comprovada ou um incidente real. A questão imediata é quem recebe o sinal que vem de fora e tem autoridade para reconciliá-lo com a regra local. Se esse caminho não existe, o filtro pode repetir com eficiência um julgamento errado sem nunca reconhecer o erro.

Fontes