Resumo

  • FlowSpec distribui critérios de pacotes e ações; ver a rota comprova um estado do plano de controle, não um resultado de encaminhamento.
  • Regras externas normalmente dependem de validação contra rotas unicast e precisam ser revalidadas quando a melhor rota muda.
  • Regras e ações podem se sobrepor ou entrar em conflito; limites de análise IPv6 e de hardware podem impedir a aplicação.
  • O fechamento exige ligar o NLRI exato à programação, aos contadores, às amostras de pacotes e ao efeito sobre tráfego atacado e legítimo.

Imagine um controlador contra DDoS originando uma regra para um destino e uma porta. Ela surge no refletor e no plano de controle de três roteadores de borda; o painel do incidente fica verde. Mesmo assim, um enlace de entrada continua transportando o fluxo porque sua placa não conseguiu compilar o critério de camada superior. A observação BGP era verdadeira. A conclusão sobre o filtro não era.

Este é um cenário hipotético, sem atribuição a operador ou fabricante. A distinção é entre entregar uma instrução e executá-la sobre pacotes.

O que a rota realmente transporta

A RFC 8955 codifica uma Flow Specification como uma n-tupla em NLRI do BGP. Os componentes podem representar prefixos de origem e destino, protocolo, portas, flags TCP, tamanho, DSCP e fragmentos. Um pacote corresponde apenas quando satisfaz a interseção de todos os componentes. O primeiro registro deve guardar a expressão decodificada, não só o rótulo exibido no painel.

Comunidades estendidas carregam limite em bytes ou pacotes, amostragem, redirecionamento por route target e marcação. A ação padrão para uma regra correspondente é aceitar segundo o encaminhamento normal. Taxa zero representa descarte. Uma regra recebida sem a ação esperada pode existir sem bloquear.

Mais de uma regra pode corresponder ao mesmo fluxo. A ordem é independente da chegada pelo BGP, mas as ações ainda podem se contradizer. Se o conflito chegar à seleção de encaminhamento, a implementação decide o que aplicar. A distribuição pode ser uniforme e o comportamento local, diferente.

A validação muda com o unicast

Sem configuração explícita em contrário, uma regra externa deve conter prefixo de destino, ter o mesmo originador da melhor rota unicast que cobre o prefixo e não abranger uma rota mais específica recebida de outro AS vizinho. A primeira condição pode ser relaxada; a política de validação, portanto, faz parte da prova.

A melhor rota unicast pode mudar sem nova regra. A RFC 8955 exige revalidação. Uma regra viável antes da mudança pode deixar de sê-lo mesmo continuando visível no coletor. O registro precisa dizer onde a validação ocorreu e qual estado unicast a sustentou.

A RFC 8956 estende o mecanismo ao IPv6 com AFI 2 e SAFI 133 ou 134. A validação exige offset zero no prefixo de destino. Cadeias de cabeçalhos anômalas e limites de hardware também podem impedir critérios de camada superior. Aceitação no controle não remove essa fronteira.

O resultado precisa de pacotes

A RFC 8955 recomenda registro de cabeçalhos e contadores de correspondência por regra. Para cada equipamento, VRF, interface e placa, registre se a regra foi compilada, rejeitada ou aproximada, qual prioridade e ação permaneceram e como os contadores se relacionam com amostras do ataque.

Meça separadamente o tráfego que alcança a vítima, a perda legítima, a capacidade do redirecionamento e o efeito da retirada. Um contador de descarte pode crescer sobre o agregado errado; uma queda do ataque pode ocultar dano colateral. A rota FlowSpec não resolve essa diferença.

Fontes