Como filtrar prefixos não falsos recebidos via BGP de um Internet Exchange (IXP)?

Quando conectado a uma troca de pares da Internet (IXP), qual é uma boa maneira de garantir que as pessoas não lhe enviem prefixos que não deveriam estar anunciando?

Com relação aos truques, conheço o projeto Team Cymru Bogon Reference , mas quando se trata de filtrar qualquer outra coisa dos colegas, não tenho idéia por onde começar. Meu entendimento é que é para isso que servem RPKI e similares?

Como os outros afirmaram, o RPKI seria o caminho a seguir, mas ainda não está lá. Nos pontos de troca, geralmente colocamos um limite de prefixo máximo em cada sessão.

Além disso, usamos as seguintes regras:

1. Nenhuma rota padrão

2. Sem truques, mais exatamente nesta lista:

   route-filter 0.0.0.0/8 orlonger reject;
   route-filter 127.0.0.0/8 orlonger reject;
   route-filter 10.0.0.0/8 orlonger reject;
   route-filter 172.16.0.0/12 orlonger reject;
   route-filter 192.168.0.0/16 orlonger reject;
   route-filter 224.0.0.0/4 orlonger reject;
   route-filter 240.0.0.0/4 orlonger reject;
   route-filter 169.254.0.0/16 orlonger reject;
   route-filter 192.0.2.0/24 orlonger reject;
   route-filter 198.51.100.0/24 orlonger reject;
   route-filter 203.0.113.0/24 orlonger reject;
   route-filter 100.64.0.0/10 orlonger reject;
   

3. Nenhum prefixo maior que / 24

4. Nenhum número de AS privado no caminho

5. Nenhum de nossos próprios prefixos

Para o IPv6, fazemos o mesmo, apenas os bogons são diferentes. Eu colei nosso filtro abaixo disso. Esteja ciente de que a sintaxe pode ser um pouco estranha, mas isso se deve à maneira como o Juniper combina prefixos. Para a sintaxe da Cisco, você pode acessar aqui: Recomendações de filtro IPv6 BGP (o exemplo do Juniper na página é de buggy, use o abaixo, se desejar.)

termo ebgp-relaxado {
    a partir de {
        família inet6;
        filtro de rota 3ffe :: / 16 ou mais;
        filtro de rota 0000 :: / 8 ou mais;
        filtro de rota 2001: db8 :: / 32 orlonger;
        filtro de rota 2001 :: / 32 política exata seguinte;
        filtro de rota 2001 :: / 32 por mais tempo;
        filtro de rota 2002 :: / 16 política exata seguinte;
        filtro de rota 2002 :: / 16 por mais tempo;
        filtro de rota fe00 :: / 9 ou mais;
        filtro de rota ff00 :: / 8 ou mais;
        filtro de rota 2000 :: / 3 prefix-length-range / 49- / 128;
        filtro de rota 0 :: / 0 ou mais;
    }
    então rejeite;
}

No momento (até que o RPKI seja mais difundido), geralmente apenas filtramos bogons comuns e aplicamos um filtro de prefixo máximo para trocar pares. Também filtramos certos ASNs, aqueles que, com certeza, nunca aparecerão na maioria das sessões de peering, como Level3 ou Cogent, ou não devem ser transitados durante uma troca.

Normalmente, achamos que a maioria dos vazamentos de rotas comuns não está no intervalo de 1-2 dígitos. De qualquer maneira, é muito difícil captá-lo, a menos que você filtre todos os seus pares criando uma lista de prefixos / ASN ou radb, etc. ) filtro de prefixo máximo. Em seguida, você pode ajustar essa sessão, conforme necessário.

Dependendo de como você está usando a troca de pares, você tem algumas opções diferentes:

Primeiramente, abordarei o RPKI e direi que, embora seja algo que você definitivamente deva seguir em frente e implantar, tanto para suas próprias rotas quanto para validar outras, infelizmente é tão pouco usado que você não pode esperar que ele faça tanto. A solução real aqui é o WHOIS - o RaDB da Merit é sem dúvida o melhor, pois permitirá que você retorne resultados para todos os RIRs de uma só vez. Mas, se você preferir consultar cada RIR diretamente, faça isso.

Agora, se você estiver no mercado e estiver obtendo apenas uma pilha de prefixos no servidor de rotas do IXP, dependendo das ferramentas disponíveis e dos recursos do seu roteador, você tem duas possibilidades:

   1. Filtrar por origem AS

Essencialmente, isso consiste em validar o AS de origem de um prefixo em relação ao do WHOIS - se o AS de origem não corresponder ao do WHOIS, você solta o prefixo e quaisquer outras informações específicas que também possam ser anunciadas. Geralmente, essa é uma boa proteção contra invasões não intencionais. A grande maioria dos prefixos deve ter esses dados.

   2. Filtrar por trânsito AS

Isso leva um passo adiante e filtra as rotas com qualquer AS no caminho que não esteja autorizado no WHOIS - você não pode fazer isso para todos os prefixos, no entanto, pois nem todo mundo terá criado objetos especificando quem são seus fornecedores de AS de trânsito autorizados.

Por outro lado, se você estiver usando a troca de pares para se relacionar diretamente com os outros, sua vida ficará muito mais simples; você pode procurar quais prefixos eles possuem no WHOIS e permitir esses. Em minha opinião, uma boa prática é permitir que os pares anunciem mais detalhes específicos até um comprimento máximo de / 24 e, ao mesmo tempo, defina um valor sensível de prefixo máximo (ou seja, proporcional ao número de sub-redes que eles têm) nos seus pares para que eles possam ' não o enche de rotas, mas pode responder a um seqüestro de prefixo.

Se você está procurando ferramentas, consulte o IRRToolSet e o IRR PowerTools

Você basicamente respondeu sua própria pergunta. Sua suposição de que o uso do RPKI é o caminho a seguir é absolutamente correta. Mais especificamente, as Autorizações de Originação de Rota são usadas para validar um prefixo para um AS. Obviamente, os bogons não serão válidos porque não estão atribuídos a ninguém, de modo que o problema se resolverá. Muitas dessas informações estão disponíveis na página da Wikipédia RPKI . Outro bom recurso é a página RPKI do ARIN .

Se você precisar de ajuda na configuração, sugiro que você crie outra pergunta solicitando ajuda específica na configuração.

Também vale a pena notar que o RPKI não funcionará para tudo, porque nem todo mundo está usando. Em algum momento, você só precisa confiar nas rotas que está recebendo.

Pergunte a seus colegas qual macro AS eles anunciarão e construa filtros para eles usando IRRToolSet ou rpsltool ou irrpt. Incentive-os a publicar as informações corretas em um IRRdb. Não se esqueça de atualizar seu próprio aut-numobjeto no IRRdb amigável mais próximo para refletir a adjacência.

O RPKI não é o caminho a seguir, pois não protege contra vazamentos de rotas.