Protocollo di gateway di confine
| Border Gateway Protocol | |
|---|---|
| Nome cinese | Protocollo di gateway di confine |
| Nome inglese | Border Gateway Protocol |
| Abbreviazione | BGP |
| Versione corrente | BGP-4 (RFC 4271, 2006) |
| Porta / Protocollo di trasporto | TCP 179 |
| Tipo di routing | Protocollo di gateway esterno (Exterior Gateway Protocol), protocollo path-vector |
| Funzione principale | Scambio di informazioni di raggiungibilità di rete tra sistemi autonomi (AS) |
| Organismo di standardizzazione | IETF |
Il Border Gateway Protocol (BGP, protocollo di gateway di confine) è il protocollo di routing fondamentale tra i sistemi autonomi (AS, Autonomous System) di Internet, la cui funzione principale è lo scambio automatico di informazioni di routing prive di loop tra i sistemi autonomi[1]. BGP è classificato come protocollo path-vector (protocollo a vettore di percorso); le sue decisioni di routing si basano su percorsi, politiche di rete o insiemi di regole configurate dall'amministratore, e non semplicemente sul numero di hop o sullo stato del collegamento[2]. BGP-4 supporta il Classless Inter-Domain Routing (CIDR) e fornisce meccanismi di aggregazione delle route; è lo standard de facto per il routing interdominio su Internet[1].
La progettazione di BGP deriva dalle limitazioni del precedente Exterior Gateway Protocol (EGP) di Internet, in particolare dalla sua restrizione della topologia inter-AS a una struttura ad albero e dalla perdita di aggiornamenti dovuta all'uso di un trasporto IP non affidabile[3].
- BGP-1: pubblicato per la prima volta nel giugno 1989 nell'RFC 1105, supportava un piccolo numero di route IPv4 classful, utilizzava TCP come trasporto affidabile per ridurre il flapping delle route e introduceva l'attributo AS_PATH per prevenire i loop di routing[4][3]. BGP è stato originariamente progettato da Yakov Rekhter e Kirk Lougheed durante la 12ª riunione IETF nel gennaio 1989, inizialmente come soluzione a breve termine, ma è diventato inaspettatamente uno dei pilastri di Internet[5].
- BGP-2: pubblicato nel 1990 nell'RFC 1163, introduceva un framework per trasportare attributi di percorso (come Origin, AS_PATH, Next_Hop) tramite codifica TLV, gettando le basi per le successive estensioni[3].
- BGP-3: pubblicato nel 1991 nell'RFC 1267, ha ulteriormente ottimizzato i meccanismi operativi di BGP-2[3][6].
La versione attualmente ampiamente implementata è BGP-4. La sua specifica iniziale è stata abbozzata nell'RFC 1654 nel 1994, poi pubblicata nell'RFC 1771 nel 1995, e lo standard finale è stato formalizzato nell'RFC 4271 nel 2006[1][2].
Il miglioramento chiave di BGP-4 rispetto alle versioni precedenti è il supporto per CIDR, che consente di aggregare più prefissi IP in un unico annuncio di route, riducendo notevolmente le dimensioni della tabella di routing di Internet[1]. Inoltre, BGP-4 ha ulteriormente migliorato la granularità del controllo delle politiche, supportando attributi di percorso più ricchi[7].
BGP opera su un protocollo di trasporto affidabile, utilizzando solitamente la porta TCP 179 per stabilire connessioni, evitando così la necessità di implementare complessi meccanismi di frammentazione, ritrasmissione e riconoscimento dei messaggi[4][2]. I peer BGP richiedono una configurazione manuale da parte dell'amministratore per stabilire la connessione.
I peer BGP interagiscono tramite i seguenti cinque tipi di messaggi[8][9]:
- OPEN: primo messaggio inviato dopo l'instaurazione della connessione TCP, utilizzato per negoziare parametri come versione BGP, numero AS, Hold Time, ecc.
- UPDATE: utilizzato per annunciare route raggiungibili (contenenti NLRI e attributi di percorso) o per ritirare route non raggiungibili.
- KEEPALIVE: inviato periodicamente per mantenere attiva la connessione e anche come riconoscimento del messaggio OPEN.
- NOTIFICATION: inviato quando viene rilevato un errore, dopodiché la connessione BGP viene chiusa.
- ROUTE-REFRESH (estensione opzionale): utilizzato per richiedere dinamicamente al peer di reinviare le informazioni di route.
BGP non si basa semplicemente sul distance vector, ma prende decisioni basandosi su un insieme di attributi di percorso (Path Attributes). Quando esistono più route verso la stessa destinazione, BGP avvia l'algoritmo di selezione del percorso ottimale (Decision Process)[7]. L'ordine tipico di selezione è il seguente[10][7]:
- Scarta le route con next-hop irraggiungibile;
- Preferisce la route con Weight (peso) più alto (attributo proprietario Cisco);
- Preferisce la route con Local Preference (preferenza locale) più alta;
- Preferisce le route generate localmente (es. iniettate tramite comando network);
- Preferisce la route con il percorso AS (AS_PATH) più breve;
- Preferisce la route con il tipo di origine più basso (IGP < EGP < Incomplete);
- Preferisce la route con il valore MED (Multi-Exit Discriminator) più basso;
- Preferisce le route apprese tramite eBGP rispetto a quelle iBGP;
- Preferisce la route con metrica IGP (Metric) più bassa verso il Next_Hop;
- Se ancora indistinguibili, utilizza il Router ID, la lunghezza della Cluster List e l'IP del peer come criteri di arbitraggio finali.
I router BGP mantengono logicamente più banche di informazioni di routing (Routing Information Bases)[1][11]:
- Adj-RIBs-In: memorizza le informazioni di route originali ricevute dai peer.
- Loc-RIB: le informazioni di route selezionate localmente dopo l'applicazione delle politiche di routing (come filtri in ingresso, modifica degli attributi e algoritmo del percorso ottimale).
- Adj-RIBs-Out: le route pronte per essere annunciate a un peer specifico, solitamente modificate da politiche in uscita.
BGP manca di meccanismi di verifica di sicurezza incorporati fin dalla progettazione. Un AS può annunciare prefissi IP che non gli appartengono, causando il dirottamento o l'intercettazione del traffico (prefix hijacking)[12]. Questo problema può essere dovuto a errori di configurazione dell'amministratore o ad attacchi malevoli, e le sue conseguenze sono spesso di vasta portata[13].
Per mitigare queste minacce alla sicurezza, l'industria ha sviluppato la Resource Public Key Infrastructure (RPKI) e la Route Origin Validation (ROV), che consentono ai proprietari di AS di autorizzare l'annuncio dei propri prefissi IP tramite certificati crittografici[14]. Inoltre, è stato proposto BGPsec (RFC 8205) per la protezione dell'integrità del percorso, al fine di fornire garanzie di sicurezza più complete[13], ma a causa della complessità di implementazione e dei costi, la sua adozione effettiva a livello globale rimane limitata[14].
Con l'evoluzione di Internet, le funzionalità originali di BGP-4 progettate per IPv4 unicast non sono più sufficienti a soddisfare le nuove esigenze, portando allo sviluppo delle estensioni multiprotocollo per BGP (MP-BGP, Multiprotocol Extensions for BGP-4, RFC 4760). MP-BGP introduce i campi Address Family Identifier (AFI) e Subsequent Address Family Identifier (SAFI), consentendo a BGP di trasportare informazioni di routing per vari protocolli di livello rete come IPv6 unicast, multicast, VPN di livello 3 (L3VPN) e servizi LAN virtuali privati[15][2].
- ↑ 1.0 1.1 1.2 1.3 1.4 Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
- ↑ 2.0 2.1 2.2 2.3 Border Gateway Protocol, EPFL Graph Search.
- ↑ 3.0 3.1 3.2 3.3 Rekhter, Y., "BGP at 18: Lessons in protocol design", Juniper Networks, 2007.
- ↑ 4.0 4.1 Lougheed, K., Rekhter, Y., "A Border Gateway Protocol (BGP)", RFC 1105, June 1989.
- ↑ What is BGP? A Pillar of the Modern Internet, Catchpoint, 2019.
- ↑ BGP技术介绍, 新华三集团.
- ↑ 7.0 7.1 7.2 BGP Path Selection and Route Preference, Cisco Systems, 2026.
- ↑ BGP路由技术, 阿里云开发者社区, 2023.
- ↑ Overview of BGP Messages, Juniper Networks.
- ↑ Route Selection, Juniper Networks.
- ↑ An Introduction to the Border Gateway Protocol (BGP) for Protocol Developers, IETF 119.
- ↑ Jiang, S., et al., "Route Origin Registry Problem Statement", IETF Internet-Draft, 2026.
- ↑ 13.0 13.1 Jaw, E., et al., "Serial BGP Hijackers: A Reproducibility Study and Assessment of Current Dynamics", RIPE Labs, 2024.
- ↑ 14.0 14.1 "Understanding stealthy BGP hijacking risk in the ROV era", APNIC Blog, 2025.
- ↑ Bates, T., et al., "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.