JungleLabs Insights

Che cos'è il database RIPE e perché è importante?

Articolo

Che cos'è il database RIPE?

Il RIPE Database è un database di registro pubblico che memorizza informazioni sulle risorse numeriche Internet e sui relativi oggetti tecnici. È gestito dal RIPE NCC, il Registro Internet regionale che serve l’Europa, il Medio Oriente e alcune parti dell’Asia centrale. Il suo scopo è contribuire a mantenere la trasparenza, la responsabilità e il coordinamento tecnico nell’intera Internet pubblica.Il database include record per lo spazio di indirizzamento IPv4 e IPv6, ASN, organizzazioni, contatti di rete, criteri di routing, annunci di route, deleghe DNS inverso, contatti per la sicurezza e altre informazioni tecniche. Questi record sono organizzati come oggetti strutturati. Ogni oggetto ha un tipo, una chiave o un identificatore univoco, un insieme di attributi e uno o più maintainer che controllano chi è autorizzato ad aggiornarlo.

Ad esempio, un'allocazione di indirizzi IPv4 può essere rappresentata da un inetnum object. An IPv6 allocation may be represented by an inet6num oggetto. Un ASN è generalmente rappresentato da un aut-num oggetto. Una policy di routing BGP può essere rappresentata da un percorso object for IPv4 or a route6 object for IPv6. A company itself may be represented by an organizzazione oggetto, mentre un contatto tecnico può essere rappresentato tramite un persona o ruolo oggetto. Questi oggetti sono collegati tra loro. Un blocco di indirizzi IP può fare riferimento a un oggetto organizzazione. L'oggetto organizzazione può essere associato a contatti amministrativi e tecnici. Un oggetto route può collegare un prefisso IP a un ASN. Un oggetto maintainer può definire chi ha il permesso di modificare il record. È questa struttura collegata che rende il RIPE Database utile sia per le operazioni tecniche sia per l'amministrazione delle risorse.

È importante comprendere che il RIPE Database è un sistema di registrazione e coordinamento, non un semplice certificato di proprietà. Un registro pubblico può mostrare l'organizzazione responsabile di una risorsa o l'entità registrata come utente finale, ma il contesto giuridico, contrattuale e normativo può essere più complesso. Le aziende non dovrebbero basarsi esclusivamente su una ricerca nel database quando effettuano un trasferimento IPv4 di valore elevato, un'acquisizione, una revisione di una controversia o un importante processo di due diligence. In tali situazioni, il database è un'importante fonte di prove, ma dovrebbe essere esaminato insieme alle procedure di registrazione vigenti, alla documentazione contrattuale e, ove appropriato, alla consulenza professionale.

RIPE NCC, la comunità RIPE e il RIPE Database

I termini “RIPE”, “RIPE NCC” e “RIPE Database” sono spesso usati insieme, ma non significano esattamente la stessa cosa. RIPE si riferisce alla comunità più ampia di operatori di rete, fornitori di servizi Internet, specialisti tecnici e altri stakeholder coinvolti nello sviluppo e nel coordinamento delle operazioni Internet nella regione. RIPE NCC, ovvero Réseaux IP Européens Network Coordination Centre, è l’organizzazione che fornisce servizi di registro e coordinamento, inclusa la gestione del RIPE Database.

RIPE NCC è uno dei cinque Regional Internet Registry del mondo. Gli altri quattro sono ARIN per gli Stati Uniti, il Canada e parti dei Caraibi e dell'Atlantico settentrionale; APNIC per la regione Asia-Pacifico; LACNIC per l'America Latina e gran parte dei Caraibi; e AFRINIC per l'Africa e la regione dell'Oceano Indiano. Ogni RIR gestisce le risorse numeriche Internet all'interno della propria regione di servizio in base a politiche sviluppate attraverso processi della comunità.Il RIPE Database è pertanto uno strumento operativo fondamentale per la regione del RIPE NCC. Un'azienda che riceve un ASN tramite un LIR sponsor del RIPE NCC, ad esempio, può vedersi inserire o aggiornare informazioni nel RIPE Database nell'ambito del processo di registrazione. In seguito, l'azienda potrebbe dover gestire i record dell'organizzazione, i contatti tecnici, gli oggetti di instradamento, le autorizzazioni RPKI, le informazioni sui contatti per gli abusi e i dati relativi a BGP.

Per gli operatori di rete, il database supporta le decisioni operative quotidiane. Un provider di transito può utilizzare i dati degli oggetti di rotta nella creazione di filtri dei prefissi. Un analista della sicurezza può utilizzare il database per identificare un contatto pertinente per gli abusi. Un'azienda può cercare un ASN prima di instaurare una relazione di peering o di servizio. Un data center può verificare i registri di assegnazione degli indirizzi durante una revisione del trasferimento di un IP. Un ingegnere che sta risolvendo un problema relativo a un annuncio di rotta può confrontare il prefisso IP, l'ASN di origine, l'oggetto di rotta, lo stato RPKI e i requisiti del provider upstream.

Perché il database RIPE è importante per le aziende

Il database RIPE è importante perché l'infrastruttura Internet necessita di responsabilità pubblica. Quando un'azienda gestisce un prefisso IP o un ASN, altre reti hanno bisogno di un modo affidabile per determinare chi è responsabile di quella risorsa. Ciò è particolarmente importante quando si verifica un incidente di routing, un attacco DDoS, una segnalazione di spam, una segnalazione di abuso, un modello di traffico sospetto, un dirottamento BGP, un'interruzione della connettività o un'indagine sulla sicurezza.

Un record del database RIPE ben mantenuto può rendere un'azienda più facile da identificare e contattare. Può inoltre ridurre gli attriti quando si lavora con provider di transito upstream, Internet Exchange Point, partner di connettività cloud, provider di mitigazione DDoS e altri operatori di rete. Se i record di un'organizzazione sono incompleti, inesatti o non aggiornati, questa potrebbe subire ritardi nel tentativo di annunciare prefissi, convalidare il routing BGP, dimostrare il controllo delle risorse, aggiornare i contatti o rispondere a un incidente.

Il database è inoltre importante per la gestione della reputazione. Gli indirizzi IP pubblici possono sviluppare una reputazione in base al loro utilizzo storico. Un provider di hosting, un operatore VPN, una piattaforma email, un'azienda cloud o un servizio proxy potrebbe dover dimostrare di avere una struttura organizzativa legittima, un contatto per gli abusi attivo, contatti tecnici chiari e record di routing adeguatamente mantenuti. Sebbene una voce nel database RIPE non garantisca una buona reputazione, può contribuire a una presenza di rete più trasparente e professionale.Per le organizzazioni che utilizzano BGP, gli oggetti route e i record RPKI accurati sono particolarmente preziosi. Molti provider upstream utilizzano le informazioni dei registri di routing per creare filtri sui prefissi. Se una rete annuncia un prefisso ma non dispone di un oggetto route appropriato o di un'autorizzazione al routing, il provider potrebbe rifiutare la route. Ciò può causare interruzioni, ritardi nell'attivazione o una raggiungibilità globale incompleta.

Il Database RIPE supporta anche la governance interna. Un'azienda può avere diverse persone coinvolte nelle operazioni di rete, nella conformità, nella gestione legale, nella fatturazione, nella gestione degli abusi e nella manutenzione dell'infrastruttura. Relazioni chiare tra gli oggetti e controlli dei maintainer possono aiutare l'azienda a definire chi può aggiornare quali record. Ciò riduce il rischio che ex dipendenti, consulenti di terze parti o soggetti non autorizzati mantengano il controllo di record critici delle risorse Internet.

Tipi di oggetti importanti del database RIPE

Il RIPE Database contiene molti tipi diversi di oggetti. Alcuni sono utilizzati principalmente dagli amministratori dei registri, mentre altri sono utilizzati regolarmente dagli ingegneri di rete e dai responsabili delle risorse IP. Gli oggetti più importanti per una tipica azienda che utilizza spazio IP pubblico e un ASN sono l'oggetto organizzazione, l'oggetto indirizzo IP, l'oggetto ASN, l'oggetto contatto, l'oggetto maintainer e l'oggetto route.

An organizzazione l’oggetto rappresenta una persona giuridica, un titolare di risorse, un utente finale o un’altra organizzazione riconosciuta coinvolta nella registrazione delle risorse di numerazione Internet. Può includere il nome dell’organizzazione, il tipo, i riferimenti all’indirizzo, i riferimenti ai contatti e le informazioni sul maintainer. Questo oggetto consente di associare gli intervalli di indirizzi IP e gli ASN a un’organizzazione responsabile.

An inetnum l'oggetto rappresenta un intervallo di indirizzi IPv4. Può contenere l'intervallo stesso, un nome descrittivo, un riferimento all'organizzazione, contatti amministrativi e tecnici, informazioni sullo stato, riferimenti ai contatti per gli abusi e controlli del maintainer. Un inet6num object performs a similar function for IPv6 address space. These records are critical because they identify the network operator or organization associated with an address block.

An aut-num l'oggetto rappresenta un Numero di Sistema Autonomo. Può includere l'ASN, l'organizzazione responsabile, informazioni sulla politica di instradamento, riferimenti alle politiche di importazione ed esportazione, contatti tecnici e informazioni sul maintainer. Un'azienda che utilizza BGP dovrebbe assicurarsi che i dati relativi all'ASN siano accurati, poiché questo record fa parte del contesto pubblico relativo all'identità di instradamento della rete.

A persona l'oggetto identifica un singolo contatto, mentre un ruolo l’oggetto identifica un contatto funzionale come “Centro operativo di rete”, “Reparto abusi”, “Supporto tecnico” o “Amministrazione delle risorse IP”. In molti casi, gli oggetti di ruolo sono più pratici dei contatti personali perché rimangono validi anche quando cambiano i dipendenti. Un’azienda ben gestita utilizza spesso indirizzi di ruolo funzionali per le operazioni di rete e la gestione degli abusi, invece di affidarsi interamente ai dati personali di un singolo dipendente.

A mntner l'oggetto, abbreviazione di oggetto maintainer, è uno dei controlli di sicurezza più importanti nel Database RIPE. Specifica i requisiti di autenticazione e autorizzazione per la modifica degli oggetti correlati. Se un maintainer non è configurato correttamente, l'azienda potrebbe perdere la possibilità di aggiornare i propri record nel database oppure esporsi a tentativi di modifica non autorizzati. Le credenziali del maintainer, le password, le credenziali API e le procedure di autorizzazione devono essere gestite con attenzione e non devono mai essere esposte in codice sorgente pubblico, script lato browser o documentazione non protetta.

A percorso object documents the relationship between an IPv4 prefix and an origin ASN. A route6 l'oggetto fornisce il record equivalente per un prefisso IPv6. Ad esempio, un oggetto route può indicare che 203.0.113.0/24 è destinato a essere annunciato da AS64500. Questi oggetti sono comunemente utilizzati dai provider e dai peer durante la creazione di filtri di routing. Un oggetto route non equivale a un annuncio BGP attivo, ma è un'importante dichiarazione dell'intento di routing.

Come cercare nel database RIPE

Il database RIPE può essere consultato tramite la sua interfaccia web, strumenti di interrogazione in stile WHOIS e API REST. Il metodo scelto dipende dallo scopo dell’utente. Un responsabile aziendale può preferire l’interfaccia web perché è facile da leggere. Un ingegnere di rete può utilizzare query dalla riga di comando o le API REST per l’automazione. Un team di sicurezza può utilizzare una combinazione di ricerche nel database, strumenti di convalida RPKI, piattaforme di monitoraggio BGP e sistemi interni di risposta agli incidenti.

Una ricerca IP di base può mostrare le informazioni di registrazione associate a un intervallo di indirizzi IPv4 o IPv6 pubblico. Se un utente cerca un indirizzo IP, il database può restituire un oggetto relativo all'intervallo di indirizzi contenente l'intervallo allocato o assegnato, il nome della rete, il codice del Paese, il riferimento all'organizzazione, i contatti tecnici, i riferimenti ai contatti per gli abusi e le informazioni sul maintainer. A seconda dell'oggetto e delle norme sulla privacy applicabili, alcuni dettagli di contatto potrebbero essere oscurati o limitati.

Una ricerca ASN può mostrare il aut-num oggetto associato a una rete. Può includere l’ASN stesso, una descrizione, riferimenti all’organizzazione pertinente, contatti tecnici, informazioni sulla policy di routing e dettagli del maintainer. Un record ASN può essere utile quando si indaga sull’identità di routing di una rete o ci si prepara a una relazione BGP.

Una ricerca della route può aiutare a determinare se un prefisso è documentato come annunciato da uno specifico ASN. Ciò è utile quando un provider upstream richiede un oggetto route prima di accettare un annuncio BGP. Può inoltre aiutare gli ingegneri a diagnosticare il motivo per cui un prefisso viene filtrato, rifiutato o trattato come imprevisto.

Tuttavia, gli utenti devono comprendere i limiti dei dati. Un oggetto route non dimostra che la route sia attualmente visibile su Internet globale. Non dimostra che ogni provider accetti la route. Inoltre, non sostituisce la convalida RPKI. Per comprendere la visibilità attuale del routing, l'utente potrebbe dover consultare sistemi di monitoraggio BGP, collettori di route, looking glass dei provider, validatori RPKI o piattaforme di intelligence sul routing.

Analogamente, un record dell'indirizzo IP può mostrare un'organizzazione registrata, ma non rivela necessariamente ogni azienda che utilizza servizi dietro quell'indirizzo. I provider di hosting, le piattaforme cloud, i servizi VPN e i rivenditori possono gestire infrastrutture per molti clienti utilizzando un blocco condiviso o delegato.

TUTORIAL TECNICO

Come utilizzare l'API REST del database RIPE

Apprendi il formato degli URI REST, le chiavi degli oggetti, le consultazioni sicure in sola lettura, gli aggiornamenti autenticati, la convalida in modalità dry-run, i formati delle risposte e le misure di sicurezza operative.

L'API REST del RIPE Database fornisce accesso programmatico agli oggetti del RIPE Database tramite HTTPS. È utile per gli inventari delle risorse, gli strumenti di gestione della rete, i portali interni, i flussi di monitoraggio e l'amministrazione controllata delle risorse. Ogni oggetto del RIPE Database dispone di un URI di localizzazione univoco, quindi un'applicazione può recuperare o gestire un oggetto specifico quando conosce la fonte del database, il tipo di oggetto e la chiave primaria.

1 Informazioni sul formato URI REST

Il formato URI standard dell'oggetto è https://rest.db.ripe.net/source/objecttype/key. Il fonte identifica la fonte del database, come RIPE per i dati di produzione o TEST quando si utilizza l'ambiente di test. Il tipo di oggetto identifica l'oggetto del Database RIPE, come inetnum, inet6num, aut-num, persona, ruolo, mntner, percorso, oppure route6. Il chiave è l'identificatore primario dell'oggetto.

Pattern URI https://rest.db.ripe.net/source/objecttype/key

La maggior parte dei tipi di oggetto utilizza un valore di chiave primaria. Gli oggetti persona e ruolo utilizzano il nic-hdl il valore come chiave. Gli oggetti route e route6 usano una chiave combinata: il prefisso della route seguito immediatamente dall'ASN di origine. Ad esempio, un oggetto route per il prefisso 193.0.22.0/23 originato da AS3333 utilizza la chiave combinata 193.0.22.0/23AS3333. Utilizzare la codifica URL quando richiesto, quando una chiave include caratteri quali barre, spazi o altri caratteri URL riservati.

Ambiente di produzione https://rest.db.ripe.net

Usa questo endpoint per gli oggetti live del database RIPE e gli aggiornamenti di produzione autorizzati.

Ambiente di test https://rest-test.db.ripe.net

Utilizza questo endpoint per esercitarti con le richieste e convalidare la logica di integrazione senza modificare i dati di produzione.

2 Inizia con una ricerca di oggetti di sola lettura

Il recupero in sola lettura è il punto di partenza più sicuro per un'integrazione. Il comando seguente richiede il pubblico aut-num oggetto per l'ASN di esempio AS3333 e chiede all'API di restituire JSON. Sostituisci l'ASN di esempio solo con un ASN pubblico reale che sei autorizzato a interrogare. Questo comando non crea, modifica o elimina alcun oggetto del database.

curl -H "Accept: application/json" \
  "https://rest.db.ripe.net/ripe/aut-num/AS3333.json"

Puoi richiedere XML utilizzando Accept: application/xml oppure utilizzando un .xml estensione. JSON può essere richiesto con Accept: application/json o un .json estensione. Se il formato della risposta non è specificato, l'API utilizza XML per impostazione predefinita. Le applicazioni devono richiedere esplicitamente il formato preferito, in modo che il comportamento di analisi rimanga prevedibile.

3 Cerca dati quando non conosci la chiave esatta dell'oggetto

Una richiesta di ricerca è utile quando si dispone di un ASN, un indirizzo IP, un prefisso, un identificatore di organizzazione o un altro valore di ricerca, ma non si conosce ancora l'URI esatto dell'oggetto. L'esempio seguente cerca nella fonte RIPE i record relativi ad AS3333. Il flags=no-referenced il parametro richiede una risposta semplificata che non includa gli oggetti referenziati.

curl --get "https://rest.db.ripe.net/search.json" \
  --data-urlencode "query-string=AS3333" \
  --data-urlencode "source=ripe" \
  --data-urlencode "flags=no-referenced".

Per una ricerca del routing, restringi la risposta in base al tipo di oggetto. Il seguente esempio cerca IPv4 percorso oggetti associati al prefisso della documentazione 203.0.113.0/24. Un oggetto route documenta le informazioni di routing previste; dovrebbe essere valutato insieme alla visibilità BGP in tempo reale e allo stato RPKI prima di prendere una decisione di routing.

curl --get "https://rest.db.ripe.net/search.json" \
  --data-urlencode "query-string=203.0.113.0/24" \
  --data-urlencode "type-filter=route" \
  --data-urlencode "source=ripe"

4 Usa POST, PUT e DELETE solo con la corretta autorizzazione

L'API REST supporta PUBBLICA per creare un oggetto, PUT per aggiornare un oggetto esistente e ELIMINA per rimuovere un oggetto. Queste operazioni richiedono HTTPS, un'autorizzazione corretta e un corpo della richiesta o un oggetto di destinazione validi. Il corpo della richiesta per la creazione o l'aggiornamento di un oggetto è una rappresentazione WhoisResource dell'oggetto. Per le richieste POST, PUT e DELETE, specificare appropriati Tipo di contenuto e Accetta intestazioni. Le rappresentazioni degli oggetti supportate includono application/json e application/xml.

PUBBLICA

Crea un oggetto

Usa POST /{source}/{objecttype} per creare un nuovo oggetto. Una richiesta completata correttamente restituisce l'oggetto appena creato, non filtrato.

PUT

Aggiorna un oggetto

Usa PUT /{source}/{objecttype}/{key} inviare una nuova versione di un oggetto esistente.

ELIMINA

Rimuovi un oggetto

Usa ELIMINA /{source}/{objecttype}/{key} solo quando l'oggetto non è più necessario e la cancellazione è autorizzata.

Non inserire una chiave API, un valore di autenticazione di base, un certificato, una password o una credenziale del manutentore nell'HTML di WordPress, nel JavaScript del front-end, in un repository Git pubblico, in uno screenshot o in un'e-mail. Le richieste autenticate devono essere effettuate tramite un servizio sicuro lato server, un runner di automazione controllato o un ambiente professionale di gestione dei segreti.

5 Convalida prima le modifiche con un'esecuzione di prova

Usa il dry-run=true parametro di query per convalidare una richiesta POST, PUT o DELETE proposta senza eseguire l'aggiornamento. Questo è il metodo preferito per testare la struttura della richiesta, il contenuto dell'oggetto e il comportamento dell'autorizzazione prima di qualsiasi modifica in produzione. L'esempio seguente è intenzionalmente rivolto all'endpoint di test e utilizza valori segnaposto. Deve essere adattato esclusivamente da un amministratore autorizzato che lavori con un oggetto di test valido e credenziali sicure.

curl -X PUT \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  --data @object.json \
  "https://rest-test.db.ripe.net/test/person/EXAMPLE-TEST?dry-run=true"

L'opzionale non formattato parametro può essere utilizzato quando un'applicazione deve preservare la formattazione fornita nella richiesta, inclusi spazi e interruzioni di riga. Per le richieste di eliminazione, l'opzionale motivo Il parametro può essere fornito per documentare il motivo per cui l'oggetto viene rimosso. Un'esecuzione a secco convalida la richiesta, ma non crea, aggiorna o elimina l'oggetto di destinazione.

6 Interpretare i codici di stato HTTP e le risposte API

Le applicazioni client dovrebbero utilizzare i codici di stato HTTP per determinare l'esito di un'operazione e dovrebbero leggere il corpo della risposta quando si verifica un errore. Il corpo della risposta viene restituito nel formato JSON o XML richiesto. Una risposta di aggiornamento riuscita contiene l'oggetto così come appare nel database dopo l'operazione, il che è utile quando un'applicazione necessita di una conferma immediata del risultato memorizzato.

200Richiesta o aggiornamento riusciti.
400Richiesta non valida, ad esempio un tipo di oggetto o una chiave non validi.
401Autenticazione non riuscita o credenziali richieste non fornite.
403 / 429La richiesta è stata rifiutata oppure è stato superato un limite di query.
404L'oggetto richiesto o il risultato della ricerca non è stato trovato.
409È stato violato un vincolo di integrità, ad esempio durante la creazione di un oggetto esistente.
415Il tipo di supporto multimediale Accept o Content-Type è mancante o non supportato.
500Il servizio ha riscontrato una condizione interna imprevista.

7 Piano per la codifica e la latenza degli aggiornamenti

Le risposte dell’API REST vengono restituite in UTF-8. Gli oggetti del Database RIPE vengono memorizzati utilizzando il set di caratteri Latin-1, pertanto il contenuto della richiesta deve utilizzare UTF-8 rimanendo al contempo entro i caratteri Latin-1 validi. Se è necessario convertire un carattere non supportato, il servizio può sostituirlo con un carattere punto interrogativo e restituire un avviso. Dopo un’operazione di scrittura, eseguire una query successiva oppure fare affidamento sulla risposta di modifica riuscita per confermare ciò che è stato memorizzato.

Gli aggiornamenti del database potrebbero non essere immediatamente visibili nelle operazioni di ricerca e consultazione. Il ritardo massimo documentato può arrivare fino a dieci secondi. Gli oggetti non gerarchici, come gli oggetti person, role e organisation, sono spesso visibili più rapidamente. I tipi di oggetti gerarchici, inclusi gli oggetti inetnum, inet6num, route, route6 e domain, possono impiegare diversi secondi prima di comparire nelle ricerche successive. L'automazione in produzione dovrebbe pertanto includere una logica di nuovi tentativi e non dovrebbe considerare una mancata corrispondenza immediata nella consultazione come prova del fallimento di un aggiornamento eseguito con successo.

Come gli oggetti di instradamento del database RIPE supportano il filtraggio BGP

BGP è il protocollo di routing che consente ai Sistemi autonomi di scambiare informazioni sulla raggiungibilità attraverso Internet. Quando un'azienda annuncia un prefisso IPv4 o IPv6, il suo provider upstream deve decidere se accettare quella rotta. Per ridurre il rischio di perdite di rotte, dirottamento di prefissi, annunci accidentali e violazioni delle policy, molti provider utilizzano filtri di routing.

Un oggetto route è uno degli input che possono supportare questo processo di filtraggio. L'oggetto indica che un determinato prefisso deve essere originato da un determinato ASN. Ad esempio, se un'azienda opera AS64500 e annuncia 203.0.113.0/24, un oggetto route può documentare tale relazione. Un provider può utilizzare l'oggetto route durante la creazione di un filtro dei prefissi che consenta all'ASN di annunciare solo quel prefisso previsto.Questo non significa che ogni provider utilizzi la stessa politica di filtraggio. Alcuni provider utilizzano ampiamente gli oggetti route IRR. Altri fanno maggiore affidamento su RPKI. Molti utilizzano una combinazione di RPKI, dati IRR, regole di policy interne, contratti con i clienti, limiti sui prefissi e revisione manuale. Pertanto, un'azienda non dovrebbe presumere che la creazione di un oggetto route garantisca automaticamente l'accettazione della rotta ovunque.L'approccio operativo migliore consiste nel coordinarsi con il provider upstream prima dell'annuncio. L'azienda dovrebbe confermare quali prefissi verranno annunciati, quale ASN li originerà, se il provider richiede oggetti route IRR, se sono richiesti ROA RPKI, quale lunghezza massima del prefisso è consentita e se il provider dispone di una procedura di registrazione delle rotte o di ticketing.

Un errore comune è configurare prima il BGP e occuparsi dei record delle rotte in un secondo momento. Questo può causare ritardi perché il provider potrebbe rifiutare l’annuncio finché i dati di registrazione non sono completi. Un processo migliore consiste nel preparare l’oggetto della rotta, creare o convalidare la ROA, verificare i record dell’ASN e dell’organizzazione, quindi configurare la sessione BGP ed eseguire test controllati.

Database RIPE e RPKI: simili ma diversi

Il database RIPE e RPKI sono correlati alla sicurezza del routing, ma svolgono funzioni diverse. Il database RIPE contiene informazioni di registrazione e sulle politiche di routing mantenute pubblicamente. RPKI, ovvero Resource Public Key Infrastructure, è un framework crittografico utilizzato per creare autorizzazioni dell'origine delle rotte.

Un oggetto route può dichiarare che uno specifico prefisso IP è destinato a essere originato da uno specifico ASN. Una ROA autorizza crittograficamente un ASN a originare uno specifico prefisso e può anche definire la lunghezza massima del prefisso che può essere annunciato. Le reti che eseguono la convalida dell'origine delle route RPKI possono utilizzare le ROA per classificare le route ricevute come valide, non valide o non trovate.

Ad esempio, un'organizzazione può detenere un prefisso IPv6 e gestire un ASN. Può creare un oggetto route6 nel RIPE Database per documentare l'ASN di origine previsto. Può anche creare una ROA che autorizzi tale ASN ad annunciare il prefisso. L'oggetto route6 può agevolare il filtraggio basato sull'IRR, mentre la ROA supporta la convalida crittografica dell'origine della rotta.I due elementi dovrebbero essere mantenuti coerenti. Se l'oggetto route punta a un ASN ma la ROA ne autorizza un altro, i provider upstream e gli operatori di rete potrebbero rilevare segnali contrastanti. Se la ROA ha una lunghezza massima del prefisso errata, gli annunci legittimi di prefissi più specifici potrebbero essere contrassegnati come non validi. Se un oggetto route è obsoleto, un provider che utilizza filtri basati sull'IRR potrebbe rifiutare un annuncio altrimenti legittimo.

Le organizzazioni dovrebbero riesaminare i propri oggetti route e le ROA ogni volta che modificano gli accordi relativi agli ASN, cambiano LIR sponsor, trasferiscono risorse IPv4, ristrutturano la propria azienda, aggiungono un nuovo provider upstream o modificano la propria policy di annuncio dei prefissi. I record di routing dovrebbero essere trattati come dati operativi in continua evoluzione, non come attività di configurazione da svolgere una tantum.

Utilizzo dell'API REST del database RIPE

L'API REST del RIPE Database consente ai sistemi software di recuperare e, ove debitamente autorizzati, gestire gli oggetti del RIPE Database tramite richieste programmatiche. L'API può essere utile per le organizzazioni che gestiscono molte reti, mantengono ampi portafogli di risorse IP, eseguono sistemi di monitoraggio, sviluppano portali per i clienti o devono integrare i dati del registro nei flussi di lavoro interni.

Un semplice flusso di lavoro di un'API REST può iniziare con una richiesta di ricerca. Il sistema invia una query per un ASN, un indirizzo IP, un prefisso, un identificatore dell'organizzazione, un nome di rete o un altro valore noto. Il database restituisce dati strutturati, comunemente in formato JSON o XML. L'applicazione può quindi analizzare il risultato e visualizzare gli attributi pertinenti a un operatore oppure confrontare il risultato con i record interni.

Ad esempio, un provider cloud può utilizzare query API in sola lettura per verificare se esiste un ASN fornito dal cliente e se i record di routing pubblici corrispondono alle informazioni di onboarding. Un sistema di sicurezza di rete può utilizzare query API per identificare un contatto registrato per le segnalazioni di abuso relativo a un intervallo di indirizzi. Una piattaforma di gestione delle risorse IP può confrontare il proprio inventario interno con i record di registrazione pubblici per identificare contatti obsoleti o oggetti di routing mancanti.

L’API dovrebbe essere utilizzata in modo responsabile. I sistemi automatizzati dovrebbero evitare volumi di query eccessivi, gestire gli errori in modo appropriato e non considerare un singolo risultato del database come prova completa di proprietà, autorizzazione o stato di instradamento attivo. Un flusso di lavoro solido può combinare i risultati dell’API del Database RIPE con la convalida RPKI, i dati di monitoraggio BGP, i contratti interni, la verifica dei clienti e una revisione manuale.

Per le richieste di sola lettura, può essere sufficiente uno strumento da riga di comando come cURL. Uno sviluppatore può inviare una richiesta GET all'endpoint di ricerca, definire un valore di ricerca, applicare un filtro per origine e richiedere una risposta JSON. La risposta può quindi essere analizzata in Python, PHP, JavaScript, Go, Java o qualsiasi altro linguaggio di programmazione in grado di leggere JSON.Quando si lavora con gli aggiornamenti degli oggetti, il rischio è maggiore. Le modifiche agli oggetti delle route, ai contatti, ai record delle organizzazioni o ai responsabili possono influire sul routing in produzione, sulla risposta agli incidenti e sulla continuità aziendale. Le operazioni di scrittura richiedono un'autorizzazione appropriata tramite il responsabile o il processo di registro pertinente. Le credenziali devono essere archiviate in modo sicuro lato server o in un sistema approvato di gestione dei segreti. Non devono mai essere incorporate nell'HTML del sito web, nel JavaScript front-end, nei repository pubblici, nella memoria locale del browser, negli screenshot, nei modelli di email o nei file di configurazione non crittografati.

Un'azienda dovrebbe inoltre stabilire procedure di gestione delle modifiche. Prima di aggiornare un oggetto route o un record correlato all'ASN, l'ingegnere responsabile dovrebbe verificare il prefisso previsto, l'ASN di origine, lo stato RPKI, i requisiti del provider upstream, il percorso di autorizzazione e il potenziale impatto della modifica. Per le organizzazioni più grandi, una revisione da parte di una seconda persona può aiutare a prevenire errori accidentali nelle policy di instradamento.

Qualità dei dati del database RIPE ed errori comuni

La qualità dei dati è una delle questioni più importanti nel RIPE Database. Un'azienda può disporre di risorse IP legittime e di un ASN attivo, ma se gli oggetti associati sono obsoleti, incoerenti o gestiti in modo inadeguato, l'azienda può comunque dover affrontare problemi tecnici e operativi.Un errore comune consiste nell'utilizzare i dati personali dei dipendenti come unico contatto tecnico o amministrativo. I dipendenti cambiano ruolo, lasciano le aziende, cambiano indirizzo e-mail o diventano irreperibili durante gli incidenti. Un oggetto di ruolo funzionale, come un contatto del Network Operations Center o dell'Abuse Desk, è spesso più duraturo. L'azienda può aggiornare le persone che ricoprono il ruolo senza dover modificare ogni oggetto di risorsa collegato.

Un altro errore comune consiste nel non aggiornare le informazioni sull'organizzazione dopo una modifica della denominazione legale, un'acquisizione, una fusione o una ristrutturazione societaria. Se l'entità giuridica associata a un ASN o a un blocco IP cambia, potrebbe essere necessario riesaminare i dati del registro. L'azienda dovrebbe coordinarsi con il proprio LIR sponsor o fornitore di servizi del registro, anziché presumere che una modifica legale interna si rifletta automaticamente nei registri Internet pubblici. Alcune organizzazioni creano anche oggetti di rotta, ma non provvedono a mantenerli. Potrebbero aggiungere un nuovo provider upstream, modificare un ASN, trasferire un prefisso o modificare la propria progettazione BGP senza aggiornare i dati di routing. Ciò può creare una discrepanza tra la policy di routing prevista e le informazioni presenti nei database pubblici.

Un problema correlato consiste nel trattare gli oggetti di rotta IRR e le ROA RPKI come intercambiabili. Non lo sono. Entrambi possono essere utili e ciascuno può essere richiesto da provider o sistemi di convalida diversi. Un moderno processo di sicurezza del routing dovrebbe esaminare entrambi.

Infine, le organizzazioni dovrebbero proteggere con attenzione l'accesso dei responsabili della manutenzione. I controlli del responsabile della manutenzione associati a un oggetto possono determinare chi può aggiornarlo. La perdita dell'accesso a un responsabile della manutenzione può rendere difficili gli aggiornamenti futuri. La condivisione non sicura delle credenziali del responsabile della manutenzione può creare un rischio per la sicurezza inaccettabile. Le aziende dovrebbero documentare la titolarità, conservare le credenziali in modo sicuro e mantenere un processo interno chiaro per il recupero dell'accesso e le modifiche autorizzate.

Database RIPE, trasferimenti IPv4 e due diligence delle risorse

Il database RIPE è particolarmente rilevante durante un trasferimento IPv4. Prima di acquisire spazio di indirizzi IPv4, un acquirente dovrebbe esaminare i registri pubblici associati al prefisso. Questi possono includere l'oggetto indirizzo attuale, il riferimento all'organizzazione, il nome della rete, lo stato della risorsa, i contatti tecnici, il contatto per gli abusi, gli oggetti di rotta e i dettagli del maintainer.

Lo scopo non è semplicemente confermare che il prefisso esista. L'acquirente dovrebbe verificare se le informazioni di registrazione appaiono coerenti, se il blocco di indirizzi contiene oggetti di instradamento esistenti, se il suo utilizzo storico può sollevare preoccupazioni in materia di reputazione e se il percorso di trasferimento può essere gestito correttamente attraverso il processo del registro competente.

Ad esempio, un acquirente potrebbe scoprire che un blocco IPv4 ha oggetti di routing attivi associati a un ASN che non verrà più utilizzato dopo il trasferimento. L'acquirente potrebbe dover coordinare la rimozione o la sostituzione di tali record, creare nuovi oggetti di routing per il proprio ASN e aggiornare le ROA RPKI prima di annunciare il prefisso dalla propria rete.

L'acquirente dovrebbe inoltre considerare la reputazione relativa alle email e alla sicurezza. Un intervallo di IP pubblico potrebbe essere stato utilizzato per l'hosting, la distribuzione di email, i servizi proxy, i servizi VPN o altri carichi di lavoro. Se il blocco è stato associato ad abusi, spam, malware o traffico sospetto, il nuovo operatore potrebbe dover dedicare tempo a ripristinarne la reputazione dopo il trasferimento. Il RIPE Database non fornisce una cronologia completa della reputazione, ma può aiutare a identificare gli operatori precedenti e i punti rilevanti per ulteriori indagini.Un processo professionale di trasferimento IPv4 dovrebbe pertanto includere la due diligence sul registro, la verifica legale, la pianificazione tecnica, la preparazione per la sicurezza del routing, la revisione del contratto e la convalida post-trasferimento. Il RIPE Database costituisce una base preziosa per questo processo, ma dovrebbe essere utilizzato insieme ad altre fonti di informazioni.

Come le aziende dovrebbero mantenere i propri dati nel database RIPE

Un'azienda dovrebbe considerare la manutenzione del RIPE Database come una responsabilità operativa continuativa. L'approccio più efficace consiste nell'assegnare una responsabilità interna chiara. Un team o un ruolo designato dovrebbe essere responsabile del monitoraggio delle modifiche ai dati aziendali, alle risorse IP, agli ASN, ai contatti, agli oggetti di instradamento e ai record RPKI.L'azienda dovrebbe riesaminare periodicamente i propri record pubblici. Dovrebbe confermare che i nomi delle organizzazioni siano aggiornati, che i contatti tecnici siano raggiungibili, che i contatti per gli abusi siano monitorati, che i controlli del maintainer siano accessibili, che gli oggetti di instradamento corrispondano agli annunci BGP effettivi e che le ROA RPKI siano coerenti con la politica di instradamento.

Una revisione è particolarmente importante prima di apportare modifiche significative alla rete. Se l'azienda aggiunge un secondo provider di transito, si trasferisce in un nuovo data center, modifica la propria architettura BGP, acquisisce un nuovo blocco IPv4, riceve risorse IPv6, cambia il proprio LIR sponsor o ristruttura la propria entità legale, i dati del registro dovrebbero essere esaminati nell'ambito del piano di progetto.Le aziende che non dispongono internamente di competenze sulle risorse Internet possono collaborare con un LIR sponsor, un consulente di rete, un provider di servizi gestiti o un ingegnere BGP esperto. L'obiettivo non è semplicemente completare un modulo del registro. L'obiettivo è garantire che i dati legali, i dati tecnici, la policy di routing, i controlli di sicurezza e i processi operativi funzionino insieme.

Il database RIPE fa parte della vostra infrastruttura Internet

Il RIPE Database è molto più di uno strumento pubblico di ricerca. È un registro centrale per indirizzi IP, prefissi IPv6, ASN, record di routing, organizzazioni, contatti e maintainer nell’area di servizio del RIPE NCC. Per le aziende che gestiscono infrastrutture Internet pubbliche, i suoi record possono influenzare l’accettazione degli instradamenti, la risposta agli incidenti, la conformità, la gestione delle risorse IP e la reputazione della rete.

Una presenza correttamente mantenuta nel database RIPE favorisce la trasparenza e la fiducia tecnica. Aiuta i provider upstream a comprendere quali prefissi una rete dovrebbe annunciare. Aiuta i team di sicurezza a individuare i contatti pertinenti. Aiuta le aziende a convalidare le risorse prima di un trasferimento IPv4. Aiuta gli operatori di rete a mantenere coerenti le informazioni su ASN, oggetti route e RPKI.Le aziende dovrebbero utilizzare il database con attenzione e tenerne presenti i limiti. Un oggetto del database non costituisce una garanzia di visibilità BGP attiva, titolarità legale o qualità della reputazione. È una componente importante di un più ampio processo di gestione dell'infrastruttura Internet. Il modello operativo più solido combina oggetti accurati nel database RIPE con una configurazione BGP corretta, ROA RPKI validi, accesso sicuro al maintainer, documentazione organizzativa aggiornata, una gestione affidabile degli abusi e un monitoraggio continuo.

Per qualsiasi azienda che utilizzi un ASN del RIPE NCC, risorse IPv4, prefissi IPv6 o il routing BGP, mantenere registrazioni accurate nel RIPE Database dovrebbe essere considerato una responsabilità fondamentale della gestione della rete.