RFC 4379 - 6. Security Considerations
6. Considérations de sécurité (Security Considerations)
Globalement, les besoins de sécurité de LSP ping sont similaires à ceux du ping ICMP.
Il existe au moins trois façons d'utiliser le mécanisme défini ici pour attaquer un LSR. Une attaque par déni de service en envoyant des MPLS echo request/reply pour accroître sa charge de travail. Une confusion de l'état de vie du plan de données MPLS en falsifiant, détournant, rejouant ou altérant les echo request et reply. Une obtention d'informations réseau par une source non autorisée exploitant LSP ping.
Pour éviter une attaque par déni de service, une implémentation RECOMMENDED de réguler le trafic LSP ping vers le plan de contrôle. Un limiteur de débit SHOULD être appliqué sur le port UDP bien connu défini ici.
Une attaque simple de rejeu et d'usurpation impliquant un echo reply falsifié ou rejoué est peu susceptible d'être efficace. Ces réponses doivent correspondre au Sender's Handle et au Sequence Number d'un echo request en cours. Un rejeu ne correspondant pas est ignoré car la séquence a avancé, laissant une petite fenêtre pour l'usurpation. Mais pour une défense plus forte, une implémentation MAY aussi vérifier la correspondance exacte du champ TimeStamp Sent.
Pour empêcher une source non autorisée d'obtenir des informations réseau via MPLS echo request, une implémentation RECOMMENDED de fournir un moyen de vérifier l'adresse source du message echo request contre une liste de contrôle d'accès avant réception.
On ne sait pas empêcher le détournement (non livraison) d'un echo request ou reply ; mais si ces messages sont détournés, LSP ping signalera que le plan de données ne fonctionne pas comme prévu.
La protection des données portées par les echo request et reply ne semble pas (actuellement) critique, bien que certains considèrent l'état du plan de données MPLS comme confidentiel. Mais une implémentation SHOULD fournir un moyen de filtrer les adresses auxquelles un echo reply peut être envoyé.
Bien que ce document utilise spécialement les adresses 127/8, elles sont uniquement combinées au port UDP 3503. De plus, ces paquets ne sont traités que par les routeurs. Tous les autres hôtes MUST traiter selon RFC 1122 tout paquet à destination dans 127/8. Tout paquet reçu par un routeur à destination dans 127/8 mais dont le port UDP de destination n'est pas 3503 MUST être traité selon RFC 1812. En particulier, le comportement par défaut est de traiter les paquets à destination 127/8 comme des "martians" (adresses erronees).