BGP communities: cosa sono e come si usano per il traffic engineering

Una rotta BGP porta con sé più di una destinazione e un AS path. Porta anche delle etichette arbitrarie, le community, che non modificano di per sé il percorso ma dicono al router che le riceve come trattare quell'annuncio. Sono lo strumento con cui un operatore chiede al proprio transit provider di fare qualcosa senza aprire un ticket.

Formato e sintassi

Una community standard (RFC 1997) è un valore a 32 bit, scritto per convenzione come ASN:valore, dove i primi 16 bit contengono di norma l'AS che la definisce:

199920:100      # community definita da AS199920, significato locale
64496:666       # convenzione diffusa per il blackholing

Il limite dei 16 bit sul primo campo è diventato un problema con gli AS a 32 bit, che non entrano nel formato. Da qui due estensioni:

• large communities (RFC 8092): tre campi da 32 bit, ASN:funzione:parametro, ad esempio 199920:1000:174. Sono la soluzione corretta oggi e vanno preferite.
• extended communities (RFC 4360): 64 bit, usate soprattutto in ambito MPLS/VPN per i route target, meno per il traffic engineering internet.

Le well-known community

Quattro valori hanno significato universale e sono implementati da tutti i router:

NO_EXPORT è quella che si usa più spesso: serve ad annunciare a un provider un prefisso più specifico che serve solo a lui, senza inquinare la tabella globale con /24 aggiuntivi.

Community dei transit provider

Qui sta l'utilità pratica. Ogni operatore di transito pubblica un elenco di community che il cliente può applicare ai propri annunci per ottenere comportamenti specifici. Le famiglie ricorrenti sono tre.

Prepend selettivo. Invece di fare AS path prepending verso tutti, si chiede al provider di aggiungere uno, due o tre prepend solo verso un determinato AS o una determinata area geografica:

# esempio di convenzione tipica (i valori reali cambiano per provider)
<ASN_provider>:1<ASN_target>   # 1 prepend verso quell'AS
<ASN_provider>:2<ASN_target>   # 2 prepend

Serve quando un solo upstream attira troppo traffico in ingresso: si degrada l'annuncio verso quella direzione senza toccare le altre.

Controllo della propagazione. Community che dicono al provider di non annunciare il prefisso a un certo peer, a una certa regione o a nessun peer:

<ASN_provider>:0:<ASN_target>   # non annunciare a quell'AS
<ASN_provider>:0:0              # non annunciare a nessuno (solo clienti del provider)

Local preference remota. Alcuni provider permettono al cliente di alzare o abbassare la local preference assegnata alla rotta all'interno della loro rete, influenzando la scelta quando il cliente è multihomed sullo stesso operatore in punti diversi.

La documentazione di riferimento è sempre quella del singolo provider, tipicamente pubblicata nell'oggetto aut-num del RIPE o su una pagina dedicata. Non esiste uno standard: la stessa community ha significati diversi su reti diverse.

RTBH: blackholing con le community

Il Remotely Triggered Black Hole è il caso d'uso più critico. Sotto attacco DDoS volumetrico verso un singolo IP, l'obiettivo è far scartare quel traffico a monte, prima che saturi il proprio uplink.

Il meccanismo:

• si annuncia al transit provider un /32 (o /128 in IPv6) dell'IP bersaglio
• si tagga l'annuncio con la community di blackhole, standardizzata come 65535:666 (RFC 7999) oppure con il valore proprietario del provider
• il provider imposta il next-hop di quella rotta su un'interfaccia null e scarta il traffico ai propri bordi

Il costo è che l'IP bersaglio diventa irraggiungibile per tutti: si sacrifica un servizio per salvare la connettività dell'intera rete. È una misura d'emergenza, non una difesa. Va predisposta e testata prima di averne bisogno, perché durante un attacco non c'è tempo di leggere la documentazione.

Due precauzioni: il provider deve autorizzare esplicitamente l'accettazione di prefissi /32 dal cliente (normalmente i filtri li scartano) e i /32 di blackhole non devono mai essere propagati oltre — vanno taggati anche con NO_EXPORT.

Community interne

Le community non servono solo verso l'esterno. Dentro il proprio AS sono il modo pulito per marcare l'origine di ogni rotta e scriverne le policy una volta sola:

199920:1000    # rotta appresa da un cliente
199920:2000    # rotta appresa da un peer all'IX
199920:3000    # rotta appresa da un transit
199920:4000    # rotta originata dalla nostra rete

Con questa marcatura le export policy diventano dichiarative: verso un transit si annuncia solo 1000 e 4000, verso un peer all'internet exchange lo stesso, verso un cliente si annuncia tutto. Aggiungere un nuovo peer non richiede di riscrivere le liste di prefissi, ma solo di applicare il template corretto.

Su MikroTik le community si impostano nelle routing filter rules, su BIRD e FRR direttamente nei filtri di import ed export. In tutti i casi vale una regola: ripulire in ingresso. Le community del proprio ASN ricevute da un peer esterno vanno cancellate, altrimenti chiunque può iniettare tag che alterano le proprie policy interne.