¿Cómo filtrar los prefijos no bogon recibidos a través de BGP desde un intercambio de Internet (IXP)?

Cuando se conecta a un intercambio de pares de Internet (IXP), ¿cuál es una buena manera de asegurarse de que las personas no le envíen prefijos que no deberían anunciar?

Con respecto a los bogons, conozco el proyecto Team Cymru Bogon Reference , pero cuando se trata de filtrar cualquier otra cosa de los compañeros, no tengo idea de por dónde empezar. Tengo entendido que para esto están destinados RPKI y similares.

Como dijeron los demás, RPKI sería el camino a seguir, pero aún no está allí. En los puntos de intercambio generalmente ponemos un límite de prefijo máximo en cada sesión.

Además utilizamos las siguientes reglas:

1. Sin ruta predeterminada

2. Sin bogons, más exactamente esta 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. No hay prefijos más largos que / 24

4. No hay números AS privados en la ruta

5. Ninguno de nuestros propios prefijos

Para IPv6 hacemos lo mismo, solo los bogons son diferentes. Pegué nuestro filtro debajo de esto. Tenga en cuenta que la sintaxis puede ser un poco extraña, pero eso se debe a la forma en que Juniper combina los prefijos. Para la sintaxis de Cisco, puede ir aquí: recomendaciones de filtro BGP IPv6 (el ejemplo de Juniper en la página tiene errores, use el siguiente si lo desea).

término ebgp-relajado {
    desde {
        familia inet6;
        route-filter 3ffe :: / 16 orlonger;
        filtro de ruta 0000 :: / 8 orlonger;
        route-filter 2001: db8 :: / 32 orlonger;
        route-filter 2001 :: / 32 próxima política exacta;
        route-filter 2001 :: / 32 más largo;
        route-filter 2002 :: / 16 próxima política exacta;
        route-filter 2002 :: / 16 más largo;
        route-filter fe00 :: / 9 orlonger;
        route-filter ff00 :: / 8 orlonger;
        route-filter 2000 :: / 3 prefix-length-range / 49- / 128;
        route-filter 0 :: / 0 orlonger;
    }
    luego rechazar;
}

En este momento (hasta que RPKI esté más extendido), generalmente solo filtramos los bogons comunes y aplicamos un filtro de prefijo máximo para intercambiar pares. También filtramos ciertos ASN, los que estamos seguros nunca aparecerán en la mayoría de las sesiones de emparejamiento, como Level3 o Cogent, o no se deben transitar por un intercambio.

Por lo general, encontramos que la mayoría de las fugas de ruta comunes no están en el rango de 1-2 dígitos. De todos modos, eso es muy difícil de atrapar, a menos que filtre a todos sus pares creando una lista de prefijos / ASN o filtre por radb, etc. ) filtro de prefijo máximo. Luego puede ajustar eso por sesión según sea necesario.

Dependiendo de cómo esté utilizando el intercambio entre pares, tiene algunas opciones diferentes:

En primer lugar, cubriré RPKI y diré que, si bien es algo que definitivamente debes seguir adelante y desplegar, tanto para tus propias rutas como para validar otras, desafortunadamente es de tan bajo uso que no puedes esperar que haga tanto. La verdadera solución aquí es WHOIS: se puede decir que el RaDB de Merit es el mejor, ya que le permitirá devolver resultados para todos los RIR a la vez. Pero, si prefiere consultar cada RIR directamente, hágalo.

Ahora, si está en el intercambio y solo está obteniendo un montón de prefijos del servidor de ruta del IXP, dependiendo de las herramientas que tenga disponibles y las capacidades de su enrutador, tiene dos posibilidades:

   1. Filtrar por origen AS

Esencialmente, esto consiste en validar el origen AS de un prefijo contra el de WHOIS: si el origen AS no coincide con el de WHOIS, se descarta el prefijo y cualquier otra información específica que también se pueda anunciar. Esto generalmente es una buena protección contra secuestros involuntarios. La gran mayoría de los prefijos deberían tener estos datos.

   2. Filtrar por tránsito AS

Esto va un paso más allá y filtra las rutas con cualquier AS en la ruta que no esté autorizada dentro de WHOIS; sin embargo, no puede hacer esto para cada prefijo, ya que no todos habrán creado objetos que especifiquen quiénes son sus proveedores autorizados de AS de tránsito.

Por otro lado, si está utilizando el intercambio de pares para mirar directamente con otros, entonces su vida se vuelve mucho más simple; puede buscar qué prefijos tienen en WHOIS y permitirlos. En mi opinión, una buena práctica es permitir que los pares anuncien más detalles hasta una longitud máxima de / 24 al tiempo que establecen un valor sensible de prefijo máximo (es decir, proporcional al número de subredes que tienen) en su peering para que puedan ' No te inunda de rutas, pero puede responder a un secuestro de prefijo.

Si está buscando herramientas, consulte IRRToolSet e IRR PowerTools

Básicamente has respondido tu propia pregunta. Su suposición de que usar RPKI es el camino a seguir es absolutamente correcta. Más específicamente, las autorizaciones de origen de ruta se utilizan para validar un prefijo a un AS. Obviamente, los bogons no serán válidos porque no están asignados a nadie, por lo que ese problema se solucionará solo. Mucha de esta información está disponible en la página de Wikipedia RPKI . Otro buen recurso es la página RPKI de ARIN .

Si necesita ayuda con la configuración, le sugiero que cree otra pregunta solicitando ayuda con la configuración específica.

También vale la pena señalar que RPKI no funcionará para todo, porque no todos lo están usando. En algún momento solo tienes que confiar en las rutas que estás recibiendo.

Pregunte a sus pares qué macro AS anunciarán y construyan filtros para ellos usando IRRToolSet o rpsltool o irrpt. Aliéntelos a tener información correcta publicada en un IRRdb. No olvide actualizar su propio aut-numobjeto en su IRRdb amigable más cercano para reflejar la adyacencia.

RPKI no es el camino a seguir, ya que no protege contra las fugas de ruta.