Come filtrare i prefissi non bogon ricevuti tramite BGP da un Internet Exchange (IXP)?

Quando si è connessi a uno scambio peering Internet (IXP), qual è un buon modo per assicurarsi che le persone non ti inviano prefissi che non dovrebbero annunciare?

Per quanto riguarda i bogon, sono a conoscenza del progetto di riferimento del Team Cymru Bogon Reference , ma quando si tratta di filtrare qualsiasi altra cosa dai colleghi non ho idea da dove cominciare. La mia comprensione è questo a cosa servono RPKI e simili?

Come hanno affermato gli altri, RPKI sarebbe la strada da percorrere, ma non è ancora lì. Ai punti di cambio generalmente poniamo un limite massimo di prefisso per ogni sessione.

Inoltre utilizziamo le seguenti regole:

1. Nessun percorso predefinito

2. Nessun problema, più esattamente questo elenco:

   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. Nessun prefisso più lungo di / 24

4. Nessun numero AS privato nel percorso

5. Nessuno dei nostri prefissi

Per IPv6 facciamo lo stesso, solo i bogon sono diversi. Ho incollato il nostro filtro sotto questo. Tieni presente che la sintassi potrebbe essere un po 'strana, ma ciò è dovuto al modo Juniper di abbinare i prefissi. Per la sintassi Cisco puoi andare qui: Consigli sul filtro BGP IPv6 (L'esempio Juniper nella pagina è difettoso, se lo desideri usa quello che segue).

termine ebgp-relaxed {
    a partire dal {
        famiglia inet6;
        route-filter 3ffe :: / 16 orlonger;
        filtro route 0000 :: / 8 o più lungo;
        route-filter 2001: db8 :: / 32 orlonger;
        route-filter 2001 :: / 32 esatto criterio successivo;
        route-filter 2001 :: / 32 più a lungo;
        route-filter 2002 :: / 16 esatto prossimo criterio;
        route-filter 2002 :: / 16 più a lungo;
        route-filter fe00 :: / 9 orlonger;
        route-filter ff00 :: / 8 orlonger;
        route-filter 2000 :: / 3 prefisso-lunghezza-intervallo / 49- / 128;
        route-filter 0 :: / 0 orlonger;
    }
    quindi respingere;
}

Al momento (fino a quando l'RPKI non sarà più diffuso), generalmente filtriamo solo i bogon comuni e applichiamo un filtro con prefisso massimo per scambiare i peer. Filtriamo anche alcuni ASN, quelli che siamo certi non verranno mai mostrati nella maggior parte delle sessioni di peering, come Level3 o Cogent, o non dovrebbero essere transitati su uno scambio.

Di solito troviamo che la maggior parte delle perdite di percorso comuni non sono comprese nell'intervallo 1-2 cifre. È molto difficile da catturare comunque, a meno che non si filtrino tutti i peer creando un prefisso / elenco ASN o filtrando per radb, ecc. La maggior parte delle perdite finisce per essere più vicina a 10k-100k +, che viene facilmente catturata da un valore abbastanza basso (100-500 ) filtro max prefisso. È quindi possibile regolare tale sessione per ogni necessità.

A seconda di come stai utilizzando lo scambio di peering, hai diverse opzioni:

In primo luogo tratterò RPKI e dirò che mentre è qualcosa che dovresti assolutamente andare avanti e distribuire, sia per i tuoi percorsi che per convalidare gli altri, è purtroppo in un uso così basso che non puoi aspettarti che faccia così tanto. La vera soluzione qui è WHOIS: il RaDB di merito è probabilmente il migliore in quanto ti consentirà di restituire risultati per tutti i RIR in una volta. Ma, se preferisci interrogare direttamente ogni RIR, provalo.

Ora, se sei in borsa e stai ricevendo un mucchio di prefissi dal server di route di IXP, a seconda degli strumenti che hai a tua disposizione e delle capacità del tuo router, hai due possibilità:

   1. Filtra per origine AS

In sostanza, ciò consiste nella convalida dell'origine AS di un prefisso rispetto a quello in WHOIS - se l'origine AS non corrisponde a quello in WHOIS, si rilascia il prefisso e qualsiasi altra specifica che potrebbe anche essere annunciata. Questa è generalmente una buona protezione contro i dirottamenti involontari. La stragrande maggioranza dei prefissi dovrebbe avere questi dati.

   2. Filtra per transito AS

Questo fa un ulteriore passo avanti e filtra le rotte con qualsiasi AS nel percorso che non è autorizzato all'interno di WHOIS, tuttavia non è possibile farlo per ogni prefisso, poiché non tutti avranno creato oggetti specificando chi sono i loro provider di AS autorizzati per il transito.

D'altra parte, se stai usando lo scambio di peering per scrutare direttamente con gli altri, la tua vita diventa molto più semplice; puoi cercare quali prefissi hanno in WHOIS e permetterli. La buona pratica a mio avviso è quella di consentire ai peer di annunciare più specifici fino a una lunghezza massima di / 24, impostando al contempo un valore di prefisso massimo sensibile (ovvero proporzionale al numero di sottoreti che hanno) sul peering in modo che possano " Ti inondano di percorsi ma possono rispondere a un dirottamento del prefisso.

Se stai cercando strumenti, controlla IRRToolSet e IRR PowerTools

In pratica hai risposto alla tua domanda. Il tuo presupposto che l'uso di RPKI sia la strada da percorrere è assolutamente corretto. Più specificamente, le autorizzazioni di origine del percorso vengono utilizzate per convalidare un prefisso in un AS. Ovviamente i bogon non saranno validi perché non sono assegnati a nessuno, quindi quel problema si occuperà di se stesso. Molte di queste informazioni sono disponibili sulla pagina Wikipedia di RPKI . Un'altra buona risorsa è la pagina RPKI di ARIN .

Se hai bisogno di aiuto per la configurazione ti suggerisco di creare un'altra domanda chiedendo aiuto specifico per la configurazione.

Vale anche la pena notare che RPKI non funzionerà per tutto, perché non tutti lo usano. Ad un certo punto devi solo fidarti dei percorsi che stai ricevendo.

Chiedi ai tuoi colleghi quale macro AS annunceranno e costruisci filtri per loro usando IRRToolSet o rpsltool o irrpt. Incoraggiali a pubblicare le informazioni corrette in un IRRdb. Non dimenticare di aggiornare il tuo aut-numoggetto nell'IRRdb amico più vicino per riflettere l'adiacenza.

RPKI non è la strada da percorrere in quanto non protegge dalle perdite di rotta.