La sicurezza su Internet passa anche per l’igiene negli instradamenti. A questo scopo esiste il programma MANRS (Mutually Agreed Norms for Routing Security), nato da ISOC (Internet Society) e oggi sostenuto da GCA (Global Cyber Alliance). Il software ROSE-T si pone proprio lo scopo di aiutare gli operatori a raggiungere la conformità con le azioni MANRS automatizzando alcuni passaggi e, soprattutto, consentendo un self-assessment sui requisiti e sui test.

INTRODUZIONE A BGP

BGP (Border Gateway Protocol) nasce nel 1989 come protocollo per lo scambio di informazioni di routing tra diversi Sistemi Autonomi (AS). Questo è il motivo per cui rientra nella definizione di Exterior Gateway Protocol (EGP). È lo standard su cui si basa la moderna Internet ed è operativo dal marzo 1995. Tra le peculiarità essenziali di BGP vale la pena menzionare “fiducia e volontarietà”. BGP, così come è stato inizialmente concepito, confida nel fatto che gli operatori di rete si interconnettono volontariamente riponendo fiducia reciproca (cosa che in seguito ha portato alla creazione di ulteriori protocolli di sicurezza).

INSTRADAMENTO

Le informazioni sul percorso possono essere espresse nella forma tipica della modalità CIDR, cioè IP/prefix_length, e sono chiamate “Prefissi IP” o “Reti”. Queste reti appartengono a blocchi numerici (IPv4 o IPv6) che IANA distribuisce ai cinque RIR che, a loro volta, assegnano a LIR/NIR. Quest’ultimo, infine, effettua le assegnazioni agli utenti. In ogni caso, questi sono gli elementi costitutivi della Full Internet Routing Table (FIRT), una tabella che può essere appresa da ciascun AS di Internet sfruttando le sessioni BGP inter-AS e che garantisce la raggiungibilità di qualsiasi dispositivo con un indirizzo univoco. Ogni sistema autonomo comunica agli altri AS, con i quali mantiene sessioni BGP, le proprie risorse IP ed, eventualmente, quelle dei propri clienti (nel caso fornisca loro un servizio di transito) In questo modo tutte le informazioni sui percorsi vengono propagate a tutti gli AS che poi utilizzeranno un metodo di selezione per eleggere il cosiddetto percorso migliore verso una specifica destinazione.

POLITICHE DI INSTRADAMENTO

Una politica di instradamento (routing policy) definisce le regole adottate da un AS per la gestione del traffico in entrata e in uscita e le regole per l’accettazione e l’invio di annunci BGP. L’implementazione pratica delle politiche di instradamento richiede configurazioni complesse che utilizzano strumenti specifici messi a disposizione dalle implementazioni BGP dei vari produttori. Questi includono certamente i filtri. Infatti, le attività di filtraggio della tabella BGP, prima che i suoi elementi vengano installati nella tabella di routing, richiedono la conoscenza di alcuni principi generali e di alcune tecniche particolari. È utile ribadire la distinzione tra due ambiti: traffico in entrata (inbound) e traffico in uscita. Esistono in realtà due prospettive diverse: da un lato (inbound) gli annunci che un sistema autonomo comunica ai suoi vicini, dall’altro (outbound) gli annunci che riceve da altri AS. L’entrata è influenzata dagli annunci fatti da un AS; in uscita è influenzato dagli annunci pubblicitari che riceve.

SICUREZZA DEL PERCORSO

Poiché Internet è passata da una rete a uso limitato, in un ambiente ritenuto “affidabile”, a una con forti motivazioni commerciali, negli ultimi anni si è reso necessario studiare e implementare misure di sicurezza per il protocollo BGP. Lo standard originale non includeva funzionalità di sicurezza. Nel corso degli anni sono stati introdotti alcuni meccanismi operativi, come il filtraggio dei prefissi, che, pur non essendo introdotti come funzionalità di sicurezza, possono comunque essere considerati strumenti che aiutano a costruire un’architettura sicura per BGP.

È utile sottolineare che le spiegazioni qui fornite riguardano sessioni eBGP, sebbene in teoria siano applicabili anche alle sessioni iBGP. Infatti, è solo nelle sessioni eBGP che la controparte va considerata, dal punto di vista della sicurezza, “inaffidabile”, poiché amministrata da un soggetto diverso.

Molti incidenti in Internet sono causati dalla diffusione di informazioni di routing errate. Le minacce più comuni, come il dirottamento dei prefissi o le perdite di percorsi, sfruttano una vulnerabilità sottostante nel protocollo BGP, vale a dire l’incapacità di verificare se gli AS che propagano gli annunci pubblicitari sono effettivamente legittimati a farlo. Le informazioni sulla proprietà delle risorse Internet (ASN e prefissi) non risiedono all’interno del protocollo ma sono contenute nei database pubblici (gli IRR), gestiti e mantenuti dai registri Internet regionali e aggiornati dagli utenti. È quindi necessario attivare processi di verifica di cosa riceve un AS, meccanismi out-of-band che aiutino il BGP a verificare la correttezza delle informazioni di raggiungibilità ricevute dai vicini.

Al di là degli aspetti più tecnici legati al protocollo, la storia di Internet ci ha insegnato che una più stretta collaborazione tra i partecipanti all’ecosistema e una responsabilità condivisa sono le basi su cui si fonda la crescita e il successo di Internet. Quindi, mentre è necessario attivare meccanismi di controllo per salvaguardare la corretta raggiungibilità delle destinazioni su Internet, un AS deve anche condividere le proprie informazioni di raggiungibilità ed evitare di generare incidenti di routing nell’ecosistema: i problemi di routing di un singolo operatore potrebbero riversarsi sugli altri.

MUTUALLY AGREED NORMS FOR ROUTING SECURITY

Nel corso degli anni, diverse iniziative si sono occupate di raccogliere le migliori pratiche nell’area della sicurezza del routing e molto è stato fatto in termini di promozione di una cultura di responsabilità collettiva verso la sicurezza stessa dell’ecosistema. Tra le varie iniziative vale la pena segnalarne una, forse la più importante ad oggi, e cioè le MANRS (Mutually Agreed Norms for Routing Security). Promossa e sostenuta dalla Internet Society, è un’iniziativa globale che fornisce una soluzione efficace per la riduzione e la mitigazione delle principali minacce al routing.

MANRS è in costante aggiornamento, seguendo l’evoluzione dei meccanismi di difesa dalle più comuni minacce di routing, ed è quindi una guida per tutti coloro che desiderano migliorare e mantenere aggiornato il livello di sicurezza della propria infrastruttura.

Prevede diversi programmi in base al tipo di rete e alle attività svolte nell’ecosistema. Le azioni suggerite riguardano i punti di scambio Internet, i fornitori di contenuti, nonché le reti di distribuzione dei contenuti, i venditori e soprattutto gli operatori di rete. L’idea di base è:

  • sensibilizzare sui problemi di sicurezza del routing e incoraggiare l’attuazione di azioni in grado di affrontarli;
  • promuovere una cultura di responsabilità collettiva nei confronti della sicurezza;
  • fornire un quadro che consenta agli operatori di comprendere e affrontare meglio i problemi.

MANRS specifica una serie di azioni importanti che mirano ad affrontare essenzialmente tre tipologie di problemi:

  • informazioni di raggiungibilità errate;
  • traffico con indirizzi IP di origine falsificati;
  • coordinamento e collaborazione tra gli operatori.

Ed ecco infine le quattro azioni definite dall’iniziativa.

1. Facilitare il coordinamento e la collaborazione con altri operatori: le informazioni di contatto (come e-mail e numeri di telefono NOC) all’interno degli IRR e del peeringDB dovrebbero essere mantenute aggiornate.

2. Documentare pubblicamente le proprie informazioni di routing: per facilitare il filtraggio ai vicini BGP è necessario specificare quali sono le informazioni di raggiungibilità sia all’interno degli IRR (tramite oggetti route e route6) che nella lista dei downstream (nell’oggetto as-set ) e per creare ROA per i prefissi.

3. Blocco del traffico proveniente da indirizzi IP falsificati: un operatore dovrebbe implementare un sistema che consenta la convalida dell’indirizzo di origine per la propria rete e i propri clienti. È poi necessario includere filtri anti-spoofing per evitare che pacchetti con un indirizzo IP di origine errato entrino o escano dalla rete.

4. Prevenire la propagazione di informazioni di instradamento errate: è necessario implementare un sistema in base al quale un operatore annuncia alle reti adiacenti solo ed esclusivamente i propri prefissi e quelli dei propri clienti. Allo stesso modo, l’operatore deve verificare che i prefissi annunciati dai propri clienti siano realmente i propri.

BGP E SISTEMI AUTONOMI

Le relazioni tra sistemi autonomi sono solitamente di tre tipi: fornitore-cliente, cliente-fornitore, peer. È molto comune che un AS abbia relazioni con più AS contemporaneamente.

Pertanto, un AS può avere relazioni di peering (spesso molte o moltissime), avere contemporaneamente due o più relazioni di transito (cioè due o più fornitori) e, in alcuni casi, avere un numero variabile di clienti. Per poter verificare la configurazione è necessario innanzitutto capire, per ogni sessione BGP presente, quale è la relazione tra i due AS coinvolti.

  1. Fornitore-cliente: il sistema autonomo AS1 (fornitore) annuncia i prefissi di ogni sistema autonomo conosciuto al sistema autonomo AS2 (cliente). Per ogni prefisso IP p annunciato da tutti gli altri AS su Internet, FIRT, c’è almeno un percorso nella tabella di instradamento T1 di AS1 che porta a quel prefisso IP, e un altro percorso nella tabella di instradamento T2 di AS2 che porta ad AS1.
    ∀p ∈ FIRT ​: ∃ rp,1 ​∈ T1 ​∧ ∃ rp,2 ​∈ T2
  2. Cliente-fornitore: il sistema autonomo AS2 (cliente) annuncia i propri prefissi e i prefissi appartenenti ai propri clienti. Per ogni prefisso IP p annunciato da AS2 e dai suoi clienti, (AS2_SET) c’è almeno un percorso nella tabella di instradamento T2 di AS2 che porta a quel prefisso IP, e un altro percorso nella tabella di instradamento T1 di AS1 che porta ad AS2.
    ∀p ∈ AS2_SET ​: ∃ rp,2 ​∈ T2 ​∧ ∃ rp,1 ​∈ T1
  3. Peer: consideriamo che AS1 e AS2 siano due sistemi autonomi che parlano BGP tra loro. Per ogni prefisso IP p annunciato da AS1 e dai suoi clienti (AS1_SET) esiste almeno un percorso verso p presente nella tabella di instradamento di AS2. Allo stesso modo, per ogni prefisso IP q annunciato da AS2 e dai suoi clienti (AS2_SET) esiste almeno un percorso verso q presente nella tabella di routing di AS1.
    ∀p ∈ AS1_SET : ∃ rp,2 ​∈ T2
​∀q ∈ AS2_SET ​: ∃ rq,1 ​∈ T1

VERIFICA FORMALE

Innanzitutto è necessario esaminare la politica di instradamento dichiarata da un sistema autonomo nel database di un IRR. A esempio, questa è la politica di routing dichiarata (tramite RPSLng) da AS59715 al database RIPE:

mp-import: afi ipv4.unicast from AS12874 accept any
mp-import: afi ipv6.unicast from AS12874 accept any
mp-import: afi ipv4.unicast from AS6762 accept any
mp-import: afi ipv6.unicast from AS6762 accept any
mp-import: afi ipv4.unicast from AS112 accept AS112
mp-import: afi ipv6.unicast from AS112 accept AS112
mp-export: afi ipv4.unicast to AS12874 announce AS-SBTAP
mp-export: afi ipv6.unicast to AS12874 announce AS-SBTAP
mp-export: afi ipv4.unicast to AS6762 announce AS-SBTAP
mp-export: afi ipv6.unicast to AS6762 announce AS-SBTAP
mp-export: afi ipv4.unicast to AS112 announce any
mp-export: afi ipv6.unicast to AS112 announce any

Leggiamo due famiglie di indirizzi, IPv4 e IPv6; per ciascuno, nella direzione dell’importazione, ci sono due fornitori (cioè AS con rapporto di transito): AS6762 e AS12874 dai quali AS59715 accetta qualunque annuncio conosca (accetta tutto). Nella direzione dell’esportazione, invece, AS59715 comunica ai due fornitori solo il proprio AS-SET (cioè i propri prefissi e quelli dei propri clienti, se presenti). Notiamo poi una terza relazione con AS112 da cui AS59715 accetta solo i prefissi di AS112 e al quale invece annuncia tutto quello che sa. Si può dire che AS59715 dia transito a AS112 per entrambe le famiglie di indirizzi.

Ora dal database RIPE è possibile estrarre i prefissi che hanno origine da AS59715:

185.5.200.0/22
185.5.200.0/23
185.5.202.0/24
185.5.203.0/24
2a02:cdc0::/29
2a02:cdc6:3074::/48
2a02:cdc6:3100::/48

Stessa estrazione per AS112:

192.175.48.0/24
2620:4f:8000::/48

Un rapido sguardo al set AS AS-SBTAP: è composto di soli due membri, AS59715 e AS112, quindi non è necessario continuare la ricerca nel database. Ciò che resta da fare ora è verificare se quanto affermato corrisponde alla realtà di Internet.

Prendiamo il punto di vista del progetto RouteViews BGP Route Viewer ed estraiamo tutte le informazioni su AS59715 per la famiglia di indirizzi IPv4:

Network 185.5.200.0/23
Path 6939 6762 59715
Path 8283 6762 59715 i
Path 3267 1299 6762 59715 i
Path 3333 6762 59715 i
Path 1351 6939 6762 59715 i
Path 7018 6762 59715 i
Path 3356 6762 59715 i
Path 20912 3257 6762 59715 i
Path 19214 3257 6762 59715 i
Path 3549 3356 6762 59715 i
Path 2497 2914 6762 59715 i
Path 3303 6762 59715 i
Path 4901 6079 3257 6762 59715 i
Path 101 3356 6762 59715 i
Path 49788 1299 6762 59715 i
Path 852 3356 6762 59715 i
Path 3561 209 3356 6762 59715 i
Path 57866 6830 6762 59715 i
Path 20130 6939 6762 59715 i
Path 3257 6762 59715 i
Path 6939 6762 59715 i

Network 185.5.200.0/22
Path 8283 6762 59715 i
Path 3267 1299 12874 59715 i
Path 3333 6762 59715 i
Path 7018 6762 59715 i
Path 20912 12874 59715 i
Path 49788 12552 3303 12874 59715
Path 3549 3356 12874 59715 i
Path 19214 174 6762 59715 i
Path 6939 6762 59715 i
Path 20130 6939 6762 59715 i
Path 3356 12874 59715 i
Path 852 3303 12874 59715 i
Path 57866 6830 6762 59715 i
Path 101 11164 3303 12874 59715 i
Path 1351 6939 6762 59715 i
Path 4901 6079 3303 12874 59715 i
Path 3257 3356 12874 59715 i
Path 3561 3910 3356 12874 59715 i
Path 2497 3356 12874 59715 i
Path 3303 12874 59715 i

Network 185.5.202.0/24
Path 8283 1299 12874 59715 i
Path 3267 1299 12874 59715 i
Path 3333 3303 12874 59715 i
Path 7018 3356 12874 59715 i
Path 20912 12874 59715 i
Path 49788 12552 3303 12874 59715
Path 3549 3356 12874 59715 i
Path 6939 12874 59715 i
Path 20130 6939 12874 59715 i
Path 3356 12874 59715 i
Path 852 3303 12874 59715 i
Path 57866 3356 12874 59715 i
Path 1351 6939 12874 59715 i§
Path 101 11164 3303 12874 59715 i
Path 4901 6079 3303 12874 59715 i
Path 3257 3356 12874 59715 i
Path 3561 3910 3356 12874 59715 i
Path 2497 3356 12874 59715 i
Path 3303 12874 59715 i

Network 185.5.203.0/24
Path 8283 6762 59715 i
Path 3267 1299 6762 59715 i
Path 3333 6762 59715 i
Path 1351 6939 6762 59715 i
Path 7018 6762 59715 i
Path 3356 6762 59715 i
Path 20912 3257 6762 59715 i
Path 3549 3356 6762 59715 i
Path 2497 2914 6762 59715 i
Path 3303 6762 59715 i
Path 4901 6079 3257 6762 59715 i
Path 101 3356 6762 59715 i
Path 49788 1299 6762 59715 i
Path 852 3356 6762 59715 i
Path 3561 209 3356 6762 59715 i
Path 57866 6830 6762 59715 i
Path 20130 6939 6762 59715 i
Path 3257 6762 59715 i
Path 6939 6762 59715 i

Ora, se le affermazioni fatte da AS59715 al database RIPE sono vere, allora anche dal punto di vista di RouteViews dovrebbero risultare solo due transiti, e in particolare AS6762 e AS12874.

STRUMENTO DI VERIFICA

Il nostro scopo (sono coinvolti anche i ricercatori italiani Mariano Scazzariello e Tommaso Caiazzi) è verificare la configurazione del router di un AS candidato alla conformità MANRS in modo che dimostri di soddisfare le quattro azioni richieste. Di conseguenza, abbiamo analizzato la ricerca inerente alla verificabilità della configurazione e testato alcuni strumenti già disponibili nell’arena open source. La nostra attenzione è stata attirata da Batfish, uno strumento che “trova errori e garantisce la correttezza delle configurazioni di rete pianificate o attuali. Consente un’evoluzione rapida e sicura della rete, senza il timore di interruzioni o violazioni della sicurezza”.

Purtroppo alcune limitazioni a oggi non ne consentono l’utilizzo per scenari complessi perché, a esempio, non copre alcune funzionalità diffuse delle configurazioni dei router BGP. La limitazione bloccante per noi è la mancanza di supporto per IPv6.

Ritenendo poco pratico estendere quel software senza un team di sviluppo, è stato necessario guardare altrove e cambiare il paradigma. Cioè, invece di limitarci a verificare la configurazione da un punto di vista formale, abbiamo pensato di emulare la configurazione in un ambiente controllato. Ci è venuto in soccorso il progetto katharà, “un sistema di emulazione di rete open source basato su container per mostrare demo/lezioni interattive, testare reti di produzione in un ambiente sandbox o sviluppare nuovi protocolli di rete”.

Ciò ci consente di creare router, caricare configurazioni MANRS candidate e preparare lo scenario appropriato per verificare le azioni necessarie. In particolare due azioni, la 3 e la 4, e cioè: anti-spoofing e filtri sui client.

AZIONE MANRS 3

Iniziamo verificando se il candidato rispetta le regole anti-spoofing. Quindi per prima cosa prendiamo la configurazione del router del candidato e la diamo in pasto a Batfish, che restituisce le relazioni con altri sistemi autonomi tramite BGP.

Quindi incrociamo questi dati con ciò che il candidato ha dichiarato nei database IRR. Se i dati non sono coerenti, restituiamo avvisi e spiegazioni sulle azioni necessarie per correggerli.

Se i dati sono coerenti, carichiamo la configurazione in un contenitore gestito da kathará.

A questo punto creiamo, attraverso qualche automazione, uno scenario all’interno di kathará che emula una piccola Internet. In altre parole, kathará può creare tanti router quanti sono i sistemi autonomi che intrattengono rapporti con il candidato, siano essi di transito, di peering o di clienti. Tali router emulati da kathará sono basati sul software FRR e vengono configurati automaticamente in base alla configurazione del candidato. Per testare le regole anti-spoofing viene impostata questa procedura: dalle reti appartenenti al candidato viene estratto un indirizzo IP casuale (IPv4 e IPv6) che viene assegnato a un client linux emulato su kathará. Viene quindi attivato un comando ping nel client per trasmettere pacchetti ICMP che hanno un IP falsificato come origine e come destinazione hanno un IP di un altro client Linux. Su quest’ultimo computer è in esecuzione un tcpdump che segnalerà l’arrivo dei pacchetti ICMP.

Quindi se il pacchetto sorgente spoofing arriva a destinazione, significa che o non ci sono regole anti-spoofing nella configurazione candidata o, se ci sono, non funzionano. In caso contrario, invece, il candidato risulterà conforme all’azione 3 MANRS.

AZIONE MANRS 4

L’altra verifica da fare riguarda i filtri per le reti annunciate dai clienti del candidato. Cioè, il candidato deve assicurarsi di accettare solo le reti che i suoi clienti sono autorizzati ad annunciare. Per effettuare tale verifica è necessario innanzitutto verificare nei database IRR le politiche di instradamento dichiarate dai vari soggetti coinvolti nella configurazione appartenente al candidato. Poi su kathará si crea uno scenario capace di emulare la relazione che esiste tra il sistema autonomo del candidato e i suoi clienti.

A questo punto da uno dei router dei client (che ricordiamo sono emulati tramite FRR) si tenta di annunciare una rete estranea e osservare se quella rete è passata, ad esempio, al transito del candidato o ai suoi peer (anch’essi emulati su kathará).

Se passa la rete estera allora vuol dire che il candidato non si è dato regole efficaci; in caso contrario, il candidato è conforme all’azione 4 di MANRS.

SORGENTI DATI AFFIDABILI

Determinare una sorgente di dati affidabile è questione alquanto delicata poiché ne va della veridicità degli esiti di qualunque verifica. Per questo motivo abbiamo selezionato le collezioni dell’Università dello Stato dell’Oregon, USA, che nell’ambito del progetto Route Views raccoglie da oltre vent’anni le tabelle BGP da sistemi autonomi provenienti da tutto il mondo. Gli archivi vengono popolati con snapshot della tabella BGP di un route collector effettuati ogni due ore, dunque, per le operazioni di verifica sull’AS candidato, usiamo il file più recente disponibile, a esempio rib.20231009.1400.bz2

Una volta scaricato – al momento gli snapshot sono di circa 100 MB ciascuno – lo elaboriamo con uno strumento capace di estrarre velocemente dati sugli AS_PATH di interesse per il candidato. Lo strumento è bgpgrep afferente alla Micro BGP Suite programmata dallo studioso italiano Lorenzo Cogotti.

Ecco un caso d’uso che mette sotto esame il candidato AS59715:

./bgpgrep ./rib.20231009.1400.bz2 -aspath "59715$" > 59715.bgp

Il comando estrae tutti gli AS_PATH, che terminano per 59715, presenti nello snapshot di uno dei collector eseguito il 9 ottobre 2023 alle ore 14:00.

Di seguito l’output del comando:

=|185.5.200.0/22|37100 3303 12874 59715|105.16.0.247|i|||NO_EXPORT|105.16.0.247 37100|1696730621|1

=|185.5.200.0/22|3549 3356 12874 59715|208.51.134.255|i|||3356:2 3356:22 3356:100 3356:123 3356:505 3356:901 3356:2074 3549:2018 3549:30840 12874:700 12874:3454|208.51.134.255 3549|1696459515|1

=|185.5.200.0/22|2914 6762 59715|129.250.1.71|i|||2914:420 2914:1005 2914:2000 2914:3000 6762:1 6762:92 6762:13980|129.250.1.71 2914|1696458965|1
=|185.5.200.0/22|3303 12874 59715|217.192.89.50|i|||3303:1000 3303:1007 3303:1020 3303:3071 12874:700 12874:1011 12874:3454|217.192.89.50 3303|1696553609|1
=|185.5.200.0/22|49788 12552 3303 12874 59715|91.218.184.60|i|||12552:12000 12552:12100 12552:12101 12552:22000|91.218.184.60 49788|1696591876|1
=|185.5.200.0/22|3130 1239 6762 59715|147.28.7.2|i|||1239:321 1239:1000 1239:1006|147.28.7.2 3130|1696375295|1
=|185.5.200.0/22|7660 2516 6762 59715|203.181.248.195|i|||2516:1030 7660:9001|203.181.248.195 7660|1696342689|1
=|185.5.200.0/22|7018 6762 59715|12.0.1.63|i|||7018:5000 7018:37232|12.0.1.63 7018|1696008116|1
=|185.5.200.0/22|20912 12874 59715|212.66.96.126|i|||20912:65016|212.66.96.126 20912|1696421519|1
=|185.5.200.0/22|3561 209 3356 12874 59715|206.24.210.80|i||||206.24.210.80 3561|1696419810|1
=|185.5.200.0/22|3549 3356 12874 59715|208.51.134.246|i|||3356:2 3356:22 3356:100 3356:123 3356:505 3356:901 3356:2074 3549:2352 3549:31826 12874:700 12874:3454|208.51.134.246 3549|1696419768|1
=|185.5.200.0/22|5413 3303 12874 59715|194.153.0.253|i||||194.153.0.253 5413|1696419788|1
=|185.5.200.0/22|34224 12874 59715|94.156.252.18|i|||34224:333 34224:334 34224:2040|94.156.252.18 34224|1696780769|1
=|185.5.200.0/22|3257 3356 12874 59715|89.149.178.10|i|||3257:8794 3257:30043 3257:50001 3257:54900 3257:54901|89.149.178.10 3257|1696593716|1
=|185.5.200.0/22|11686 6461 6762 59715|96.4.0.55|i|||11686:121|96.4.0.55 11686|1696811668|1
=|185.5.200.0/22|1403 6461 6762 59715|198.58.198.252|i|||1403:6461|198.58.198.252 1403|1695500156|1
=|185.5.200.0/22|8492 57304 12874 59715|85.114.0.217|i|||8492:1101 8492:1601|85.114.0.217 8492|1696419763|1
=|185.5.200.0/22|23673 55329 6939 12874 59715|203.189.128.233|i||||203.189.128.233 23673|1696419782|1
=|185.5.200.0/22|18106 6939 12874 59715|202.73.40.45|i|||6939:2000|202.73.40.45 18106|1696419763|1
=|185.5.200.0/22|1299 12874 59715|62.115.128.137|i||||62.115.128.137 1299|1696780726|1
=|185.5.200.0/22|22652 3303 12874 59715|45.61.0.85|i|||3303:1000 3303:1007 3303:1020 3303:3071 12874:700 12874:1011 12874:3454|45.61.0.85 22652|1696419763|1
=|185.5.200.0/22|57866 6830 6762 59715|37.139.139.17|i|||6762:1 6762:92 6762:13980 6830:17000 6830:17413 6830:23001 6830:33104 57866:100 65100:6830 65103:2 65104:31 57866:100:6830 57866:101:100 57866:103:2 57866:104:31|37.139.139.17 57866|1695858540|1
=|185.5.200.0/22|3741 12874 59715|168.209.255.56|i||||168.209.255.56 3741|1696419771|1
=|185.5.200.0/22|2152 11164 3303 12874 59715|137.164.16.84|i|||2152:65299 2152:65511 3303:1000 3303:1007 3303:1020 3303:3071 11164:1170 11164:7880 11164:7890 12874:700 12874:1011 12874:3454|137.164.16.84 2152|1696419769|1
=|185.5.200.0/22|293 3356 12874 59715|198.129.33.85|i||||198.129.33.85 293|1696419788|1
=|185.5.200.0/22|6939 6762 59715|64.71.137.241|i||||64.71.137.241 6939|1695144510|1
=|185.5.200.0/22|2497 3356 12874 59715|202.232.0.3|i||||202.232.0.3 2497|1696780731|1
=|185.5.200.0/22|20130 6939 6762 59715|140.192.8.16|i||||140.192.8.16 20130|1695144510|1
=|185.5.200.0/23|37100 6762 59715|105.16.0.247|i|||NO_EXPORT|105.16.0.247 37100|1696730618|1
=|185.5.200.0/23|2914 6762 59715|129.250.1.71|i|||2914:420 2914:1005 2914:2000 2914:3000 6762:1 6762:92 6762:13980|129.250.1.71 2914|1696458965|1
=|185.5.200.0/23|3549 3356 6762 59715|208.51.134.255|i|||3356:3 3356:22 3356:86 3356:575 3356:666 3356:901 3356:2011 3549:2018 3549:30840 6762:1 6762:92 6762:13980|208.51.134.255 3549|1696458817|1
=|185.5.200.0/23|3130 1239 6762 59715|147.28.7.2|i|||1239:321 1239:1000 1239:1006|147.28.7.2 3130|1696375295|1
=|185.5.200.0/23|49788 1299 6762 59715|91.218.184.60|i|||1299:20000|91.218.184.60 49788|1696213672|1
=|185.5.200.0/23|7660 2516 6762 59715|203.181.248.195|i|||2516:1030 7660:9001|203.181.248.195 7660|1696342689|1
=|185.5.200.0/23|7018 6762 59715|12.0.1.63|i|||7018:5000 7018:37232|12.0.1.63 7018|1696008116|1
=|185.5.200.0/23|20912 3257 6762 59715|212.66.96.126|i|||3257:8067 3257:30662 3257:50001 3257:53900 3257:53902 20912:65004|212.66.96.126 20912|1695905115|1
=|185.5.200.0/23|34224 6762 59715|94.156.252.18|i|||34224:333|94.156.252.18 34224|1695904349|1
=|185.5.200.0/23|5413 1299 6762 59715|194.153.0.253|i||||194.153.0.253 5413|1695904337|1
=|185.5.200.0/23|3549 3356 6762 59715|208.51.134.246|i|||3356:2 3356:22 3356:86 3356:500 3356:666 3356:901 3356:2064 3549:2352 3549:31826 6762:1 6762:92 6762:13980|208.51.134.246 3549|1695904322|1
=|185.5.200.0/23|3257 6762 59715|89.149.178.10|i|||3257:8052 3257:30024 3257:50001 3257:54900 3257:54901|89.149.178.10 3257|1695904313|1
=|185.5.200.0/23|3561 209 3356 6762 59715|206.24.210.80|i||||206.24.210.80 3561|1695904304|1
=|185.5.200.0/23|11686 6461 6762 59715|96.4.0.55|i|||11686:193|96.4.0.55 11686|1696811668|1
=|185.5.200.0/23|1403 1299 6762 59715|198.58.198.252|i|||1299:25000|198.58.198.252 1403|1695500157|1
=|185.5.200.0/23|8492 31133 6762 59715|85.114.0.217|i|||8492:1104 8492:1601|85.114.0.217 8492|1695937409|1
=|185.5.200.0/23|23673 55329 6939 6762 59715|203.189.128.233|i||||203.189.128.233 23673|1695559649|1
=|185.5.200.0/23|18106 6939 6762 59715|202.73.40.45|i|||6939:2000|202.73.40.45 18106|1696405028|1
=|185.5.200.0/23|3303 6762 59715|217.192.89.50|i|||3303:1004 3303:1006 3303:1030 3303:3055 6762:1 6762:92 6762:13980|217.192.89.50 3303|1695147633|1
=|185.5.200.0/23|2497 2914 6762 59715|202.232.0.3|i||||202.232.0.3 2497|1696571955|1
=|185.5.200.0/23|3741 3356 6762 59715|168.209.255.56|i||||168.209.255.56 3741|1695229174|1
=|185.5.200.0/23|293 3356 6762 59715|198.129.33.85|i||||198.129.33.85 293|1695144527|1
=|185.5.200.0/23|2152 3356 6762 59715|137.164.16.84|i|||2152:65493 2152:65497 2152:65499 2152:65511 3356:3 3356:22 3356:86 3356:575 3356:666 3356:901 3356:2011 6762:1 6762:92 6762:13980|137.164.16.84 2152|1695144524|1
=|185.5.200.0/23|57866 6830 6762 59715|37.139.139.17|i|||6762:1 6762:92 6762:13980 6830:17000 6830:17413 6830:23001 6830:33104 57866:100 65100:6830 65103:2 65104:31 57866:100:6830 57866:101:100 57866:103:2 57866:104:31|37.139.139.17 57866|1695858540|1
=|185.5.200.0/23|22652 174 6762 59715|45.61.0.85|i|||174:21000 174:22013|45.61.0.85 22652|1695144540|1
=|185.5.200.0/23|20130 6939 6762 59715|140.192.8.16|i||||140.192.8.16 20130|1695144510|1
=|185.5.200.0/23|6939 6762 59715|64.71.137.241|i||||64.71.137.241 6939|1695144510|1
=|185.5.200.0/23|1299 6762 59715|62.115.128.137|i||||62.115.128.137 1299|1695144510|1
=|185.5.202.0/24|37100 3303 12874 59715|105.16.0.247|i|||NO_EXPORT|105.16.0.247 37100|1696730621|1
=|185.5.202.0/24|6939 12874 59715|64.71.137.241|i||||64.71.137.241 6939|1696545433|1
=|185.5.202.0/24|3549 3356 12874 59715|208.51.134.255|i|||3356:2 3356:22 3356:100 3356:123 3356:505 3356:901 3356:2074 3549:2018 3549:30840 12874:700 12874:3454|208.51.134.255 3549|1696459515|1
=|185.5.202.0/24|2914 3356 12874 59715|129.250.1.71|i|||2914:420 2914:1409 2914:2403 2914:3400|129.250.1.71 2914|1696458824|1
=|185.5.202.0/24|3303 12874 59715|217.192.89.50|i|||3303:1000 3303:1007 3303:1020 3303:3071 12874:700 12874:1011 12874:3454|217.192.89.50 3303|1696553609|1
=|185.5.202.0/24|49788 12552 3303 12874 59715|91.218.184.60|i|||12552:12000 12552:12100 12552:12101 12552:22000|91.218.184.60 49788|1696591876|1
=|185.5.202.0/24|5413 3303 12874 59715|194.153.0.253|i||||194.153.0.253 5413|1696419788|1
=|185.5.202.0/24|3561 209 3356 12874 59715|206.24.210.80|i||||206.24.210.80 3561|1696419784|1
=|185.5.202.0/24|2497 3356 12874 59715|202.232.0.3|i||||202.232.0.3 2497|1696780731|1
=|185.5.202.0/24|293 3356 12874 59715|198.129.33.85|i||||198.129.33.85 293|1696419788|1
=|185.5.202.0/24|3741 12874 59715|168.209.255.56|i||||168.209.255.56 3741|1696419771|1
=|185.5.202.0/24|2152 11164 3303 12874 59715|137.164.16.84|i|||2152:65299 2152:65511 3303:1000 3303:1007 3303:1020 3303:3071 11164:1170 11164:7880 11164:7890 12874:700 12874:1011 12874:3454|137.164.16.84 2152|1696419769|1
=|185.5.202.0/24|57866 1299 12874 59715|37.139.139.17|i|||1299:30000 57866:100 65100:1299 65103:3 65104:31 57866:100:1299 57866:101:100 57866:103:3 57866:104:31|37.139.139.17 57866|1696780709|1
=|185.5.202.0/24|3549 3356 12874 59715|208.51.134.246|i|||3356:2 3356:22 3356:100 3356:123 3356:505 3356:901 3356:2074 3549:2352 3549:31826 12874:700 12874:3454|208.51.134.246 3549|1696419768|1
=|185.5.202.0/24|7660 2516 6762 12874 59715|203.181.248.195|i|||2516:1030 7660:9001|203.181.248.195 7660|1696419764|1
=|185.5.202.0/24|3257 3356 12874 59715|89.149.178.10|i|||3257:8794 3257:30043 3257:50001 3257:54900 3257:54901|89.149.178.10 3257|1696593715|1
=|185.5.202.0/24|7018 3356 12874 59715|12.0.1.63|i|||7018:5000 7018:37232|12.0.1.63 7018|1696419763|1
=|185.5.202.0/24|8492 57304 12874 59715|85.114.0.217|i|||8492:1101 8492:1601|85.114.0.217 8492|1696419763|1
=|185.5.202.0/24|1299 12874 59715|62.115.128.137|i||||62.115.128.137 1299|1696780726|1
=|185.5.202.0/24|20130 6939 12874 59715|140.192.8.16|i||||140.192.8.16 20130|1696545433|1
=|185.5.202.0/24|3130 1239 3356 12874 59715|147.28.7.2|i|||1239:321 1239:1000 1239:1010|147.28.7.2 3130|1696419763|1
=|185.5.202.0/24|20912 12874 59715|212.66.96.126|i|||20912:65016|212.66.96.126 20912|1696421519|1
=|185.5.202.0/24|34224 12874 59715|94.156.252.18|i|||34224:333 34224:334 34224:2040|94.156.252.18 34224|1696780769|1
=|185.5.202.0/24|11686 6461 12874 59715|96.4.0.55|i|||11686:193|96.4.0.55 11686|1696811668|1
=|185.5.202.0/24|1403 6461 12874 59715|198.58.198.252|i|||1403:6461|198.58.198.252 1403|1696593719|1
=|185.5.202.0/24|23673 55329 6939 12874 59715|203.189.128.233|i||||203.189.128.233 23673|1696419782|1
=|185.5.202.0/24|18106 6939 12874 59715|202.73.40.45|i|||6939:2000|202.73.40.45 18106|1696419763|1
=|185.5.202.0/24|22652 3303 12874 59715|45.61.0.85|i|||3303:1000 3303:1007 3303:1020 3303:3071 12874:700 12874:1011 12874:3454|45.61.0.85 22652|1696419763|1
=|185.5.203.0/24|37100 6762 59715|105.16.0.247|i|||NO_EXPORT|105.16.0.247 37100|1696730618|1
=|185.5.203.0/24|2914 6762 59715|129.250.1.71|i|||2914:420 2914:1005 2914:2000 2914:3000 6762:1 6762:92 6762:13980|129.250.1.71 2914|1696458965|1
=|185.5.203.0/24|3549 3356 6762 59715|208.51.134.255|i|||3356:3 3356:22 3356:86 3356:575 3356:666 3356:901 3356:2011 3549:2018 3549:30840 6762:1 6762:92 6762:13980|208.51.134.255 3549|1696458817|1
=|185.5.203.0/24|3130 1239 6762 59715|147.28.7.2|i|||1239:321 1239:1000 1239:1006|147.28.7.2 3130|1696375295|1
=|185.5.203.0/24|49788 1299 6762 59715|91.218.184.60|i|||1299:20000|91.218.184.60 49788|1696213672|1
=|185.5.203.0/24|7660 2516 6762 59715|203.181.248.195|i|||2516:1030 7660:9001|203.181.248.195 7660|1696342689|1
=|185.5.203.0/24|7018 6762 59715|12.0.1.63|i|||7018:5000 7018:37232|12.0.1.63 7018|1696008116|1
=|185.5.203.0/24|20912 3257 6762 59715|212.66.96.126|i|||3257:8067 3257:30662 3257:50001 3257:53900 3257:53902 20912:65004|212.66.96.126 20912|1695905117|1
=|185.5.203.0/24|34224 6762 59715|94.156.252.18|i|||34224:333|94.156.252.18 34224|1695904349|1
=|185.5.203.0/24|5413 1299 6762 59715|194.153.0.253|i||||194.153.0.253 5413|1695904337|1
=|185.5.203.0/24|3549 3356 6762 59715|208.51.134.246|i|||3356:2 3356:22 3356:86 3356:500 3356:666 3356:901 3356:2064 3549:2352 3549:31826 6762:1 6762:92 6762:13980|208.51.134.246 3549|1695904322|1
=|185.5.203.0/24|3257 6762 59715|89.149.178.10|i|||3257:8052 3257:30024 3257:50001 3257:54900 3257:54901|89.149.178.10 3257|1695904313|1
=|185.5.203.0/24|3561 209 3356 6762 59715|206.24.210.80|i||||206.24.210.80 3561|1695904304|1
=|185.5.203.0/24|11686 6461 6762 59715|96.4.0.55|i|||11686:193|96.4.0.55 11686|1696811668|1
=|185.5.203.0/24|1403 1299 6762 59715|198.58.198.252|i|||1299:25000|198.58.198.252 1403|1695500157|1
=|185.5.203.0/24|8492 31133 6762 59715|85.114.0.217|i|||8492:1104 8492:1601|85.114.0.217 8492|1695937409|1
=|185.5.203.0/24|23673 55329 6939 6762 59715|203.189.128.233|i||||203.189.128.233 23673|1695559649|1
=|185.5.203.0/24|18106 6939 6762 59715|202.73.40.45|i|||6939:2000|202.73.40.45 18106|1696405028|1
=|185.5.203.0/24|3303 6762 59715|217.192.89.50|i|||3303:1004 3303:1006 3303:1030 3303:3055 6762:1 6762:92 6762:13980|217.192.89.50 3303|1695147633|1
=|185.5.203.0/24|2497 2914 6762 59715|202.232.0.3|i||||202.232.0.3 2497|1696571955|1
=|185.5.203.0/24|3741 3356 6762 59715|168.209.255.56|i||||168.209.255.56 3741|1695229174|1
=|185.5.203.0/24|293 3356 6762 59715|198.129.33.85|i||||198.129.33.85 293|1695144527|1
=|185.5.203.0/24|2152 3356 6762 59715|137.164.16.84|i|||2152:65493 2152:65497 2152:65499 2152:65511 3356:3 3356:22 3356:86 3356:575 3356:666 3356:901 3356:2011 6762:1 6762:92 6762:13980|137.164.16.84 2152|1695144524|1
=|185.5.203.0/24|57866 6830 6762 59715|37.139.139.17|i|||6762:1 6762:92 6762:13980 6830:17000 6830:17413 6830:23001 6830:33104 57866:100 65100:6830 65103:2 65104:31 57866:100:6830 57866:101:100 57866:103:2 57866:104:31|37.139.139.17 57866|1695858540|1
=|185.5.203.0/24|22652 174 6762 59715|45.61.0.85|i|||174:21000 174:22013|45.61.0.85 22652|1695144540|1
=|185.5.203.0/24|20130 6939 6762 59715|140.192.8.16|i||||140.192.8.16 20130|1695144510|1
=|185.5.203.0/24|6939 6762 59715|64.71.137.241|i||||64.71.137.241 6939|1695144510|1
=|185.5.203.0/24|1299 6762 59715|62.115.128.137|i||||62.115.128.137 1299|1695144510|1

Parallelamente è necessario disporre di quanto dichiarato dall’AS candidato all’interno del database del RIR di competenza territoriale e, nel dettaglio, è necessario identificare quale sia la routing policy resa pubblica. L’oggetto da considerare è aut-num poiché contiene ciò che è di interesse alla verifica:

aut-num: AS59715
as-name: SBTAP-AS
org: ORG-CdSB1-RIPE
mp-import: afi ipv4.unicast from AS12874 accept any
mp-import: afi ipv6.unicast from AS12874 accept any
mp-import: afi ipv4.unicast from AS6762 accept any
mp-import: afi ipv6.unicast from AS6762 accept any
mp-import: afi ipv4.unicast from AS112 accept AS112
mp-import: afi ipv6.unicast from AS112 accept AS112
mp-export: afi ipv4.unicast to AS12874 announce AS-SBTAP
mp-export: afi ipv6.unicast to AS12874 announce AS-SBTAP
mp-export: afi ipv4.unicast to AS6762 announce AS-SBTAP
mp-export: afi ipv6.unicast to AS6762 announce AS-SBTAP
mp-export: afi ipv4.unicast to AS112 announce any
mp-export: afi ipv6.unicast to AS112 announce any
admin-c: SBT21-RIPE
tech-c: SBT20-RIPE
tech-c: AP7729-RIPE
status: ASSIGNED
mnt-by: RIPE-NCC-END-MNT
mnt-by: SBTAP-MNT
created: 2012-10-04T12:53:46Z
last-modified: 2022-10-24T14:18:26Z
source: RIPE

Ora, ciò che va verificato è che da una parte i rapporti di transito espressi nella routing policy pubblicata nel database del RIR trovino riscontro nella tabella BGP del collector e, dall’altra, che, sempre per le relazioni di transito, gli AS_PATH della tabella BGP corrispondano a quanto dichiarato nel database del RIR.

Per condurre tale controllo abbiamo usato il linguaggio PROLOG utile a trattare i dati come fatti e a costruire delle relazioni tra i fatti così da poter verificare alcune proprietà.

Il programma dunque accetta come input due file: uno contenente gli AS_PATH della tabella BGP relativi all’AS candidato (59715.bgp), l’altro contenente la routing policy dichiarata dal candidato nel database del RIR (59715.rir).

./verify --bgp 59715.bgp --rir=59715.rir
Excellent work, what declared in the RIR DB matches what was found on the Internet (and vice versa)

Questo significa che la verifica ha dato esito positivo: candidato promosso.

Alcune precisazioni

Perché osserviamo solo i transiti e non i peering?

Ai fini dell’esistenza amministrativa e dell’operatività su Internet di un ISP, i rapporti di transito (generalmente considerati un requisito per essere multi-homed) rivestono un ruolo primario {Definizione valida per tutti gli AS tranne che per i tier-1 (vedi infra) i quali, pur soddisfacendo il requisito di essere multi-homed (vedi nota successiva), tuttavia non usufruiscono di transiti per raggiungere tutti gli AS attivi su Internet.} e indispensabile laddove invece i rapporti di peering se da una parte rappresentano quasi sempre {Vedi infra il caso dei peering remoti.} un importante plus per l’efficienza della rete (riduzione drastica della latenza) e per le politiche di instradamento (mantenimento locale del traffico locale), dall’altra sono solitamente opzionali per l’esistenza di un AS {RIPE-679 – Autonomous System (AS) Number Assignment Policies, March 2017: “A network must be multi-homed in order to qualify for an AS Number.”}. Questo ragionamento conduce a eleggere quello sui transiti come controllo principe per la verifica dei sistemi autonomi nell’ambito delle azioni propedeutiche alla certificazione MANRS.

I rapporti di transito sono, per così dire, esposti alla luce del sole cioè pubblicamente osservabili, seppure con alcune avvertenze.

Innanzitutto partiamo dalla definizione di transito esplicitando l’assunto che nessun AS nel mondo di Internet è interconnesso a tutti gli altri contemporaneamente e in modo diretto. Dunque si può dire che AS1 è transito di AS2 quando consente al traffico proveniente da AS2 e destinato ad altri AS (con i quali AS2 non è interconnesso) appunto di transitare per la sua infrastruttura. A esempio, dato che AS2 non ha interconnessione con AS3, allora per raggiungerlo transita per AS1.

T-FIRT(AS1, AS2)
AS1 dà transito T ad AS2 per la FIRT, Full Internet Routing Table.

Questo è il punto di vista di AS2, ma quali sono invece le caratteristiche che AS1 deve avere per poter erogare transito? AS1 deve avere una tabella di routing in grado di instradare il traffico verso qualunque destinazione esistente (e attiva) su Internet, non importa quali siano i mezzi che AS1 ha impiegato per ottenerla (altri transiti, peering bilaterali, peering multilaterali, PNI ecc). Il caso più semplice è che AS1 abbia, nella propria tabella di routing, un instradamento di default (IPv4 0.0.0.0/0 e/o IPv6 ::/0) verso il proprio upstream (altro nome del provider che eroga transito). Tuttavia, quest’ultimo caso è una eccezione che non dovrebbe coinvolgere gli AS che forniscono (a titolo oneroso) un servizio di transito poiché, dato che i RIR richiedono che ciascun AS sia multi-homed (cioè che abbia almeno due upstream provider distinti {Ut supra}), sarebbe assai limitata la possibilità di gestire politiche di traffic engineering. Per questo motivo i rapporti di transito consistono nella trasmissione, attraverso il BGP, di tutti i best-path di cui l’AS erogante è in possesso. L’insieme degli AS che si interconnettono tra loro filtrando gli instradamenti di default si chiama default-free zone (DFZ).

Ora, se AS1 è parte della DFZ (in qualità di transito), ha la possibilità di trasmettere ad AS2 sia un instradamento di default (probabile solo se AS2 sia un cosiddetto stub AS) sia la sua intera tabella di routing via BGP (stragrande maggior parte dei rapporti). Considerando questo secondo caso il più plausibile, si ha una relazione nella quale AS1 trasmette ad AS2 tutti i best-path che ha selezionato e, a sua volta, AS2 (che in questo esempio non ha altri AS come clienti) trasmette ad AS1 i prefissi originanti dal proprio AS (cioè quelli assegnati dai RIR).

T-FIRT(AS1, AS2, AS2_Prefissi)
AS1 dà transito T ad AS2 per la FIRT, Full Internet Routing Table e AS2, a sua volta, trasmette i propri prefissi
AS1 trasmette la Full Internet Routing Table (FIRT) a AS2:

Nel caso in cui AS2 eroghi a sua volta un servizio di transito per altri AS (per esempio ad AS10, AS20 e AS30), allora dovrebbe trasmettere ad AS1 anche i prefissi dei propri clienti (il cosiddetto Customer Cone {Nel campo semantico di RPSLng tale insieme di AS viene esplicitato attraverso la valorizzazione nell’oggetto as-set del campo members dove si inseriscono, oltre il proprio AS, i numeri di AS dei propri clienti, a esempio:

as-set: AS-IBSCUST
members: AS3269
members: AS2162
members: AS2164
members: AS2593
members: AS2594
members: AS2595
members: AS3228
members: AS3573
members: AS3275
members: AS5382
members: AS5394
members: AS5397
members: AS5502
members: AS6734
members: AS6760
members: AS112

}
).

T-FIRT(AS1, AS2, AS2_Prefissi, AS2_Customer_Cone)
AS1 dà transito T ad AS2 per la FIRT, Full Internet Routing Table e AS2, a sua volta, trasmette i propri prefissi e quelli dei propri clienti.

Queste due ultime fattispecie determinano la formazione di AS_PATH (che sono una sequenza ordinata di numeri di AS) di lunghezza leggermente diversa. Infatti, dalla prospettiva di AS1, gli AS_PATH che deve considerare sarebbero:

AS1 AS2
AS1 AS2 AS10
AS1 AS2 AS20
AS1 AS2 AS30

Da questo punto di vista l’individuazione dell’AS in funzione di transito è immediata perché emerge dall’ordine della sequenza dell’AS_PATH; così è possibile osservare che AS1 è transito per AS2, che AS2 è transito per AS10, AS20 e AS30.

Si tratta di una conclusione che può essere desunta facilmente ogni volta che si esamina la tabella BGP di un route-collector ma solo per AS_PATH più lunghi di due AS. Il motivo sta nel fatto che l’accordo con i sistemi autonomi dei route-collector prevede che l’afferente trasmetta l’intera tabella di routing senza filtri e che, a sua volta, il collector non annunci alcun prefisso. {A dire la verità questo punto è stato a lungo dibattuto proprio per il fatto che non ci fosse, a livello globale, una regola unica per gestire l’afferenza a un route-collector. Anche l’ultimo tentativo, del 2022, non è andato in porto: draft-ymbk-grow-bgp-collector-communities}

Questa circostanza fa sì che risulti praticamente impossibile, dall’esame di una sola tabella BGP, determinare se il rapporto tra gli unici due AS che compongono l’AS_PATH sia di transito o di peering (tranne nel caso dei tier-1 spiegato più avanti) poiché in entrambi i casi i prefissi comparirebbero presso il route-collector con il medesimo AS_PATH.

Ecco un esempio di AS_PATH corto (per un prefisso esaminato appunto dalla prospettiva del collector) dove AS100 è afferente al route-collector e contemporaneamente sia transito per AS1:

AS100 AS1

Di seguito invece un esempio di AS_PATH dove AS100 è afferente al route-collector e contemporaneamente abbia un peering con AS1:

AS100 AS1

Si capisce a questo punto come basti che l’AS_PATH, dal punto di vista del collector, sia costituito di almeno tre AS per essere certi che tra l’ultimo AS a destra e il penultimo ci sia un rapporto di transito (cioè dove, procedendo da sinistra verso destra, il penultimo faccia da transito all’ultimo).

I peering, al contrario, non sono facilmente desumibili dall’osservazione di una tabella BGP per ragioni inerenti la natura stessa del rapporto {Ci sono studi che hanno tentato di reperire un metodo per far emergere i rapporti di peering attraverso la collezione di migliaia di tabelle BGP importate da altrettanti punti di osservazione privilegiati come i route-collector. Metodi che, in alcuni casi, hanno dato vita a strumenti disponibili on-line che, purtroppo, si sono rivelati assai imprecisi e incapaci di produrre risultati completi e affidabili. Altri ci hanno provato combinando le tabelle BGP importate dai route-collector con le dichiarazioni che gli AS hanno rilasciato via RPSLng agli IRR o a soggetti aggregatori terzi come peeringDB (https://www.peeringdb.com/), dati combinati anche alle matrici di peering esposte pubblicamente da alcuni IXP nel mondo. Anche in questo secondo caso i risultati sono tutt’altro che esaustivi e accurati.}. Si considerano peering delle sessioni BGP stabilite tra pari, cioè tra AS che più o meno si equivalgono o tra AS, anche molto diversi tra loro per dimensioni, che però hanno valide motivazioni per ritenere vantaggioso il collegamento. Tradizionalmente le sessioni BGP paritarie si configurano a titolo gratuito proprio per l’esistenza di importanti interessi reciproci tra due AS. A volte tuttavia sul mercato si osservano dei particolari frangenti nei quali alcuni AS sono molto corteggiati per rapporti di peering e che, di conseguenza, concedono la configurazione solo a seguito della sottoscrizione di un contratto a titolo oneroso {Può essere il caso di introdurre qui l’utilità delle PNI (Private Network Interconnection) nell’ambito delle facility messe a disposizione dagli IXP o da altre entità dove sono presenti le infrastrutture facenti capo a molteplici AS. Mentre la maggiore parte delle interconnessioni tra AS avviene sull’hardware offerto dai punti di interscambio (chiamato IP Fabric), alcuni altri rapporti possono rimanere privati e possono essere stabiliti sulla base di accordi che esulano dalle regole imposte dagli IXP. Nascono così delle interconnessioni, chiamate PNI, tra due soggetti che si accordano per scambiare traffico in modo riservato cioè senza fare uso dell’infrastruttura pubblica condivisa, decidendo autonomamente le regole del gioco (valide solo tra di loro naturalmente): peering a pagamento, transito, trasporto ecc. Dunque la particolarità citata nel testo, cioè quella di un peering a titolo oneroso con un AS, ritenuto molto interessante, che non partecipa all’infrastruttura pubblica (e gratuita), trova appunto casa nelle PNI.}.

La maggior parte {Tipicamente gli AS tier-1 non afferiscono agli IXP pubblici o, quanto meno, non si presentano sulla LAN di peering.} dei rapporti di peering vede la luce nei NAP, Network Access Point (chiamati anche IXP, Internet Exchange Point), cioè in infrastrutture appositamente dedicate all’incontro {Si tratta di una condizione logica più che fisica. Infatti l’afferenza agli IXP può essere materiale (cioè con apparati e circuiti presenti nelle facility dell’IXP) o virtuale (cioè senza apparati o circuiti di proprietà in loco, ma attraverso trasporto effettuato da altri afferenti) e così, conseguentemente, i rapporti di peering possono essere locali o remoti (con eventuali ripercussioni sulle prestazioni della rete).} tra AS diversi. Tradizionalmente le sessioni si stabiliscono uno a uno attraverso accordi che si prendono in modo più o meno informale: una modalità che, soprattutto con l’affollarsi dei punti di interscambio, ha mostrato la grave incapacità di scalare. Perciò è stata introdotta una nuova tecnica per la realizzazione dei peering, stavolta non più in modo bilaterale, ma in modo multilaterale. In altre parole gli IXP oggi, nella lista di molteplici servizi per gli operatori di rete, mettono a disposizione anche un apparato chiamato Route Server {RFC 7947 Internet Exchange BGP Route Server, September 2016} che ha la caratteristica di poter intrattenere rapporti BGP con tutti gli afferenti e di riflettere gli instradamenti di ciascuno a tutti gli altri (senza modificare l’AS_PATH). In tal modo a ogni AS è sufficiente instaurare una sessione BGP con il Route Server per ricevere gli stessi instradamenti che gli sarebbero stati trasmessi su N {Se il numero degli afferenti a un IXP è N, le configurazioni che ciascun AS deve mettere in piedi per stabilire un rapporto di peering con tutti gli altri è di N-1. Invece, in presenza di un route-server (o più d’uno per ridondanza) è sufficiente configurare una sessione di peering con il route-server per ricevere automaticamente gli instradamenti di tutti gli altri AS che con quel route-server hanno stabilito un rapporto di peering.} tradizionali sessioni di peering.

La sessione di peering si differenzia da quella di transito anche per la natura degli annunci che si esportano e che si importano. Mentre nel transito si accetta tutta la tabella degli instradamenti dall’upstream provider e gli si trasmettono solo i propri prefissi o i propri prefissi e quelli dei propri eventuali clienti, nel rapporto di peering ciascuno trasmette e accetta solo i prefissi propri dell’AS e quelli del cosiddetto Customer Cone. Dunque è un rapporto che ha rilevanza solo tra le parti che partecipano e che, per questo motivo, non si caratterizza negli AS_PATH osservabili dal punto di vista dei route-collector.

In questo contesto è necessario riferire di alcuni speciali AS che non attingono ad altri AS per il transito: si chiamano infatti Transit-Free Network perché intrattengono esclusivamente rapporti di peering (settlement-free peering) tra loro. Sono sedici {Un numero che può leggermente variare nel tempo a seconda delle mutazioni dei rapporti tra gli operatori di rete. In questo caso consideriamo solo i tier-1 su scala mondiale (sia IPv4 sia IPv6) e non quelli rilevanti a livello continentale o quelli che sono transit-free network solo in IPv4 o solo in IPv6 (vedi nota seguente):

  1. AS701 Verizon
  2. AS1239 T-Mobile
  3. AS1299 Arelion
  4. AS2914 NTT
  5. AS3257 GTT
  6. AS3320 DTAG
  7. AS3356 Lumen
  8. AS3491 PCCW
  9. AS5511 Orange
  10. AS6453 Tata
  11. AS6461 Zayo
  12. AS6762 Sparkle
  13. AS6830 Liberty Global
  14. AS7018 AT&T
  15. AS7922 Comcast
  16. AS12956 Telxius}

AS chiamati di livello 1, tier-1, che dunque stabiliscono tra loro rapporti di peering, non acquisiscono transito (semplicemente perché non ne hanno bisogno) e vendono transito (solitamente all’ingrosso) a tutti gli altri.

Quindi gli AS non appartenenti alla cerchia dei tier-1, sono per definizione clienti di un tier-1 o, al massimo, clienti di cliente (e così via) di un tier-1 {Va specificato che questa particolare proprietà dei tier-1 va declinata sia per IPv4 sia per IPv6, di conseguenza si osserva che l’insieme degli AS tier-1 del mondo IPv4 non coincida con quello del mondo IPv6. Emblematico è il caso di AS6939, Hurricane Electric, che è tier-1 per IPv6 ma non per IPv4; oppure il caso di Cogent, AS174, che è tier-1 per IPv4 ma non per IPv6.}.

Quando dunque si rinviene il numero di un AS tier-1 in un AS_PATH, si può pacificamente dedurre che sia transito dell’AS posizionato immediatamente alla sua destra (tranne nel caso di altro AS tier-1, caso in cui il rapporto è di peering), ovunque la coppia si posizioni nella sequenza. Oltre questo si può dedurre che, se alla sua sinistra si trova un AS diverso da tier-1, faccia da transito anche a quest’ultimo. Se invece alla sua sinistra c’è un altro tier-1, allora si tratta di un rapporto di peering, come precedentemente menzionato.

Ecco un esempio chiarificatore:

AS6762 è un tier-1
AS100 è afferente al route-collector

desideriamo osservare l’AS_PATH per il prefisso 1.2.3.0/24 che origina da AS20

1.2.3.0/24 AS100 AS6762 AS1 AS2 AS20

Per tutto quanto esposto finora, l’osservazione di questa sequenza fa scaturire la dichiarazione di alcuni fatti:

AS2 è transito di AS20
AS1 è transito di AS2
AS6762 è transito di AS1
AS6762 è transito di AS100

Altro esempio:

AS6762 è un tier-1
AS6762 è afferente al route-collector

desideriamo osservare l’AS_PATH per il prefisso 1.2.3.0/24 che origina da AS20

1.2.3.0/24 AS6762 AS1 AS2 AS20

Osservazioni:

AS2 è transito di AS20
AS1 è transito di AS2
AS6762 è transito di AS1

Altro esempio:

AS6762 è un tier-1
AS 2914 è un tier-1
AS100 è afferente al route-collector

desideriamo osservare l’AS_PATH per il prefisso 1.2.3.0/24 che origina da AS20

1.2.3.0/24 AS100 AS6762 AS2914 AS1 AS2 AS20

Osservazioni:

AS2 è transito di AS20
AS1 è transito di AS2
AS2914 è transito di AS1
AS6762 è peer di AS2914
AS6762 è transito di AS100

Infine:

AS6762 è un tier-1
AS 2914 è un tier-1
AS100 è afferente al route-collector
AS6762 è afferente al route-collector
AS200 è afferente al route-collector

desideriamo osservare l’AS_PATH per il prefisso 1.2.3.0/24 che origina da AS20

1.2.3.0/24 AS100 AS6762 AS2914 AS1 AS2 AS20
1.2.3.0/24 AS100 AS6762 AS1 AS2 AS20
1.2.3.0/24 AS6762 AS1 AS2 AS20
1.2.3.0/24 AS100 AS200 AS20
1.2.3.0/24 AS200 AS20

Osservazioni:

AS2 è transito di AS20
AS1 è transito di AS2
AS2914 è transito di AS1
AS6762 è peer di AS2914
AS6762 è transito di AS100
AS6762 è transito di AS1
AS200 è transito di AS20
AS100 è peer o transito di AS200

Ora, rispetto alla domanda che chiede quale AS dia transito all’AS20, si può dire che tutti gli esempi siano concordi nell’individuazione dell’AS2 e dell’AS200 in modo sicuro. Nei casi illustrati, i path che vedono un tier-1 come afferente del route-collector non aggiungono né tolgono alcunché alla risposta della domanda iniziale poiché i route-collector, avendo accordi (e di conseguenza sessioni) con molteplici afferenti, in numero assai superiore del numero totale degli AS tier-1, possono sempre mostrare AS_PATH alternativi per il medesimo prefisso.

Di conseguenza, per rendere più snello il lavoro di ricerca dei transiti è possibile, in modo del tutto sicuro, eliminare tutti quegli AS_PATH che recano un tier-1 (che ha numero di AS appartenente a un insieme noto) come primo numero a sinistra, indipendentemente dalla lunghezza dell’AS_PATH.