Filtro de agujero negro activado por control remoto (RTBH) BGP para Juniper

Estoy tratando de encontrar la forma más elegante de implementar un filtro RTBH para las rutas recibidas de un cliente.

El filtro debe:

1. Solo acepte los prefijos propios de los clientes de una lista de prefijos
2. Solo acepta / 32 prefijos
3. Solo prefijos con la comunidad blackhole
4. Establezca el siguiente salto en el RTBH siguiente salto (192.0.2.1)

Para comenzar, miré el documento " Configuración de condiciones de coincidencia en términos de política de enrutamiento " de Juniper.

Primero pensé en combinar una prefix-list-filterpara que solo coincida con las rutas de la lista de prefijos de los clientes y una route-filterpara limitar los prefijos aceptados a / 32, así:

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

Pero luego me topé con esta información en el documento:

Si configura una política que incluye alguna combinación de filtros de ruta, listas de prefijos y filtros de dirección de origen, se evalúan de acuerdo con una operación OR lógica o una búsqueda de coincidencia de ruta más larga.

Según tengo entendido (y lo encuentro un poco confuso), si lo uso prefix-list-filter, route-filtery / o source-address-filteren el mismo término, se evaluaría con un OR más largo entre todos, lo que hace que este enfoque sea inutilizable .

Lo que se me ocurrió es este el siguiente filtro. El hostroutes-onlytérmino desvía todos los prefijos más cortos que / 32 a la siguiente política. Después de eso, el prefixestérmino coincide si el / 32 está en el rango del cliente, coincide con su ruta de acceso y tiene establecida la comunidad de agujeros negros:

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

Entonces, ¿es esta la forma más elegante de manejar esto? ¿Alguna otra solución?

No hay ninguna razón para limitar al cliente solo al agujero negro / 32, permitirles bloquear cualquier cosa de ellos.

Algo como esto:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Recuerde configurar 'accept-remote-nexthop' en la configuración de BGP, para que el siguiente salto se pueda cambiar a algo más que la dirección del enlace.

También apoyo firmemente que los proveedores comiencen a admitir diferentes comunidades de agujeros negros que solo 'agujeros negros completos'. Especialmente si opera en más de un país, generalmente el ataque es de tránsito y, a menudo, el cliente realmente desea acceder a pares nacionales, por lo que es útil implementar varios niveles de blackhhole:

1. Completo
2. Fuera del país local (IXP local, clientes AS + enteros propios vistos)
3. Fuera del área local (si corresponde, como para mí podría ser 'nórdicos')
4. Incluir / excluir enrutador de emparejamiento específico en el agujero negro

Me complace dar un ejemplo de cómo implementar algo como esto con JNPR DCU / SCU, siempre que sus enrutadores pares sean JNPR, pero es posible con solo comunidades, un poco más incómodo.

Si desea limitar las opciones de sus clientes, puede agregar esto:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

De esta manera debería ser lógico AND. Pero realmente no veo el valor de crear complejidad para reducir la expresividad de la configuración.