Anúncio condicional que permite a instalação condicional de casos de uso de prefixos
As redes são geralmente subdivididas em unidades menores e mais gerenciáveis chamadas sistemas autônomos (ASs). Quando o BGP é usado por roteadores para formar relações de pares no mesmo AS, ele é chamado de BGP interno (IBGP). Quando o BGP é usado por roteadores para formar relações entre pares em diferentes ASs, ele é chamado de BGP externo (EBGP).
Após realizar verificações de sanidade de rota, um roteador BGP aceita as rotas recebidas de seus pares e as instala na tabela de roteamento. Por padrão, todos os roteadores em sessões de IBGP e EBGP seguem as regras padrão de anúncio BGP. Enquanto um roteador em uma sessão do IBGP anuncia apenas as rotas aprendidas com seus pares diretos, um roteador em uma sessão de EBGP anuncia todas as rotas aprendidas com seus pares diretos e indiretos (pares de pares). Assim, em uma rede típica configurada com EBGP, um roteador adiciona todas as rotas recebidas de um peer EBGP em sua tabela de roteamento e anuncia quase todas as rotas para todos os pares de EBGP.
Um provedor de serviços que troca rotas BGP com clientes e colegas na Internet corre o risco de ameaças maliciosas e não intencionais que podem comprometer o roteamento adequado do tráfego, bem como a operação dos roteadores.
Isso tem várias desvantagens:
Non-aggregated route advertisements— Um cliente poderia anunciar erroneamente todos os seus prefixos ao ISP em vez de um agregado de seu espaço de endereço. Dado o tamanho da tabela de roteamento da Internet, isso deve ser cuidadosamente controlado. Um roteador de borda também pode precisar apenas de uma rota padrão para a Internet e, em vez disso, estar recebendo toda a tabela de roteamento BGP de seus peer upstream.
BGP route manipulation— Se um administrador mal-intencionado alterar o conteúdo da tabela de roteamento BGP, ele poderá impedir que o tráfego chegue ao destino desejado.
BGP route hijacking— Um administrador desonesto de um peer BGP poderia anunciar maliciosamente os prefixos de uma rede na tentativa de redirecionar o tráfego destinado à rede da vítima para a rede do administrador para obter acesso ao conteúdo do tráfego ou bloquear os serviços on-line da vítima.
BGP denial of service (DoS)— Se um administrador malicioso enviar tráfego BGP inesperado ou indesejável para um roteador na tentativa de usar todos os recursos BGP disponíveis do roteador, isso pode resultar em prejudicar a capacidade do roteador de processar informações de rota BGP válidas.
A instalação condicional de prefixos pode ser usada para resolver todos os problemas mencionados anteriormente. Se um cliente precisar de acesso a redes remotas, é possível instalar uma rota específica na tabela de roteamento do roteador conectado com a rede remota. Isso não acontece em uma rede EBGP típica e, portanto, a instalação condicional de prefixos torna-se essencial.
As ASs não são apenas vinculadas por relações físicas, mas por negócios ou outras relações organizacionais. Um AS pode fornecer serviços a outra organização ou agir como um AS de trânsito entre duas outras ASs. Essas ASs de trânsito são vinculadas por acordos contratuais entre as partes que incluem parâmetros sobre como se conectar entre si e, o mais importante, o tipo e a quantidade de tráfego que transportam entre si. Portanto, por razões legais e financeiras, os provedores de serviços devem implementar políticas que controlem como as rotas BGP são trocadas com vizinhos, quais rotas são aceitas desses vizinhos e como essas rotas afetam o tráfego entre as ASs.
Existem muitas opções diferentes disponíveis para filtrar rotas recebidas de um peer BGP para aplicar políticas inter-AS e mitigar os riscos de receber rotas potencialmente nocivas. A filtragem de rotas convencional examina os atributos de uma rota e aceita ou rejeita a rota com base em tais atributos. Uma política ou filtro pode examinar o conteúdo do AS-Path, o valor do próximo salto, um valor de comunidade, uma lista de prefixos, a família de endereços da rota e assim por diante.
Em alguns casos, a "condição de aceitação" padrão de corresponder a um determinado valor de atributo não é suficiente. O provedor de serviços pode precisar usar outra condição fora da própria rota, por exemplo, outra rota na tabela de roteamento. Como exemplo, pode ser desejável instalar uma rota padrão recebida de um peer upstream, somente se for possível verificar se esse peer tem acessibilidade para outras redes ainda mais upstream. Esta instalação de rota condicional evita a instalação de uma rota padrão que é usada para enviar tráfego para este peer, quando o peer pode ter perdido suas rotas upstream, levando ao tráfego black-holed. Para isso, o roteador pode ser configurado para procurar a presença de uma rota específica na tabela de roteamento e, com base nesse conhecimento, aceitar ou rejeitar outro prefixo.
Exemplo: Configurar uma política de roteamento para anúncio condicional que permite a instalação condicionada de prefixos em uma tabela de roteamento explica como a instalação condicional de prefixos pode ser configurada e verificada.