Filtro BGP blackhole attivato da remoto (RTBH) per Juniper

Sto cercando di trovare il modo più elegante per implementare un filtro RTBH per i percorsi ricevuti da un cliente.

Il filtro dovrebbe:

1. Accetta solo i prefissi dei clienti da un elenco di prefissi
2. Accetta solo / 32 prefissi
3. Solo prefissi con la comunità blackhole
4. Imposta l'hop successivo sull'hop successivo RTBH (192.0.2.1)

Per iniziare, ho esaminato il documento " Configurazione delle condizioni di corrispondenza nei termini della politica di routing " di Juniper.

Per prima cosa ho pensato di combinare a prefix-list-filterper abbinare solo le rotte dall'elenco dei prefissi dei clienti e a route-filterper limitare i prefissi accettati a / 32, in questo modo:

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

Ma poi mi sono imbattuto in queste informazioni nel documento:

Se si configura un criterio che include una combinazione di filtri di route, elenchi di prefissi e filtri di indirizzi di origine, questi vengono valutati in base a un'operazione OR logica o una ricerca di corrispondenza di route più lunga.

Da quanto ho capito (e lo trovo un po 'poco chiaro), se lo uso prefix-list-filter, route-filtere / o source-address-filternello stesso termine, sarebbe valutato con una corrispondenza più lunga OR tra tutti, il che rende questo approccio inutilizzabile .

Quello che mi è venuto in mente è questo il seguente filtro. Il hostroutes-onlytermine devia tutti i prefissi più brevi di / 32 alla politica successiva. Dopodiché il prefixestermine corrisponde se il / 32 è compreso nell'intervallo del cliente, corrisponde al suo percorso e ha la comunità blackhole impostata:

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

Quindi, è questo il modo più elegante per gestirlo? Qualche altra soluzione?

Non vi è alcun motivo per limitare il cliente al solo blackhole / 32, consentire loro di blackhole qualsiasi cosa da loro.

Qualcosa come questo:

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

Ricorda di impostare "accept-remote-nexthop" nelle impostazioni BGP, in modo che l'hop successivo possa essere cambiato in qualcosa di diverso dall'indirizzo di collegamento.

Sostengo anche con forza che i fornitori inizino a supportare diverse comunità di blackhole rispetto a un semplice "blackhole completo". Soprattutto se si opera in più di un Paese, di solito l'attacco proviene dal transito e spesso il cliente desidera accedere principalmente a peerings domestici, quindi è utile implementare diversi livelli di blackhhole:

1. Pieno
2. Al di fuori del paese locale (IXP locale, clienti AS + interi visti)
3. Fuori dall'area locale (se applicabile, come per me potrebbe essere "Nordics")
4. Includi / Escludi router di peering specifico nel blackhole

Sono felice di fare un esempio su come implementare qualcosa di simile con JNPR DCU / SCU, a condizione che i router di peering siano JNPR, ma è possibile solo con le community, un po 'più imbarazzanti.

Se vuoi assolutamente limitare le opzioni dei tuoi clienti puoi aggiungere questo:

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

In questo modo dovrebbe essere logico AND. Ma non vedo davvero il valore nel creare complessità per ridurre l'espressività della configurazione.