Resumo

  • O RFC 8955 usa BGP para disseminar critérios e ações de tráfego, mas sua validação padrão compara o originador da regra com o da melhor rota unicast correspondente e exige nova validação quando essa rota muda.
  • Susan Hares é coautora do RFC 8955 e editora do RFC 8956 para IPv6. O RFC 9117 foi escrito por outros autores e flexibiliza a validação apenas para controladores e route servers dentro de um domínio local comum.

Um anúncio com efeito imediato

FlowSpec permite combinar prefixos de origem e destino, protocolo, portas, campos ICMP, flags TCP, comprimento, DSCP e fragmentação. Comunidades estendidas carregam as consequências: limitar por bytes ou pacotes, amostrar, interromper a sequência de regras, redirecionar por route target ou remarcar o tráfego. Taxa zero significa descarte.

Em uma mitigação de DDoS, essa linguagem distribui rapidamente uma regra entre routers de borda. Mas a capacidade deixa BGP mais próximo de um plano de ação. Uma rota convencional altera o caminho preferido; uma regra FlowSpec pode remover pacotes legítimos ou colocá-los em outro contexto. Validade sintática não equivale a autorização.

O perfil oficial de Susan Hares no IETF Datatracker registra sua participação no processo de padrões. O recorte documental aqui é preciso. O RFC 8955, Standards Track publicado em dezembro de 2020, lista Christoph Loibl, Susan Hares, Robert Raszuk, Danny McPherson e Martin Bacher, e substitui os RFCs 5575 e 7674. No RFC 8956, extensão para IPv6, Loibl, Raszuk e Hares aparecem como editores.

FlowSpec não é obra de uma única pessoa. Coautoria, revisão do IETF, implementação e operação fazem parte do resultado. A evidência sustenta a contribuição de Hares à revisão normativa; não sustenta autoria exclusiva, implantação universal ou sucesso de qualquer caso real.

A credencial vem da topologia atual

O RFC 8955 define uma ordenação determinística para regras sobrepostas. Uma correspondência sem ação anexada aceita o pacote por padrão. Isso torna o comportamento previsível entre implementações, mas não concede a uma origem o direito de solicitar a ação.

Na validação padrão, o router encontra a melhor rota unicast que cobre o destino. O originador da regra FlowSpec deve coincidir com o originador dessa rota. Se outro AS vizinho anuncia um prefixo mais específico, a regra pode perder a validade. Em EBGP, também se compara o AS mais à esquerda nos dois caminhos.

Não é uma assinatura de boa intenção. É uma delimitação prática. O AS que já é o próximo passo para o destino poderia descartar o tráfego depois que ele chegasse. Permitir que esse mesmo AS peça ao upstream para limitar ou descartar antes pode preservar a capacidade do enlace sob ataque. A autoridade deriva da relação presente com o destino, não do simples fato de existir uma sessão BGP.

Ela também precisa ser revogada quando a relação muda. O RFC 8955 exige revalidar as regras após alterações na rota unicast. Uma nova origem ou um more-specific vindo de outro peer pode retirar o fundamento de um filtro já instalado. Conferir apenas na entrada transforma uma permissão dinâmica em privilégio permanente.

O caso especial do controlador central

Um controlador interno autorizado nem sempre aparece no melhor forwarding path. Ele foi colocado no domínio para programar políticas, não para encaminhar cada pacote. Aplicar literalmente o teste de origem pode rejeitar uma regra legítima desse controlador.

O RFC 9117, de agosto de 2021, atualiza o procedimento. Seus autores são Jeffrey Uttaro, Jorge Alcaide, Clarence Filsfils, David Smith e Pradosh Mohapatra; Susan Hares não o escreveu. O documento interessa como evolução posterior da fronteira criada pelo RFC 8955.

A flexibilização permanece no mesmo domínio administrativo local. O operador pode declarar confiança em seu controlador sem exigir que ele origine a rota unicast. O RFC 9117 também ajusta a leitura de AS_PATH em ambientes com route server. Não concede a um controlador remoto direito geral de filtrar entre domínios e não substitui a política do receptor.

Autorizar um controlador próprio a programar uma rede própria é governança interna. Aceitar uma ação solicitada por outra organização é coordenação interdomínio. A arquitetura pode usar a mesma família de mensagens, mas a cadeia de autoridade não é a mesma.

Aceitar no BGP não é instalar corretamente

O RFC 8955 alerta para filtragem, marcação e redirecionamento indesejados quando a validação é relaxada. Ações podem trocar filas, caminhos ou contextos VPN. Um controlador comprometido ou defeituoso pode enviar updates demais, esgotar a capacidade da plataforma ou criar uma regra ampla demais.

A rede pode restringir por vizinho o conjunto de ações, os prefixos e portas, as taxas, os alvos de redirecionamento e a quantidade de regras. Depois precisa provar a execução. Uma entrada aceita no control plane pode não chegar à ACL, FIB ou ASIC. Uma entrada instalada pode atingir serviços que a expressão aparentemente não pretendia alcançar.

Um RFC publicado também não prova suporte de fornecedor, configuração ativa, equivalência entre devices ou eficácia de mitigação. O padrão oferece semântica compartilhada e uma defesa padrão. O comportamento real pertence à evidência de produção.

Um núcleo comum e decisões futuras locais

O ensaio de Lu Heng Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption ajuda a separar os papéis. O núcleo compartilhado pode conter componentes de match, codificação de ações, ordenação e validação associada ao unicast. Cada rede decide quais peers e controladores aceita, quais ações permite, seus limites, registros e processo de retirada.

Uma sintaxe comum não deve virar comando central. Interpretações incompatíveis também inviabilizam a coordenação. O equilíbrio está em uma gramática estreita com consequências autorizadas localmente.

Pelo critério de Running-Code Primacy, a tabela BGP é só o começo. É preciso conferir estado de validação, ordem, instalação em hardware, contadores, efeito sobre serviços, retirada e recuperação. A mudança da rota unicast deve ser testada para confirmar a perda ou transferência de autoridade. Esses dois ensaios posteriores são uma lente de Sofia Ren, não posições atribuídas a Hares ou aos autores dos RFCs.

Uma regra confiável deixa três respostas verificáveis: quem a originou, qual fato de routing atual lhe dá legitimidade e qual política local autorizou a ação. A contribuição documentada de Hares ilumina uma ideia essencial: quanto maior a consequência do filtro, mais explícita deve ser sua base revogável.

Fontes