RFC 4379 - 6. Security Considerations
6. Considerazioni sulla sicurezza (Security Considerations)
Nel complesso, le esigenze di sicurezza di LSP ping sono simili a quelle di ICMP ping.
Vi sono almeno tre modi di sfruttare il meccanismo qui definito per attaccare un LSR. Un attacco di negazione del servizio inviando MPLS echo request/reply per aumentarne il carico di lavoro. Confondere lo stato di vivacità del piano dati MPLS falsificando, dirottando, riproducendo o altrimenti alterando MPLS echo request e reply. Ottenere informazioni di rete tramite una fonte non autorizzata che sfrutta LSP ping.
Per evitare un potenziale attacco di negazione del servizio, è RECOMMENDED che un'implementazione regoli il traffico LSP ping inviato al piano di controllo. Un limitatore di velocità dovrebbe (SHOULD) essere applicato alla porta UDP ben nota qui definita.
Un semplice attacco di replay e spoofing con un echo reply falsificato o riprodotto è poco probabilmente efficace. Tali risposte devono corrispondere al Sender's Handle e al Sequence Number di un MPLS echo request non completato. Un replay non corrispondente è scartato poiché la sequenza è avanzata, lasciando una piccola finestra per lo spoofing. Ma per una difesa più forte, un'implementazione MAY anche verificare la corrispondenza esatta del campo TimeStamp Sent.
Per impedire a una fonte non autorizzata di ottenere informazioni di rete tramite MPLS echo request, è RECOMMENDED che un'implementazione fornisca un mezzo per verificare l'indirizzo sorgente del messaggio echo request contro un elenco di controllo di accesso prima della ricezione.
Non è chiaro come impedire il dirottamento (mancata consegna) di echo request o reply; ma se tali messaggi sono effettivamente dirottati, LSP ping segnalerà che il piano dati non funziona come previsto.
La protezione dei dati trasportati negli MPLS echo request e reply non sembra (al momento) critica, sebbene alcuni possano considerare riservata la conoscenza dello stato del piano dati MPLS. Ma un'implementazione SHOULD fornire un mezzo per filtrare gli indirizzi a cui un echo reply può essere inviato.
Sebbene questo documento usi in modo speciale gli indirizzi 127/8, essi sono usati solo in combinazione con la porta UDP 3503. Inoltre, tali pacchetti sono elaborati solo dai router. Tutti gli altri host MUST trattare secondo RFC 1122 ogni pacchetto con destinazione nell'intervallo 127/8. Ogni pacchetto ricevuto da un router con destinazione nell'intervallo 127/8 ma porta UDP di destinazione diversa da 3503 MUST essere trattato secondo RFC 1812. In particolare, il comportamento predefinito è trattare i pacchetti verso 127/8 come "martians" (indirizzi non validi).