5. Considerazioni sulla sicurezza
Questa sezione identifica le minacce a cui LDP può essere vulnerabile e discute i mezzi con cui tali minacce potrebbero essere mitigate.
5.1. Spoofing
Esistono due tipi di comunicazione LDP che potrebbero essere bersaglio di un attacco di spoofing.
-
Scambi di discovery trasportati da UDP
Gli LSR indicano la loro disponibilità a stabilire e mantenere sessioni LDP inviando periodicamente messaggi Hello. La ricezione di un Hello serve a creare una nuova "Hello adjacency", se non ne esiste già una, o ad aggiornarne una esistente. Lo spoofing di un pacchetto Hello per un'adiacenza esistente può causare la scadenza dell'adiacenza e ciò può comportare la terminazione della sessione associata. Ciò può verificarsi quando l'Hello falsificato specifica un Hold Time piccolo, facendo sì che il ricevitore si aspetti dei messaggi Hello entro questo intervallo, mentre il vero vicino continua a inviare messaggi Hello alla frequenza inferiore precedentemente concordata.
Gli LSR direttamente collegati a livello di collegamento si scambiano messaggi Basic Hello sul collegamento. La minaccia di Basic Hello falsificati può essere ridotta:
o accettando i Basic Hello solo su interfacce a cui sono direttamente collegati LSR di cui ci si può fidare.
o ignorando i Basic Hello non indirizzati al gruppo multicast All Routers on this Subnet.
Gli LSR non direttamente collegati a livello di collegamento possono usare messaggi Extended Hello per indicare la disponibilità a stabilire una sessione LDP. Un LSR può ridurre la minaccia di Extended Hello falsificati filtrandoli e accettando solo quelli originati da sorgenti consentite da una access list.
-
Comunicazione di sessione trasportata da TCP
LDP specifica l'uso della TCP MD5 Signature Option per fornire l'autenticità e l'integrità dei messaggi di sessione.
La [RFC2385] afferma che l'autenticazione MD5 è oggi considerata da alcuni troppo debole per questa applicazione. Sottolinea inoltre che un'opzione TCP simile con un algoritmo di hash più forte (cita SHA-1 come esempio) potrebbe essere impiegata. A nostra conoscenza, nessuna tale opzione TCP è stata definita e implementata. Tuttavia, osserviamo che LDP può usare qualsiasi tecnica di message digest TCP disponibile, e quando ne verrà specificata e implementata una più forte di MD5, aggiornare LDP per usarla sarebbe relativamente semplice.
5.2. Privacy
LDP non fornisce alcun meccanismo per proteggere la privacy della distribuzione delle etichette.
I requisiti di sicurezza dei protocolli di distribuzione delle etichette sono essenzialmente identici a quelli dei protocolli che distribuiscono informazioni di instradamento. Fornendo un meccanismo per garantire l'autenticità e l'integrità dei suoi messaggi, LDP fornisce un livello di sicurezza almeno pari, ma non migliore, a quello che può essere fornito dai protocolli di instradamento stessi. La questione più generale se la privacy debba essere richiesta per i protocolli di instradamento esula dallo scopo del presente documento.
Si potrebbe sostenere che la distribuzione delle etichette richieda la privacy per affrontare la minaccia di spoofing delle etichette. Tuttavia, tale privacy non proteggerebbe dagli attacchi di spoofing delle etichette, poiché i pacchetti dati trasportano le etichette in chiaro. Inoltre, gli attacchi di spoofing delle etichette possono essere effettuati senza conoscere la FEC associata a un'etichetta.
Per evitare attacchi di spoofing delle etichette, è necessario garantire che i pacchetti dati etichettati siano etichettati da LSR fidati e che le etichette poste sui pacchetti siano apprese correttamente dagli LSR che le applicano.
5.3. Denial of Service
LDP fornisce due potenziali bersagli per attacchi di Denial of Service (DoS):
-
Porta UDP nota per la Discovery LDP
Un amministratore di LSR può affrontare la minaccia di attacchi DoS tramite Basic Hello assicurandosi che l'LSR sia direttamente collegato solo a peer di cui ci si può fidare che non avvieranno un tale attacco. Le interfacce verso peer interni al dominio dell'amministratore non dovrebbero rappresentare una minaccia, poiché i peer interni sono sotto il controllo dell'amministratore. Le interfacce verso peer esterni al dominio rappresentano una potenziale minaccia poiché i peer esterni non lo sono. Un amministratore può ridurre tale minaccia collegando l'LSR solo a peer esterni di cui ci si può fidare che non avvieranno un attacco Basic Hello.
Gli attacchi DoS tramite Extended Hello sono potenzialmente una minaccia più seria. Questa minaccia può essere affrontata filtrando gli Extended Hello usando access list che definiscono gli indirizzi con cui la Extended Discovery è consentita. Tuttavia, eseguire il filtraggio richiede risorse dell'LSR.
In un ambiente in cui si può identificare una MPLS cloud fidata, gli LSR al bordo della cloud possono essere usati per proteggere gli LSR interni dagli attacchi DoS tramite Extended Hello filtrando gli Extended Hello originati all'esterno della MPLS cloud fidata, accettando solo quelli originati da indirizzi consentiti dalle access list. Questo filtraggio protegge gli LSR all'interno della cloud ma consuma risorse ai bordi.
-
Porta TCP nota per la sessione di LDP
Come altri protocolli del piano di controllo che usano TCP, LDP può essere bersaglio di attacchi DoS, come gli attacchi SYN. LDP non è più né meno vulnerabile a tali attacchi rispetto ad altri protocolli del piano di controllo che usano TCP.
La minaccia di tali attacchi può essere mitigata in una certa misura da quanto segue:
o Un LSR DOVREBBE (SHOULD) evitare ascolti TCP promiscui per la sessione di LDP. DOVREBBE (SHOULD) usare solo ascolti specifici per i peer scoperti. Ciò gli consente di scartare i pacchetti di attacco all'inizio della loro elaborazione, poiché è meno probabile che corrispondano a connessioni esistenti o in corso.
o L'uso dell'opzione MD5 aiuta in una certa misura, poiché impedisce che un SYN venga accettato a meno che il checksum del segmento MD5 sia valido. Tuttavia, il ricevitore deve calcolare il checksum prima di poter decidere di scartare un segmento SYN altrimenti accettabile.
o L'uso di meccanismi di access list applicati al confine della MPLS cloud in modo simile a quello suggerito sopra per gli Extended Hello può proteggere l'interno dagli attacchi originati dall'esterno della cloud.