BGP RPKI: instructions for use (English Version)

As announced recently, “On March 25th, 2020, NTT GIN will deploy BGP routing policies which reject RPKI Invalid BGP route announcements on all AS 2914 EBGP sessions. This change will positively impact the Internet routing system.”

NTT GIN will therefore join the “reject Invalids” club which has, among its members with dimensions comparable to NTT GIN, AT&T (AS 7018), Cloudflare (AS 13335), Cogent (AS 174), KPN (AS 286), PCCW (AS 3491), Tata (AS 6453), Telia (AS 1299). Many others are doing plans to join the club (see for instance this link).

Per un'Internet più sicura: l'architettura BGP RPKI - parte III (pratica)

PREMESSA: questo è l'ultimo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog. Prima di leggere questo post è consigliabile leggere i due precedenti, il primo lo trovate qui, mentre il secondo qui.

Dopo aver visto i principali elementi dell'architettura RPKI e il suo funzionamento di base, è ora di mettere in pratica quanto detto. Illustreremo in questo post l'implementazione RPKI sia in ambiente Cisco (IOS XE) che Juniper (JUNOS).

Per un'Internet più sicura: l'architettura BGP RPKI - parte II (teoria)

PREMESSA: questo è il secondo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog. Prima di leggere questo post è consigliabile leggere il primo, che trovate a qui. 

L'ARCHITETTURA BGP RPKI: SCHEMA A BLOCCHI

L’architettura BGP RPKI, il cui schema a blocchi è riportato nella figura seguente, è basata su dei database (RPKI repository), dove sono contenute le informazioni sui ROA, informazioni che possono essere immesse direttamente dai RIR o anche dai NIR/LIR/ISP (verificate comunque dai RIR) attraverso un particolare Publication Protocol. Di solito per questo i RIR mettono a disposizione delle interfacce web semplificate, che consentono di nascondere agli end user tutte le complessità legate ai Certificati Digitali, focalizzando l’attenzione sulla sola creazione e pubblicazione dei ROA.

Per un'Internet più sicura: l'architettura BGP RPKI - parte I

PREMESSA: questo è il primo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog.

Qualsiasi trattazione di aspetti di sicurezza, non può non iniziare con una illustrazione dei possibili tipi di attacco e una analisi delle vulnerabilità. È chiaro che l’intera Internet è vulnerabile ad attacchi ai suoi protocolli di routing. Il BGP, da questo punto di vista non fa eccezione, ed essendo sicuramente il protocollo più importante, è quello su cui focalizzare maggiormente l’attenzione in termini di protezione. 

BGP (semi) news: il nuovo attributo AIGP

Le regole dei protocolli di routing non sempre portano ad avere percorsi ottimi. Si possono fare vari esempi, sia con OSPF che con IS-IS, dove i percorsi end-to-end non sono ottimali, ferme restando le regole che questi utilizzano per determinare i percorsi ottimi. La ragione principale di questo fenomeno è la partizione in aree, oppure i meccanismi di redistribuzione nel protocollo, da domini di routing esterni.  

Ancora BGP news: dalle Community alle Large Community

Uno degli attributi BGP più utili nelle applicazioni è l'attributo Community. Curiosamente, la definizione di BGP Community non è presente nel documento originale di definizione del BGP versione 4, la versione oggi in uso (RFC 1771 - A Border Gateway Protocol 4 (BGP-4) del Marzo 1995, poi aggiornata nella RFC 4271 con lo stesso titolo nel Gennaio 2006). L'attributo BGP Community è stato introdotto infatti con la RFC 1997 -  BGP Communities Attribute, dell'Agosto 1996.

BGP news: RFC 8212

Il BGP come è noto è un po' l'architrave dell'intera Internet, che può essere vista globalmente come un insieme di reti (nel gergo BGP Autonomous System, AS) interconnesse tra loro (ad oggi circa 60.000). Sul piano dati le informazioni viaggiano utilizzando il protocollo IP (oggi per la maggior parte IPv4, con IPv6 che sta pian piano, ma molto piano, crescendo), mentre sul piano di controllo le informazioni di routing vengono scambiate tra i vari AS utilizzando il protocollo BGP. 

BGP News: Graceful Shutdown di una sessione

Quante volte è capitato di dover effettuare un reload di un router in produzione, magari a seguito dell'aggiornamento del Sistema Operativo o di un solo processo. L'operazione, se eseguita senza alcun accorgimento, porta a perdita di traffico a causa di vari motivi tra cui la convergenza dei protocolli di routing. 

Il mito della FIRT (Full Internet Routing Table)

Questo post prende spunto da una e-mail che ho ricevuto tempo fa da un brillante ex-allievo che lavora in un piccolo ISP, uno di quelli che nel gergo degli ISP è un Tier-2. Ricordo che un ISP Tier-2 è un ISP che comunica direttamente con altre reti, ma che comunque acquista un transito IP per raggiungere almeno una porzione di Internet. 

Scalabilità dei servizi VPN BGP/MPLS: BGP RT Constraint

Il servizio L3VPN su reti BGP/MPLS è sicuramente quello che ha decretato il successo di MPLS. Dalle sue prime implementazioni intorno al 2000-2001, con la crescita del numero di Clienti, sono state introdotte nuove funzionalità in grado di aumentarne la scalabilità. Una di queste, a dire il vero poco conosciuta e poco implementata, riguarda la riduzione dei messaggi UPDATE MP-iBGP (AFI/SAFI = 1/128), utilizzati come noto per annunciare i prefissi dei Clienti VPN. Di altre tecniche di scalabilità, come ad esempio le VPN gerarchiche, parlerò in post futuri. 

BGP News: BGP Optimal Route Reflection

Uno dei criteri di routing più noti è il famoso Hot Potato Routing. Il principio è molto semplice, ogni volta che un router di un determinato AS riceve un pacchetto IP, la cui destinazione è al di fuori del proprio AS, cerca di liberarsene quanto prima, consegnandolo all'exit point dall'AS più vicino, dove "più vicino" va inteso secondo il costo complessivo del protocollo di routing IGP utilizzato. Il perché è presto detto, per utilizzare il minimo numero di risorse interne. (NOTA: il nome curioso deriva dall'analogia "fisica" secondo la quale se uno riceve in mano una patata bollente, cerca di liberarsene il più presto possibile, onde evitare possibili ustioni (qualsiasi altra interpretazione è assolutamente vietata !)).

BGP e NFV: virtual Route Reflector (vRR)

Una delle buzzword del momento è NFV (Network Function Virtualization), ossia la virtualizzazione di alcune funzioni di rete che oggi sono realizzate attraverso apparati hardware dedicati e proprietari. Lo svantaggio dell'utilizzo di hardware dedicato è che l'introduzione di un nuovo servizio, l'aggiornamento del software e dell'hardware spesso richiedono un intervento "fisico" sulla rete, aumentando i costi e il time-to-market.

BGP & SDN : Terza puntata - BGP FlowSpec

Dopo la seconda puntata, continua la saga "BGP & SDN" (il vecchio e il bambino, come la famosa canzone di Guccini, resa famosa anche dai Nomadi). La terza puntata (che al momento non so dirvi se sarà l'ultima, di sicuro al prossimo post passo a MPLS) è in realtà una evoluzione della seconda, dove abbiamo trattato il BGP RTBH, ampiamente utilizzato soprattutto dagli ISP, per contrastare attacchi di tipo DDoS. 

BGP & SDN : Seconda puntata - BGP RTBH

Una funzionalità di sicurezza molto interessante, tipicamente utilizzata nelle reti ISP ed Enterprise, è il meccanismo RTBH (Remote Triggered Black-Hole). RTBH utilizza il BGP per contrastare attacchi di tipo DoS (o DDoS, Distributed DoS) verso un Cliente dell’ISP, bloccando il traffico dell’attaccante ai bordi della rete. Questo traffico, oltre a provocare danni all'attaccato, provoca anche danni collaterali alla rete dell'ISP, consumando banda, risorse di elaborazione e potenzialmente provocando il fuori servizio di qualche apparato della rete.

BGP & SDN : Prima puntata - BGP Link-State

In questo post precedente, dove ho parlato del ruolo del BGP e di MPLS nell'era SDN, ho citato, parlando del ruolo di MPLS, che per determinare in maniera ottimale i percorsi tra due qualsiasi router, è necessario avere una visione completa della topologia della rete. 

BGP e MPLS nell'era SDN

In questo nostro mondo di tanto in tanto, come è giusto che sia, nascono nuove idee e nuovi paradigmi, alcune delle quali hanno successo, altre finiscono miseramente nel dimenticatoio. Si potrebbe scrivere un libro su tutti i "fallimenti" che negli anni si sono avuti nel mondo delle Telecomunicazioni. 

IGP-free Fabric nei Data Center

Nel post precedente sulle Reti di Clos, ho accennato alla fine alcune problematiche legate alla scelta del protocollo di routing da utilizzare in questo tipo di topologie, siano esse a due o tre livelli.

EVPN: l'evoluzione del servizio VPLS – Parte III

Nei due post precedenti sul modello EVPN ho illustrato i concetti e le idee fondamentali, focalizzando l’attenzione soprattutto sulle problematiche legate alla gestione dei collegamenti multi-homed e alla connettività di Livello 2. 

EVPN: l'evoluzione del servizio VPLS – Parte II

Nel post precedente sul modello EVPN ho illustrato i concetti e le idee fondamentali, focalizzando l’attenzione soprattutto alle problematiche legate alla gestione dei collegamenti multi-homed e alle loro (eleganti) soluzioni. Ho tralasciato molti dettagli di funzionamento, che in questo post cercherò almeno in parte di colmare.

EVPN: l'evoluzione del servizio VPLS – Parte I

Chi è familiare con i servizi che i Service Provider offrono sulle loro reti IP+MPLS, saprà che tra questi uno dei più interessanti è il servizio VPLS (Virtual Private LAN Service), che è un servizio di tipo Multipoint-to-Multipoint che consente l’emulazione di LAN Ethernet su una rete IP + MPLS. Nella prossima sezione richiamerò alcuni concetti base su questo servizio, necessari per inquadrare bene il problema del nuovo standard oggetto di questo post.