1. Introduction (Introduzione)

1. Introduction (Introduzione)

Una rotta BGP associa un prefisso di indirizzo con un insieme di sistemi autonomi (AS) che identificano il percorso interdominio che il prefisso ha attraversato sotto forma di annunci BGP. Questo insieme è rappresentato come attributo AS_PATH in BGP [RFC4271] e inizia con l'AS che ha originato il prefisso. Per contribuire a ridurre le minacce ben note contro BGP, inclusi gli annunci errati di prefissi e gli attacchi man-in-the-middle, uno dei requisiti di sicurezza è la capacità di validare l'AS di origine delle rotte BGP. Più specificamente, è necessario validare che il numero AS che sostiene di originare un prefisso di indirizzo (come derivato dall'attributo AS_PATH della rotta BGP) sia effettivamente autorizzato dal titolare del prefisso a farlo. Questo documento descrive un semplice meccanismo di validazione per soddisfare parzialmente questo requisito.

La Resource Public Key Infrastructure (RPKI, Infrastruttura a chiave pubblica delle risorse) descrive un approccio per costruire un database formalmente verificabile di indirizzi IP e numeri AS come risorse. L'architettura complessiva di RPKI come definita in [RFC6480] consiste di tre componenti principali:

• un'infrastruttura a chiave pubblica (PKI) con i necessari oggetti certificato,

• oggetti di routing firmati digitalmente, e

• un sistema di repository distribuito per contenere gli oggetti che supporterebbe anche il recupero periodico.

Il sistema RPKI è basato su certificati di risorse che definiscono estensioni a X.509 per rappresentare indirizzi IP e identificatori AS [RFC3779], da cui il nome RPKI. Le autorizzazioni di origine delle rotte (ROA, Route Origin Authorizations) [RFC6482] sono oggetti firmati digitalmente separati che definiscono associazioni tra AS e blocchi di indirizzi IP. Infine, il sistema di repository è gestito in modo distribuito attraverso l'IANA, la gerarchia del Regional Internet Registry (RIR) e gli ISP.

Per beneficiare del sistema RPKI, si prevede che le parti affidatarie a livello di AS o organizzazione ottengano una copia locale della collezione di oggetti firmati, verifichino le firme e li elaborino. La cache deve anche essere aggiornata periodicamente. Il meccanismo di accesso esatto utilizzato per recuperare la cache locale è al di fuori dell'ambito di questo documento.

I singoli speaker BGP possono utilizzare i dati elaborati contenuti nella cache locale per validare gli annunci BGP. I dettagli del protocollo per recuperare i dati elaborati dalla cache locale agli speaker BGP sono al di fuori dell'ambito di questo documento (fare riferimento a [RFC6810] per un tale meccanismo). Questo documento propone un mezzo mediante il quale uno speaker BGP può utilizzare i dati elaborati per assegnare uno "stato di validazione" a ciascun prefisso in un messaggio BGP UPDATE ricevuto.

Si noti che l'attestazione completa del percorso rispetto all'attributo AS_PATH di una rotta è al di fuori dell'ambito di questo documento.

Come il DNS, l'RPKI globale presenta solo una vista vagamente coerente, a seconda dei tempi, degli aggiornamenti, del recupero, ecc. Pertanto, una cache o un router può avere dati diversi su un particolare prefisso rispetto a un'altra cache o router. Non esiste una "correzione" per questo; è la natura dei dati distribuiti con cache distribuite.

Sebbene RPKI fornisca il contesto per questo documento, è altrettanto possibile utilizzare qualsiasi altro database in grado di mappare i prefissi ai loro AS di origine autorizzati. Ogni database distinto avrà le proprie caratteristiche operative e di sicurezza particolari; tali caratteristiche sono al di fuori dell'ambito di questo documento.