Filtro BGP de buraco negro acionado remotamente (RTBH) para Juniper

Estou tentando encontrar a maneira mais elegante de implementar um filtro RTBH para rotas recebidas de um cliente.

O filtro deve:

1. Aceite apenas os prefixos dos clientes em uma lista de prefixos
2. Aceitar apenas / prefixos 32
3. Apenas prefixos com a comunidade blackhole
4. Defina o próximo salto para o próximo salto RTBH (192.0.2.1)

Para começar, consultei o documento " Configurando condições de correspondência nos termos da política de roteamento " da Juniper.

Primeiro, pensei em combinar um prefix-list-filterpara corresponder apenas a rotas da lista de prefixos de clientes e um route-filterpara limitar os prefixos aceitos a / 32, da seguinte forma:

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

Mas então me deparei com essa informação no documento:

Se você configurar uma política que inclua alguma combinação de filtros de rotas, listas de prefixos e filtros de endereços de origem, elas serão avaliadas de acordo com uma operação OR lógica ou com uma pesquisa de correspondência de rota mais longa.

Como eu entendo isso (e acho que é um pouco claro), se eu usar prefix-list-filter, route-filtere / ou source-address-filterno mesmo prazo, seria avaliado com um mais antigo jogo OR entre todos eles, o que torna esta abordagem inutilizável .

O que eu vim com esse filtro é o seguinte. O hostroutes-onlytermo desvia todos os prefixos menores que / 32 para a próxima política. Depois disso, o prefixestermo corresponde se o / 32 estiver no intervalo do cliente, corresponder ao seu caminho e tiver a comunidade blackhole definida:

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;
    }
}

Então, essa é a maneira mais elegante de lidar com isso? Alguma outra solução?

Não há razão para limitar o cliente apenas a blackhole / 32, permitir que eles usem qualquer coisa deles.

Algo assim:

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;
    }
}

Lembre-se de definir 'accept-remote-nexthop' nas configurações do BGP, para que o próximo salto possa ser alterado para algo diferente de endereço de link.

Também apoio fortemente que os provedores comecem a apoiar diferentes comunidades de buracos negros do que apenas 'buracos negros completos'. Especialmente se você opera em mais de um país, geralmente o ataque é de trânsito e, muitas vezes, o cliente realmente quer acessar pares domésticos, por isso é útil implementar vários níveis de buraco negro:

1. Cheio
2. Fora do país local (IXP local, clientes AS + completos vistos)
3. Fora da área local (se aplicável, como para mim poderia ser 'nórdico')
4. Incluir / excluir roteador de peering específico no buraco negro

Fico feliz em dar exemplo de como implementar algo assim com o JNPR DCU / SCU, desde que seus roteadores de peering sejam JNPR, mas isso é possível apenas com comunidades, um pouco mais estranho.

Se você deseja absolutamente limitar as opções de seus clientes, pode adicionar este:

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;
        }
..
}

Dessa forma, deve ser AND lógico. Mas eu realmente não vejo o valor em criar complexidade para reduzir a expressividade da configuração.