7. Security Considerations (Considerazioni sulla sicurezza)

Questa sezione delinea i problemi di sicurezza relativi a SSM. Sono trattati i seguenti argomenti: IPsec, attacchi Denial of Service, falsificazione della sorgente e problemi di sicurezza collegati all'ambito amministrativo.

7.1. IPsec and SSM (IPsec e SSM)

L'IPsec Authentication Header (AH) e l'Encapsulating Security Payload (ESP) possono essere usati per proteggere il traffico SSM, se i ricevitori usano un'implementazione IPsec capace di multicast, come richiesto in [RFC4301].

7.2. SSM and RFC 2401 IPsec Caveats (Avvertenze su SSM e IPsec RFC 2401)

Per le implementazioni esistenti di IPsec RFC 2401, ora sostituito da [RFC4301], esistono alcune avvertenze relative a SSM. In IPsec RFC 2401, l'indirizzo sorgente non viene usato come parte della chiave nella ricerca nella SAD. Di conseguenza, due mittenti che per caso usano lo stesso indirizzo di destinazione SSM e lo stesso Security Parameter Index (SPI) entrano in "collisione" nella SAD di qualsiasi host che riceva entrambi i canali. Poiché gli indirizzi di canale e gli SPI sono allocati autonomamente dai mittenti, non esiste un mezzo ragionevole per garantire che ciascun mittente usi un indirizzo di destinazione o uno SPI univoco.

Si verifica un problema se un ricevitore si iscrive simultaneamente a due canali non correlati che usano IPsec, le cui sorgenti usano per caso lo stesso indirizzo IP di destinazione (IPDA) e lo stesso SPI IPsec. Poiché gli indirizzi di destinazione dei canali sono allocati autonomamente dai mittenti, due host qualunque possono usare simultaneamente lo stesso indirizzo di destinazione, e non esiste un mezzo ragionevole per garantire che ciò non accada. Tuttavia, la tupla <IPDA,SPI> è composta da 56 bit che sono generalmente scelti in modo casuale, 24 bit dell'indirizzo IP di destinazione e 32 bit dello SPI, e una collisione casuale è improbabile.

Se si verifica una collisione di questo tipo, il ricevitore non potrà ricevere simultaneamente traffico protetto da IPsec dalle due sorgenti in collisione. Un ricevitore può rilevare questa condizione notando che riceve traffico da due sorgenti diverse con lo stesso SPI e lo stesso indirizzo di destinazione SSM.

7.3. Denial of Service (Denial of Service)

Una richiesta di iscrizione crea stato (S,G) in un router per registrare l'iscrizione, invoca elaborazione su quel router e può causare elaborazione anche nei router vicini. Un host può condurre un attacco Denial of Service richiedendo un grande numero di iscrizioni. Il Denial of Service può verificarsi se:

• arriva una grande quantità di traffico che altrimenti non sarebbe desiderata, consumando risorse di rete per consegnarlo e risorse dell'host per scartarlo;

• nei router di rete viene creato molto stato multicast specifico della sorgente, usando memoria e risorse CPU del router per memorizzare ed elaborare tale stato; oppure

• viene generata una grande quantità di traffico di controllo per gestire lo stato specifico della sorgente, usando CPU dei router e larghezza di banda della rete.

Per ridurre il danno prodotto da un attacco di questo tipo, un router PUÒ disporre di opzioni di configurazione che limitano, ad esempio:

• La frequenza totale con cui tutti gli host su una singola interfaccia possono avviare iscrizioni, per limitare il danno causato da attacchi con indirizzo sorgente falsificato.

• Il numero totale di iscrizioni che possono essere avviate da una singola interfaccia o da un singolo host.

Tuttavia, qualsiasi decisione dell'implementatore di limitare artificialmente la frequenza o il numero delle iscrizioni dovrebbe essere presa con cautela, poiché applicazioni future potrebbero usare grandi numeri di canali. Limiti rigidi sulla frequenza o sul numero di iscrizioni ai canali ostacolerebbero il dispiegamento di tali applicazioni.

Un router DOVREBBE verificare che la sorgente di una richiesta di iscrizione sia un indirizzo valido per l'interfaccia su cui la richiesta è stata ricevuta. Non farlo aggraverebbe un attacco con indirizzo sorgente falsificato.

Questi attacchi non sono esclusivi di SSM: sono presenti anche nell'any-source multicast.

7.4. Spoofed Source Addresses (Indirizzi sorgente falsificati)

Falsificando l'indirizzo sorgente in un datagramma, un attaccante può potenzialmente violare il modello di servizio SSM trasmettendo datagrammi su un canale appartenente a un altro host. Pertanto, un'applicazione che richiede autenticazione forte non dovrebbe assumere che tutti i pacchetti arrivati su un canale siano stati inviati dalla sorgente richiesta senza meccanismi di autenticazione di livello superiore. Ad esempio, l'IPsec Authentication Header [RFC2401, RFC4301] può essere usato per autenticare la sorgente di una trasmissione SSM.

Un certo grado di protezione contro gli indirizzi sorgente falsificati nel multicast è già abbastanza diffuso, perché i protocolli di routing multicast IP comunemente dispiegati [PIM-DM, PIM-SM, DVMRP] incorporano un "reverse-path forwarding check" che verifica che un pacchetto multicast sia arrivato sull'interfaccia attesa per il suo indirizzo sorgente. I protocolli di routing usati per SSM DOVREBBERO incorporare un controllo di questo tipo.

Il Source Routing [RFC791], sia Loose sia Strict, in combinazione con la falsificazione dell'indirizzo sorgente può essere usato per consentire a un impostore della vera sorgente del canale di iniettare pacchetti in un canale SSM. Per impostazione predefinita, un router SSM DOVREBBE non consentire il source routing verso un indirizzo di destinazione SSM. Un router PUÒ avere un'opzione di configurazione per consentire il source routing. Sono inoltre fortemente incoraggiati meccanismi anti-spoofing della sorgente, come il filtraggio degli indirizzi sorgente ai margini della rete.

7.5. Administrative Scoping (Ambito amministrativo)

L'ambito amministrativo non dovrebbe essere considerato una misura di sicurezza [ADMIN-SCOPE]; tuttavia, in alcuni casi fa parte di una soluzione di sicurezza. Va osservato che per il multicast specifico della sorgente IPv4 non esiste alcun ambito amministrativo. Un approccio alternativo consiste nel configurare manualmente filtri di traffico per creare tale ambito quando necessario.

Inoltre, per IPv6, né l'ambito dell'indirizzo sorgente né quello dell'indirizzo di destinazione dovrebbero essere usati come misura di sicurezza. In alcuni router IPv6 attualmente dispiegati, cioè quelli non conformi a [SCOPINGv6], i confini di ambito non sono sempre applicati a tutti gli indirizzi sorgente; ad esempio, un'implementazione può filtrare indirizzi link-local e nient'altro. Un router di questo tipo può inoltrare erroneamente un canale SSM (S,G) attraverso un confine di ambito per S.