Filtre BGP à déclenchement à distance (RTBH) BGP pour Juniper

J'essaie de trouver le moyen le plus élégant d'implémenter un filtre RTBH pour les itinéraires reçus d'un client.

Le filtre doit:

1. Accepter uniquement les préfixes des clients à partir d'une liste de préfixes
2. Accepter uniquement / 32 préfixes
3. Seuls les préfixes avec la communauté blackhole
4. Définissez le tronçon suivant sur le tronçon suivant RTBH (192.0.2.1)

Pour commencer, j'ai regardé le document " Configuration des conditions de correspondance dans les conditions de la politique de routage " de Juniper.

J'ai d'abord pensé à combiner un prefix-list-filterpour ne faire correspondre que les itinéraires de la liste des préfixes clients et un route-filterpour limiter les préfixes acceptés à / 32, comme ceci:

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

Mais ensuite je suis tombé sur cette information dans le document:

Si vous configurez une stratégie qui inclut une combinaison de filtres de route, de listes de préfixes et de filtres d'adresse source, ils sont évalués selon une opération logique OU ou une recherche de correspondance de route la plus longue.

Si je comprends bien (et je trouve cela un peu flou), si j'utilise prefix-list-filter, route-filteret / ou source-address-filterdans le même terme, il serait évalué avec un OU le plus long entre tous, ce qui rend cette approche inutilisable .

Ce que j'ai trouvé, c'est le filtre suivant. Le hostroutes-onlyterme détourne tous les préfixes inférieurs à / 32 vers la stratégie suivante. Après cela, le prefixesterme correspond si le / 32 est à la portée du client, correspond à son chemin d'accès et a la communauté de trous noirs définie:

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

Alors, est-ce la façon la plus élégante de gérer cela? D'autres solutions?

Il n'y a aucune raison de limiter le client au trou noir uniquement / 32, de leur permettre de tout trou noir.

Quelque chose comme ça:

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

N'oubliez pas de définir «accept-remote-nexthop» sous les paramètres BGP, afin que le prochain saut puisse être changé en autre chose que l'adresse de liaison.

Je soutiens également fermement que les prestataires commencent à soutenir différentes communautés de trou noir que le «trou noir complet». Surtout si vous opérez dans plus d'un pays, l'attaque provient généralement du transit et, souvent, le client souhaite principalement accéder aux peerings nationaux, il est donc utile de mettre en œuvre plusieurs niveaux de trou noir:

1. Plein
2. En dehors du pays local (IXP local, propres clients AS + vus)
3. En dehors de la zone locale (le cas échéant, comme pour moi, il pourrait s'agir de «pays nordiques»)
4. Inclure / exclure un routeur d'appairage spécifique dans le trou noir

Je suis heureux de donner un exemple comment implémenter quelque chose comme ça avec JNPR DCU / SCU, à condition que vos routeurs d'appairage soient JNPR, mais c'est possible avec seulement des communautés, juste un peu plus gênantes.

Si vous voulez absolument limiter les options de votre client, vous pouvez ajouter ceci:

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 cette façon, il devrait être logique ET. Mais je ne vois vraiment pas l'intérêt de créer de la complexité pour réduire l'expressivité de la configuration.