Resumo

  • A revisão 01 propõe DOWNGRADE como comunidade BGP conhecida e transitiva: durante congestionamento, o tráfego para o prefixo marcado deve receber menor precedência e ser descartado antes dos demais.
  • O atributo de rota não prova aceitação, classificador instalado, fila Lower-Effort, preservação de DSCP, congestionamento real nem chegada de amostras úteis à vítima.
  • A estratégia depende de capacidade ociosa, participação de cada domínio, autorização do prefixo e retirada verificável; sem isso, pode virar um blackhole suave com plano de controle aparentemente saudável.

Um anúncio de blackhole toma uma decisão definitiva no lugar da rede atacada. Descarta o tráfego para salvar capacidade compartilhada. A vítima perde disponibilidade e, muitas vezes, perde também a visão necessária para saber quando o ataque acabou.

DOWNGRADE propõe uma troca diferente. O tráfego do prefixo continua elegível para encaminhamento, mas entra numa classe que deve perder primeiro sob congestionamento. Havendo espaço, pacotes passam. Esse fluxo residual pode manter uma função crítica e fornecer dados sobre a continuidade do ataque. A comunidade, porém, não contém a fila. Ela apenas pede que outra rede crie esse comportamento.

A revisão 01, de 24 de setembro de 2026, é trabalho do grupo GROW. O Datatracker a apresenta como Internet-Draft ativo, e o anúncio oficial registra sua publicação. O cabeçalho aponta para um documento Informational. Ainda não é RFC, teste de interoperabilidade ou levantamento de adoção.

O vocabulário compartilhado já recebeu número. Depois da solicitação dos autores, o registro da IANA atribuiu 0xFFFF000A a DOWNGRADE. Isso resolve qual valor reconhecer, não o que um equipamento efetivamente fará. A própria revisão 01 mostra a fronteira: sua seção IANA traz o valor, enquanto exemplos de fornecedores ainda exibem TBD. São ilustrações, não configuração pronta.

O RFC 1997 torna Communities um atributo opcional e transitivo. Um speaker pode usá-lo para aceitar, preferir e distribuir rotas, além de modificá-lo conforme política local. O emissor não controla uma fila remota. O receptor verifica se o vizinho está autorizado a anunciar o prefixo, decide se conserva a marca e determina como ela entra no encaminhamento.

O rascunho pede que a política associe a rota a uma classe inferior. Na presença de congestionamento, os pacotes para o destino marcado devem ser descartados antes dos outros. Ao sair para outro domínio, deveriam carregar o DSCP Lower-Effort 000001 do RFC 8622. Route servers de IX deveriam retransmitir a comunidade, e outros operadores não deveriam removê-la, pois agir perto da origem protege capacidade mais cedo.

Um route server continua no plano de controle. O RFC 7947 não o coloca no caminho dos pacotes. Ele pode preservar a comunidade com perfeição e jamais tocar no tráfego. Seu registro prova uma etapa de propagação, não a execução.

Lower-Effort também não oferece taxa mínima. O RFC 8622 admite rendimento muito baixo e até inanição completa. Se um domínio não possui fila LE, deve mapear o tráfego para o comportamento padrão e preservar o DSCP. Nesse ponto os pacotes recebem tratamento melhor que o solicitado e podem disputar recursos com Best Effort. Se a marca for apagada, o próximo domínio perde o sinal. Se tráfego legítimo for marcado por engano ou abuso, a ferramenta produz um ataque de degradação.

Visibilidade é outro resultado a comprovar. Pacotes que escaparam de uma fila podem morrer num gargalo posterior ou não alcançar o sensor da vítima. Uma série zerada pode indicar fim do ataque, inanição a montante, blackhole intermediário ou falha de telemetria. Uma amostra pequena talvez não revele composição do ataque nem recuperação da aplicação.

O rascunho declara sua condição física: precisa existir alguma capacidade não utilizada durante o ataque. Prioridade distribui escassez, não cria largura de banda. Se o gargalo estiver antes da classificação ou o tráfego superior consumir toda a sobra, o agregado DOWNGRADE desaparece. A causa do ataque permanece.

Por isso a proposta não repete o BLACKHOLE do RFC 7999 nem o RTBH do RFC 5635. BLACKHOLE pede descarte total e contenção de propagação. DOWNGRADE procura alcance amplo do sinal e chance não nula de entrega. Ambos exigem autoridade sobre o prefixo e política local, mas os recibos de resultado são diferentes.

A trilha operacional começa com prefixo, responsável, início, duração máxima e speaker autorizado. Depois identifica vizinhos que aceitaram, route servers que conservaram e políticas que mapearam a comunidade. Em seguida separa FIB e classificador, fila e escalonador, DSCP nas fronteiras, congestionamento e descartes, amostras, chegada à vítima e canários. O último recibo mostra retirada da marca e restauração da entrega comum.

A primazia do código em execução de Heng Lu coloca o destino do pacote acima da etiqueta. As camadas da realidade impedem que rota, fila e resultado de serviço sejam tratados como um fato único. A especificação inicial mínima deixa a camada comum nomear a intenção, mantendo a execução sob responsabilidade de cada rede.

DOWNGRADE oferece uma terceira opção entre encaminhar normalmente e desaparecer. Essa opção só é real quando o estado intermediário pode ser provado. A rota leva o pedido; a fila decide a sobrevivência.

Fontes