Retirada BGP de BYOIP da Cloudflare: Falha do Plano de Controle de Endereçamento

Visão Geral do Incidente

Tier A (confirmado): A Cloudflare declara que em 20 de fevereiro de 2026 às 17:48 UTC sofreu uma indisponibilidade que afetou um subconjunto de clientes Bring Your Own IP (BYOIP) depois que rotas de clientes foram retiradas via Border Gateway Protocol (BGP). A Cloudflare declara que o evento não foi causado por ciberataque e decorreu de uma mudança interna em como sua rede gerencia endereços BYOIP.

Tier A (confirmado): A Cloudflare informa duração total de 6 horas e 7 minutos. O impacto começou às 17:56 UTC, o subprocesso defeituoso foi encerrado às 18:46 UTC, a orientação de autorremediação para clientes foi publicada às 19:19 UTC, e a restauração final de configuração de prefixos terminou às 23:03 UTC.

Tier A (confirmado): A Cloudflare informa que aproximadamente 1.100 prefixos foram retirados antes da interrupção da mudança. Também informa que 4.306 prefixos BYOIP eram anunciados globalmente ao peer referenciado e que 25% dos prefixos BYOIP foram retirados involuntariamente durante o incidente.

Tier A (confirmado): A Cloudflare identifica o defeito imediato de software como um subprocesso de cleanup chamando /v1/prefixes?pending_delete enquanto a implementação da API testava Query().Get("pending_delete") != "". Uma flag sem valor avaliou como string vazia, impedindo a execução do caminho de pending deletion e causando retorno de um conjunto amplo de prefixos.

Tier B (inferido): A falha arquitetural dominante não foi o BGP em si. O BGP propagou um erro de plano de controle originado em mutação de estado autoritativo de endereços, semântica fraca de schema de API, separação insuficiente entre estado configurado e estado operacional, e circuit breakers inadequados para retirada de prefixos em alta cardinalidade.

Tier C (desconhecido): A evidência pública não expõe a topologia interna completa de deployment, o schema exato do banco de dados, a distribuição de bindings por cliente, nem o conjunto completo de sinais automatizados de saúde disponíveis antes da indisponibilidade.

Declaração de suposição delimitada: esta autópsia assume que a cronologia e a descrição do caminho de código publicadas pela Cloudflare são materialmente corretas e trata a topologia interna não reportada como opaca.

Superfície institucional primária: Distributed Systems Architecture.

Linhas de capacidade engajadas:

Consistency and partition strategy design
Replica recovery and convergence patterns
Failure propagation control

Mapeamento da Superfície de Falha

Definir a superfície de falha do incidente como S = {C, N, K, I, O}:

C: plano de controle para estado autoritativo de prefixos BYOIP, comportamento da Addressing API, mutação de banco de dados e estado de service bindings.
N: camada de rede onde anúncios e retiradas BGP traduziram estado de controle em alcançabilidade global.
K: ciclo de vida de chaves para acesso administrativo autenticado e autoridade de mudança assinada; não há evidência pública de comprometimento de chaves.
I: fronteira de identidade entre ações BYOIP disparadas por clientes, automação interna de cleanup e privilégios de mutação em produção.
O: orquestração operacional para rollout de release, deployment mediado por saúde, rollback e recuperação manual.

Camadas dominantes de falha:

C falhou por semântica Bizantina: a API aceitou uma flag sintaticamente presente mas semanticamente vazia e retornou um conjunto de resultados incompatível com a intenção da tarefa de cleanup.
N amplificou o erro de plano de controle por comportamento legítimo de retirada BGP.
I falhou por compressão de privilégio: uma tarefa interna recorrente possuía autoridade suficiente para remover prefixos e service bindings dependentes em um namespace de produção de alto valor.
O falhou por timing e omissão: rollout e gates de saúde não interromperam a mutação antes que aproximadamente um quarto dos prefixos BYOIP fossem retirados.

Mapeamento de classe de falha:

Primária: Bizantina (requisição de API aparentemente válida produziu mutação de produção semanticamente inválida).
Secundária: Timing (velocidade de retirada excedeu a latência de detecção e contenção).
Secundária: Omissão (ausência de rejeição de schema, guarda de cardinalidade de mutação e fronteira de rollback por desired state).

Modelagem Formal de Falhas

Seja o estado de endereçamento em produção:

S_t = (D_t, A_t, B_t, H_t)

Onde D_t é a configuração desejada de prefixos do cliente, A_t é o estado autoritativo da Addressing API, B_t é o conjunto BGP anunciado externamente, e H_t é a telemetria de saúde para alcançabilidade e correção de bindings de produto.

A transição insegura de cleanup pode ser modelada como:

T(S_t, q) = \text{delete}(\text{Fetch}(q)) \to S_{t+1}

O invariante exigido é:

I(S_t) = (B_t \subseteq D_t) \land (\Delta |B_t| \leq \theta) \land (\text{bindings}(B_t)=1)

A violação observada é:

q=\text{pending\_delete sem valor} \Rightarrow \text{Fetch}(q)=A_t \not= D_{delete}

e portanto:

|B_t - B_{t+1}| \approx 1100 > \theta

Vínculo com decisão operacional: qualquer sistema capaz de alterar anúncio global de rotas deve impor um limite de retirada \theta e interromper a mutação quando o delta exceder um envelope pré-autorizado. O limite é controle de governança, não apenas parâmetro de monitoramento.

Modelo de Exploração Adversária

Classes de atacante:

A_passive: observa instabilidade de rotas e explora confusão de usuários, comportamento de timeout e canais de suporte degradados.
A_active: induz tráfego concorrente ou carga de plano de controle durante a restauração para aumentar a latência de recuperação.
A_internal: abusa de automação confiável ou privilégios de deploy para mutar estado de endereçamento.
A_supply_chain: compromete CI/CD ou dependências que constroem ou implantam componentes da Addressing API.
A_economic: monetiza downtime contra clientes cuja alcançabilidade pública depende de anúncio BYOIP.

Pressão de exploração:

E = \Delta t \times W \times P_s

Onde \Delta t é a latência de detecção até contenção, W é a largura da fronteira de confiança da automação de cleanup até a mutação BGP em produção, e P_s é o escopo de privilégio sobre prefixos de clientes e service bindings.

Tier A (confirmado): \Delta t foi material. O impacto começou às 17:56 UTC, o subprocesso defeituoso foi encerrado às 18:46 UTC, e a restauração completa terminou às 23:03 UTC.

Tier B (inferido): W era excessivo porque automação de cleanup, estado autoritativo e anúncio operacional de rotas estavam fortemente acoplados.

Tier C (desconhecido): Fontes públicas não revelam o modelo exato de autorização do subprocesso de cleanup nem se aprovação independente era exigida para deleção ampla de prefixos.

Fragilidade Arquitetural Raiz

A fragilidade raiz foi compressão de confiança entre configuração desejada do cliente, automação interna de cleanup e anúncio de rede em produção. Uma tarefa recorrente destinada a remover objetos pendentes de deleção podia afetar prefixos ativos e service bindings dependentes porque o caminho de estado autoritativo estava próximo demais do estado operacional.

A Addressing API operou como plano de controle de alta autoridade no qual uma pequena ambiguidade de schema teve implicações globais de roteamento. Este é um padrão estrutural de risco: quando um parâmetro Booleano ou semelhante a flag controla seleção destrutiva, ausência, vazio e falso precisam ser estados distinguíveis. Tratar uma flag vazia como caminho benigno de consulta converte ambiguidade de parser em mutação de infraestrutura.

A fraqueza de rollback também foi material. A Cloudflare afirma que alguns prefixos puderam ser restaurados por toggle no dashboard, enquanto outros exigiram recuperação de banco de dados e rollout global de configuração de máquinas porque service bindings haviam sido removidos. Isso indica separação insuficiente entre desired state, snapshot operacional e estado aplicado reversível.

Reconstrução em Nível de Código

// Guarda orientada a produção para cleanup destrutivo de estado de endereços.
func FetchPendingDeletion(req *http.Request, store PrefixStore) ([]Prefix, error) {
    values, present := req.URL.Query()["pending_delete"]
    if !present {
        return nil, errors.New("deny: pending_delete flag is required for cleanup task")
    }
    if len(values) != 1 || values[0] != "true" {
        return nil, fmt.Errorf("deny: malformed pending_delete=%q", values)
    }

    prefixes, err := store.FetchPrefixesPendingDeletion(req.Context())
    if err != nil {
        return nil, err
    }

    if len(prefixes) > MaxDeletionBatch || WithdrawalDelta(prefixes) > MaxWithdrawalDelta {
        return nil, errors.New("deny: deletion exceeds blast-radius envelope")
    }

    return prefixes, nil
}

A propriedade de controle é explícita: mutação destrutiva em produção deve rejeitar flags ambíguas, limitar cardinalidade de lote e medir delta de retirada de rotas antes da admissão da mutação.

Análise de Impacto Operacional

Tier A (confirmado): A Cloudflare informa aproximadamente 1.100 prefixos BYOIP retirados. Informa 4.306 prefixos BYOIP totais anunciados globalmente ao peer referenciado, com 25% retirados involuntariamente durante o incidente. A Cloudflare também informa que produtos usando BYOIP, incluindo Core CDN and Security Services, Spectrum, Dedicated Egress e Magic Transit, sofreram falhas de alcançabilidade ou operação degradada.

Métrica de blast radius:

B = \frac{\text{affected\_nodes}}{\text{total\_nodes}} = \frac{1100}{4306} \approx 0.255

Aqui affected_nodes mapeia para prefixos BYOIP afetados, não hosts físicos. A interpretação operacional é que aproximadamente um quarto do namespace de prefixos BYOIP na superfície de medição descrita entrou em estado inválido de anúncio.

Canais de impacto operacional:

Amplificação de latência: BGP path hunting e comportamento de conexões orientado por timeout aumentaram a duração percebida da falha para usuários finais.
Degradação de throughput: aplicações dependentes de prefixos BYOIP retirados não conseguiam atrair tráfego para a Cloudflare.
Exposição de capital: clientes cujos caminhos de ingresso, egresso ou proteção DDoS dependiam de anúncio BYOIP sofreram exposição direta de disponibilidade.
Blast radius: service bindings dependentes transformaram retirada de prefixos em assimetria de restauração por produto.

Camada de Tradução Empresarial

CTO: qualquer plataforma que use anúncio de endereços gerenciado por cloud deve tratar planos de controle de endereçamento do provedor como dependências críticas de produção. BYOIP reduz risco de portabilidade de IP, mas não elimina risco de mutação no provedor.

CISO: exigir evidência de que operações destrutivas de controle de rede são validadas por schema, escopadas por autorização, registradas e delimitadas por controles independentes de blast radius. O controle relevante não é apenas "quem pode fazer deploy", mas "qual delta máximo de produção uma automação pode produzir."

DevSecOps: codificar semântica de API como testes de política. Flag vazia, flag ausente, flag falsa e flag verdadeira devem ser distintas em workflows destrutivos. Adicionar regras de admissão para retirada de rotas em alta cardinalidade, deleção de service bindings e disponibilidade de snapshots de rollback.

Board: monitorar exposição de concentração quando alcançabilidade externa depende de plano de controle de terceiro. O risco em nível de conselho é downtime correlacionado entre unidades de negócio que usam o mesmo substrato de roteamento do provedor.

Modelo STIGNING de Hardening

Prescrições de controle:

Isolamento do plano de controle: separar configuração desejada do cliente, intenção interna de manutenção e snapshots de roteamento aplicados.
Segmentação do ciclo de vida de chaves: vincular mutação destrutiva de rotas a identidades de serviço estritamente escopadas, com credenciais de curta duração e envelopes explícitos de aprovação.
Hardening de quórum: exigir aprovação multipartes ou verificação independente automatizada para deltas de retirada acima de limite definido.
Reforço de observabilidade: detectar deltas de contagem de rotas, taxas de deleção de bindings e probes de alcançabilidade de clientes como sinais primários de segurança.
Envelope de rate limiting: limitar velocidade de deleção e retirada por contagem de prefixos, contagem de clientes, sensibilidade de ASN e dependência de produto.
Rollback seguro para migração: implantar snapshots imutáveis de estado aplicado que possam ser restaurados independentemente do banco autoritativo corrompido.

Modelo estrutural ASCII:

[Desired State do Cliente]
          |
          v
[API Validada por Schema] ---> [Fila de Intencao de Manutencao]
          |                              |
          v                              v
[Snapshot Aplicado Imutavel] --> [Controlador de Mutacao de Rotas]
          |                              |
          v                              v
[Service Bindings]              [Conjunto de Anuncio BGP]
          \______________________________/
                    |
                    v
        [Circuit Breaker de Alcancabilidade + Delta]

Implicação Estratégica

Classificação primária: fragilidade sistêmica de cloud.

A implicação de cinco a dez anos é que planos de controle de roteamento em cloud precisarão de governança de release mais próxima de software safety-critical do que de gestão ordinária de configuração. Empresas exigirão evidência contratual de rollout faseado de estado de endereços, circuit breakers de delta de rotas, snapshots operacionais reversíveis e controles de blast radius visíveis ao cliente. O BGP continuará determinístico dentro de seu modelo de protocolo, mas as camadas de abstração de cloud acima do BGP se tornarão a superfície dominante de falha para alcançabilidade na Internet.

Referências

Postmortem da Cloudflare: https://blog.cloudflare.com/cloudflare-outage-february-20-2026/
RFC 4271, Border Gateway Protocol 4: https://www.rfc-editor.org/rfc/rfc4271
Documentação de service bindings da Cloudflare: https://developers.cloudflare.com/byoip/service-bindings/

Conclusão

O incidente foi uma falha de integridade de plano de controle na qual semântica ambígua de API e automação destrutiva mutaram estado autoritativo de endereços, e então o BGP propagou corretamente a retirada resultante. O controle arquitetural não é desconfiar do BGP; é restringir os sistemas que decidem quais prefixos o BGP pode anunciar. Mitigação durável exige APIs destrutivas tipadas, envelopes explícitos de mutação, gates independentes de alcançabilidade e snapshots reversíveis de estado aplicado.

STIGNING Infrastructure Risk Commentary Series
Engineering Under Adversarial Conditions