12. Security Considerations (Considerazioni sulla sicurezza)
12. Security Considerations (Considerazioni sulla sicurezza)
Si ritiene che la maggior parte dei meccanismi di sicurezza faranno parte del servizio del database di mappatura quando si utilizzano processi del piano di controllo per ottenere mappature EID-to-RLOC. Per le mappature attivate dal piano dati descritte in questa specifica, la protezione contro lo spoofing dell'ETR viene fornita utilizzando il meccanismo di raggiungibilità dell'instradamento (vedere la Sezione 3), dimostrato tramite l'uso del campo 'Nonce' a 24 bit nell'header di incapsulamento LISP e del campo 'Nonce' a 64 bit nei messaggi di controllo LISP.
Il nonce, unito al fatto che gli ITR accettano solo Map-Reply che hanno richiesto, fornisce un livello di sicurezza di base simile sotto molti aspetti alla sicurezza sperimentata nell'attuale sistema di instradamento Internet. È difficile per gli attaccanti fuori percorso lanciare attacchi contro questi meccanismi LISP poiché non hanno il valore del nonce. È possibile inviare molti pacchetti per trovare accidentalmente il valore del nonce corretto, ma questo è di per sé un attacco Denial of Service (DoS). Gli attaccanti sul percorso possono eseguire attacchi più seri, ma gli attaccanti sul percorso possono anche lanciare attacchi seri nell'Internet corrente, inclusi intercettazione, blocco o reindirizzamento del traffico. Vedere la Sezione 6.1.5.1 per ulteriori discussioni su questo argomento.
LISP non si basa su una PKI o su sistemi di autenticazione più pesanti. Tali sistemi sfidano uno degli obiettivi principali di progettazione di LISP: la scalabilità.
La prevenzione degli attacchi DoS dipenderà dalle implementazioni che limitano la velocità del numero di Map-Request e Map-Reply del piano di controllo e di Map-Reply attivati dai dati.
Gli ITR implementati in modo errato o dannoso possono scegliere di ignorare Priority e Weight forniti dall'ETR nel suo Map-Reply. Tale orientamento del traffico sarà limitato al traffico inviato da questo sito ITR e non è più grave di un sito che avvia un attacco DoS di larghezza di banda su uno dei collegamenti di ingresso dell'ETR. Il sito dell'ITR generalmente non trarrà alcun beneficio dal non rispettare i Weight e potrebbe ottenere un servizio migliore rispettandoli.
Per gestire i tentativi di esaurimento della map-cache negli ITR/PITR, le implementazioni dovrebbero considerare l'impostazione di un limite massimo superiore sul numero di voci memorizzate e mantenere un elenco di riserva per siti speciali o frequentemente acceduti. Questo dovrebbe essere sotto il controllo della politica di configurazione impostata dall'amministratore di rete che gestisce l'ITR e il PITR. Quando esistono EID-Prefix sovrapposti tra più voci Map-Cache, l'integrità dell'insieme deve essere mantenuta completamente. Pertanto, se una voce più specifica non può essere aggiunta perché è stato raggiunto il limite massimo superiore, qualsiasi voce meno specifica non dovrebbe essere memorizzata nella map-cache.
Dato che gli ITR/PITR mantengono una cache delle mappature EID-to-RLOC, le dimensioni della cache e la manutenzione sono problemi da tenere a mente durante l'implementazione. È una buona idea installare strumentazione per rilevare il churn della cache. Gli esperimenti di implementazione verranno utilizzati per determinare quali politiche di gestione della cache funzionano meglio. In generale, è difficile difendersi dagli attacchi di churn della cache. Va notato che le cache troppo piccole negli ITR/PITR avranno un effetto negativo non solo sul sito o sull'area che supportano, ma potrebbero anche comportare un maggiore carico di Map-Request sul sistema di mappatura.
I dati di mappatura "Piggybacked" discussi nella Sezione 6.1.3 specificano come tali mappature vengono gestite e includono la possibilità per un ETR di accettare temporaneamente tali mappature prima della verifica quando opera in un ambiente "fidato". In questo caso, esiste una minaccia potenziale che mappature fasulle possano essere inserite (anche se solo per breve tempo) nella map-cache. Come indicato nella Sezione 6.1.3, un ETR deve essere configurato specificamente per operare in tale modalità e può considerare solo specifici ITR particolari come operanti anche nello stesso ambiente fidato.
Esiste un rischio per la sicurezza nel fatto che gli ETR stanno generando l'EID-Prefix a cui stanno rispondendo. Gli ETR possono rivendicare prefissi più corti di quelli per cui sono effettivamente responsabili. Vari meccanismi per migliorare o risolvere questo problema saranno oggetto di ricerca futura [LISP-SEC].
Lo spoofing degli indirizzi dell'header interno dei pacchetti dati incapsulati LISP è possibile, proprio come con qualsiasi meccanismo di tunneling. Un ITR DEVE verificare che l'indirizzo di origine di un pacchetto sia un EID nell'intervallo degli EID-Prefix del sito prima di incapsularlo. Un ETR DEVE disincapsulare e inoltrare solo datagrammi il cui indirizzo di destinazione dell'header interno corrisponde a uno dei propri intervalli EID-Prefix. Se, alla ricezione e al disincapsulamento, l'EID di destinazione di un datagramma non corrisponde a uno degli EID-Prefix configurati dell'ETR, l'ETR DEVE scartare quel datagramma. Se un pacchetto dati incapsulato LISP arriva a un ETR, dovrebbe confrontare l'indirizzo EID di origine dell'header interno e l'indirizzo RLOC di origine dell'header esterno con le mappature presenti nel database di mappatura. Quindi, quando si verifica un attacco di spoofing, l'indirizzo RLOC di origine dell'header esterno può essere utilizzato per tracciare l'attacco al sito di origine utilizzando gli strumenti operativi esistenti.
Questa specifica sperimentale non tratta la gestione automatica delle chiavi (AKM). Il BCP 107 [RFC4107] fornisce indicazioni in quest'area. Inoltre, al momento della stesura, è in corso un considerevole lavoro per migliorare la sicurezza del sistema di instradamento [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]. Il lavoro futuro su LISP dovrebbe affrontare i problemi discussi nel BCP 107 insieme ad altre considerazioni di sicurezza aperte, il che potrebbe richiedere modifiche a questa specifica.