Uma das principais funcionalidades do serviço de monitoramento e análise de BGP é o monitoramento de anomalias específicas que podem resultar em um incidente, que denominamos vazamento de rota BGP ou sequestro de BGP.
Ambos redirecionam o tráfego para terceiros, em comparação com o estado sem anomalias, mas de maneiras diferentes. Nos últimos anos, muitos esforços foram investidos na resolução desses problemas, mas ainda existem mal-entendidos sobre o que é o quê e como diferentes ferramentas ajudam a resolver diferentes problemas.
Começamos a coletar o modelo de relacionamentos BGP alguns anos antes do surgimento da RFC 7908, tentando definir o que é um vazamento de rota BGP. As duas principais diferenças entre esses momentos de ocorrência foram descritas como:
- Rotas redirecionadas por meio de ASNs/links incorretos (Vazamentos de rota), descritos como tipos 1 a 4 na RFC 7908.
- Rotas redirecionadas para ASNs incorretos (Sequestro de rota), descritas como tipos 5 e 6 na RFC 7908.
Durante um vazamento de rota BGP, o tráfego destinado à sua rede provavelmente fluirá de forma ineficiente, o que pode levar ao aumento da latência e à perda de pacotes. No entanto, ele quase certamente chegará à sua rede, a menos que haja congestionamento crítico devido a algum motivo (como a má intenção de um malfunctor). Durante um sequestro de rota BGP, o tráfego destinado à sua rede é redirecionado para um terceiro e permanece lá. Além disso, os mecanismos para criar esses tipos de anomalias também são diferentes. Para criar um vazamento de rota, é necessário transferir uma rota válida para um provedor de internet vizinho inadequado. Para criar um sequestro de rota, é preciso anunciar uma rota com um subprefixo/prefixo válido mais específico (para atrair todo o tráfego dos provedores de internet que receberam tal anúncio com o AS_PATH desejado) ou criar um anúncio de rota com um prefixo de terceiro a partir da sua rede. Como os mecanismos para criar anomalias de roteamento variam, os mecanismos de detecção e prevenção/mitigação de incidentes também devem ser diferentes.
Para detectar a causa de um vazamento de rotas, é necessário descobrir a relação entre cada uma das duas operadoras conectadas e identificar as rotas BGP (obtidas de um coletor BGP) que violam o modelo formal de Gao-Rexford. Para mais informações, consulte “Relações AS” da CAIDA. Para detectar sequestros de rotas, é preciso ter informações precisas sobre quais prefixos pertencem a quais ISPs e, na maioria dos casos, quando um par de prefixos de ISPs não registrados aparece, é necessário gerar um alerta ou tomar alguma ação.
Para prevenir/mitigar sequestros de rotas, existem duas abordagens padrão dentro de uma estrutura de Validação de Origem de Prefixo (POV). Você pode registrar um objeto Route em seu IRR ou criar um objeto ROA. Nossa equipe descreveu as diferenças entre essas abordagens durante o RIPE79. No entanto, o que elas têm em comum é que ambas definem quais prefixos pertencem a quais operadoras (pelas próprias operadoras) e tentam bloquear rotas de um ISP com prefixos não registrados (por ISPs de trânsito). Para prevenir/mitigar vazamentos de rotas puros, participamos da criação de uma política aberta de BGP. Outra abordagem é o bloqueio de pares — bloquear rotas com vizinhos/ISPs inesperados no AS_PATH. O rascunho do ASPA da IETF se destaca um pouco da prevenção pura de sequestro/vazamento de rotas, pois se concentra mais no bloqueio de AS_PATHs ruins (casos de vazamento de rotas e sequestros com/sem manipulação inadequada do AS_PATH).
ROA vs. Vazamentos de Rota
Então, sua rede estará segura se você implementar assinatura ROA e filtragem ROA? Não, porque sem ASPA ou qualquer equivalente, o ROA por si só não impedirá que outros vazem rotas. Esperamos que agora você entenda a complexidade desse problema, onde abordagens distintas são necessárias para proteger a base do roteamento interdomínio moderno: o Border Gateway Protocol (BGP).
Assinatura ROA vs. Filtragem ROA
Outro equívoco comum está relacionado ao ROA. Existem duas partes nos algoritmos ROA: a parte que assina – o operador, que fornece a verdade fundamental sobre os prefixos que possui; e a parte que filtra – o operador de trânsito, que filtra rotas ruins de acordo com as informações fornecidas pela parte que assina.
Como um operador stub (ou seja, um AS com apenas um provedor upstream), você tem um número limitado de maneiras de influenciar a quantidade de partes que filtram. Quanto mais partes filtram, mais seguros seus prefixos serão (menos regiões serão afetadas se um sequestrador decidir atacar seus prefixos). Se você optar por assinar seus prefixos, poderá usar uma infraestrutura de filtragem existente, que só tende a crescer no futuro próximo. Além disso, recomendamos que você faça exatamente isso, independentemente do tamanho da rede por trás do seu ASN.
Este artigo termina com um alerta: a infraestrutura de filtragem atual ainda pode ser imperfeita e, em alguns casos, você não conseguirá retornar o tráfego de uma região afetada devido à opção de comprimento máximo escolhida e à filtragem ROA (Root Access Address) do seu provedor de internet.
Leave a Reply