Como a Verizon e um otimizador de BGP derrubaram grandes partes da Internet

Vazamento maciço de rota afeta grandes partes da Internet, incluindo a Cloudflare

O que aconteceu?

Hoje às 10: 30UTC, a Internet teve um pequeno ataque cardíaco. Uma pequena empresa no norte da Pensilvânia tornou-se o caminho preferido de muitas rotas da Internet através da Verizon (AS701), um importante provedor de trânsito da Internet. Isso equivalia ao Waze rotear uma via expressa inteira por uma rua do bairro – resultando na indisponibilidade de muitos sites na Cloudflare, e muitos outros provedores, de grandes partes da Internet. Isso nunca deveria ter acontecido porque a Verizon nunca deveria ter encaminhado essas rotas para o resto da Internet. Para entender por que, continue a ler.

Nós escrevemos sobre esses eventos infelizes no passado, já que eles não são incomuns. Desta vez, o dano foi visto em todo o mundo. O que exacerbou o problema hoje foi o envolvimento de um produto “BGP Optimizer” da Noction. Este produto tem um recurso que divide os prefixos IP recebidos em partes menores e contribuintes (chamadas de mais específicas). Por exemplo, nossa própria rota IPv4 104.20.0.0/20 foi transformada em 104.20.0.0/21 e 104.20.8.0/21. É como se o sinal de trânsito que direciona o tráfego para “Pensilvânia” fosse substituído por dois sinais de trânsito, um para “Pittsburgh, PA” e outro para “Filadélfia, PA”. Ao dividir esses grandes blocos de IP em partes menores, uma rede tem um mecanismo para direcionar o tráfego dentro de sua rede, mas essa divisão nunca deveria ter sido anunciada para o mundo como um todo. Quando foi causado a interrupção de hoje.

Para explicar o que aconteceu a seguir, aqui está um breve resumo de como funciona o “mapa” subjacente da Internet. “Internet” significa literalmente uma rede de redes e é composta de redes chamadas Sistemas Autônomos (AS), e cada uma dessas redes tem um identificador único, seu número AS. Todas essas redes são interconectadas usando um protocolo chamado Border Gateway Protocol (BGP). O BGP une essas redes e constrói o “mapa” da Internet que permite que o tráfego viaje, digamos, do seu ISP para um site popular no outro lado do globo. 

Usando o BGP, as redes trocam informações de rotas: como chegar até elas de onde você estiver. Essas rotas podem ser específicas, semelhantes a encontrar uma cidade específica no seu GPS ou muito gerais, como apontar seu GPS para um estado. É aqui que as coisas deram errado hoje.

Um provedor de serviços de Internet na Pensilvânia ( AS33154 – DQE Communications) estava usando um otimizador de BGP em sua rede, o que significava que havia muitas rotas mais específicas em sua rede. Rotas específicas sobrepõem-se a rotas mais gerais (na analogia do Waze, uma rota para, digamos, o Palácio de Buckingham é mais específica do que uma rota para Londres). 

A DQE anunciou essas rotas específicas para seus clientes ( AS396531 – Allegheny Technologies Inc). Todas essas informações de roteamento foram enviadas para seu outro provedor de trânsito ( AS701 – Verizon), que passou a informar toda a Internet sobre essas rotas “melhores”. Essas rotas eram supostamente “melhores” porque eram mais granulares, mais específicas.

O vazamento deveria ter parado na Verizon. No entanto, contra inúmeras práticas recomendadas descritas abaixo, a falta de filtragem da Verizon transformou isso em um grande incidente que afetou muitos serviços da Internet, como Amazon, Linode e Cloudflare . 

O que isto significa é que, de repente, a Verizon, Allegheny e DQE tiveram que lidar com uma debandada de usuários da Internet tentando acessar esses serviços através de sua rede. Nenhuma dessas redes estava adequadamente equipada para lidar com esse drástico aumento no tráfego, causando interrupção no serviço. Mesmo que eles tivessem capacidade suficiente, DQE, Allegheny e Verizon não foram autorizados a dizer que tinham a melhor rota para Cloudflare, Amazon, Linode, etc …

Durante o incidente, observamos uma perda, no pior dos casos, de cerca de 15% do nosso tráfego global.

Como esse vazamento poderia ter sido evitado?

Existem várias maneiras de evitar esse vazamento: 

Uma sessão do BGP pode ser configurada com um limite rígido de prefixos a serem recebidos. Isso significa que um roteador pode decidir encerrar uma sessão se o número de prefixos ultrapassar o limite. Se a Verizon tivesse tal limite de prefixo, isso não teria ocorrido. É uma prática recomendada ter esses limites no lugar. Não custa nada a um provedor como a Verizon ter tais limites no lugar. E não há nenhuma boa razão, além de desleixo ou preguiça, de que eles não teriam tais limites no lugar.

Uma forma diferente de operadores de rede podem evitar que vazamentos como este sejam implementados pela filtragem baseada em IRR. A IRR é o Internet Routing Registry e as redes podem adicionar entradas a esses bancos de dados distribuídos. Outros operadores de rede podem então usar esses registros IRR para gerar listas de prefixo específicas para as sessões BGP com seus pares. Se a filtragem de IRR tivesse sido usada, nenhuma das redes envolvidas teria aceitado as falhas mais específicas. O que é bastante chocante é que parece que a Verizon não implementou nada dessa filtragem em sua sessão de BGP com a Allegheny Technologies, embora a filtragem de IRR esteja presente (e bem documentada) há mais de 24 anos. A filtragem de IRR não aumentaria os custos da Verizon nem limitaria seu serviço de forma alguma. Mais uma vez, a única explicação que podemos conceber porque não foi

A estrutura RPKI que implementamos e implementamos globalmente no ano passado foi projetada para evitar esse tipo de vazamento. Permite a filtragem na rede de origem e no tamanho do prefixo. Os prefixos anunciados pela Cloudflare são assinados para um tamanho máximo de 20. O RPKI indica então que qualquer prefixo mais específico não deve ser aceito, não importa qual seja o caminho. Para que esse mecanismo tome uma ação, uma rede precisa ativar a validação de origem do BGP. Muitos provedores como a AT & T já o habilitaram com sucesso em sua rede.

Se a Verizon tivesse usado o RPKI, eles teriam visto que as rotas anunciadas não eram válidas e as rotas poderiam ter sido descartadas automaticamente pelo roteador. 

A Cloudflare incentiva todos os operadores de rede a implementarem o RPKI agora!

Todas as sugestões acima são bem condensadas em MANRS ( normas mutuamente acordadas para segurança de roteamento )

Como foi resolvido

A equipe de rede da Cloudflare alcançou as redes envolvidas, AS33154 (DQE Communications) e AS701 (Verizon). Tivemos dificuldades em chegar a qualquer rede, isso pode ter sido devido ao tempo do incidente, pois ainda era cedo na Costa Leste dos EUA quando o vazamento de rota começou.

Um de nossos engenheiros de rede entrou em contato com a DQE Communications rapidamente e, após um pequeno atraso, eles puderam nos colocar em contato com alguém que poderia resolver o problema. A DQE trabalhou conosco ao telefone para parar de anunciar essas rotas “otimizadas” para a Allegheny Technologies Inc. Estamos agradecidos por sua ajuda. Depois disso, a Internet se estabilizou e as coisas voltaram ao normal.

É lamentável que, embora tenhamos tentado tanto o e-mail quanto as ligações telefônicas para entrar em contato com a Verizon, no momento em que escrevemos este artigo (mais de 8 horas após o incidente), não recebemos notícias deles nem estamos cientes deles. Ou se tomaram medidas para resolver o problema. 

Na Cloudflare, desejamos que eventos como esse nunca aconteçam, mas infelizmente o estado atual da Internet faz muito pouco para evitar que incidentes como esse ocorram. Chegou a hora de a indústria adotar uma melhor segurança de roteamento por meio de sistemas como o RPKI. Esperamos que os principais fornecedores sigam o exemplo da Cloudflare, Amazon e AT & T e iniciem a validação de rotas . E, em particular, estamos olhando para você Verizon – e ainda esperando sua resposta.

Apesar de isso ser causado por eventos fora do nosso controle, lamentamos a interrupção. Nossa equipe se preocupa profundamente com nosso serviço e nós tivemos engenheiros nos EUA, Reino Unido, Austrália e Cingapura on-line minutos depois que esse problema foi identificado.

Fontes:
Por Tom Strickx 2019-06-24
Matéria enviada pelo leitor Guilherme da empresa Made4IT
guilherme@made4it.com.br