Resumo

  • Um domínio interno anunciou muitos prefixos para o backbone dos centros de dados. Cada rota carregava uma comunidade BGP atribuída legitimamente àquele domínio e passou pela route-map de entrada; os roteadores de agregação receberam o conjunto inteiro, ficaram sem memória e reiniciaram os processos de roteamento.
  • A proposta de Daria Shantalova separa identidade do prefixo, autorização em cada fronteira e verificação contínua do estado real da rede.
  • A apresentação diz que quase todas as violações observadas foram eliminadas em alguns meses, mas não mostra o total inicial, o número restante ou uma série datada.

O crachá era verdadeiro. A autorização não veio junto.

O detalhe mais revelador do incidente apresentado por Daria Shantalova na RIPE 93 é que as rotas não chegaram com um rótulo falso. Um domínio interno vizinho anunciou um volume grande de prefixos para o Express Backbone que liga centros de dados. Cada prefixo trazia uma comunidade BGP legitimamente atribuída ao domínio. A route-map de entrada reconheceu o valor e aceitou os anúncios.

Depois, as rotas se espalharam pela malha iBGP interna. Os roteadores de agregação dos centros de dados receberam o conjunto completo; o daemon de roteamento esgotou a memória disponível e reiniciou. Os materiais públicos não informam a quantidade exata de prefixos, quantos roteadores foram atingidos nem quanto durou a interrupção. Eles mostram o ponto cego: o filtro validava a comunidade do domínio emissor, mas não se cada prefixo tinha permissão para atravessar aquela fronteira.

Uma comunidade pode identificar o domínio de origem e descrever o alcance de propagação. Não dá autorização automática a todos os prefixos que carreguem o valor. A política tratou uma etiqueta correta como se fosse uma lista completa de permissões.

Limitar a quantidade não define o que pode entrar

Os controles respondem a perguntas diferentes. O máximo de prefixos pergunta quantas rotas chegaram. Uma lista de prefixos permitidos pergunta quais podem entrar por uma fronteira. O filtro de comunidade pergunta se o rótulo é reconhecido ou deve ser mantido. Eles se complementam; nenhum substitui os demais. A RFC 7454 trata separadamente filtragem de prefixos, limite de volume e tratamento de comunidades. A RFC 4271 define a troca de informações de alcançabilidade e as decisões de rota do BGP.

A primeira camada sugerida por Shantalova é a identidade: cada prefixo recebe uma comunidade BGP ID que informa o domínio de origem e o alcance permitido. ID ausente, incorreto, repetido ou conflitante conta como violação. A segunda camada é autoridade: um Route Registry interno registra a origem e a comunidade esperadas para cada prefixo, e gera filtros de entrada para cada fronteira entre domínios. A terceira compara continuamente os RIBs de produção com o registro, encontra prefixos não cadastrados e divergências de comunidade ou de intenção, e dispara alertas.

O registro diz o que deveria estar ativo; o RIB mostra o que os roteadores aceitaram. Uma exportação de configuração feita na implantação não mantém os dois alinhados para sempre. É a comparação contínua que fecha o circuito.

“Quase todas” pede a conta completa

O resumo da sessão afirma que a equipe removeu “quase todas” as violações observadas em poucos meses e que a aplicação automatizada impede o retorno. Os slides não trazem a quantidade inicial, o resíduo exato, uma cronologia das violações nem o total de fronteiras cobertas. Uma série antes e depois, com a cobertura de implantação, permitiria separar o efeito da limpeza inicial do efeito da automação.

Para o operador, a saída não é acrescentar mais um filtro e encerrar o incidente. Cada controle precisa ter uma pergunta própria, e a resposta precisa ser comparada ao estado instalado. Quando uma etiqueta válida vira autorização total, o equipamento pode aplicar com precisão uma permissão que nunca foi conferida.

Fontes: sessão e resumo da RIPE 93; transcrição oficial; slides originais; RFC 4271; RFC 7454.