5. Considérations de sécurité

Cette section identifie les menaces auxquelles LDP peut être vulnérable et examine les moyens de les atténuer.

5.1. Usurpation (Spoofing)

Il existe deux types de communication LDP susceptibles d'être la cible d'une attaque par usurpation (spoofing).

1. Les échanges de découverte transportés par UDP

   Les LSR indiquent leur volonté d'établir et de maintenir des sessions LDP en envoyant périodiquement des messages Hello. La réception d'un Hello sert à créer une nouvelle "Hello adjacency", si elle n'existe pas déjà, ou à rafraîchir une Hello adjacency existante. L'usurpation d'un paquet Hello pour une Hello adjacency existante peut faire expirer l'adjacence, ce qui peut entraîner la terminaison de la session associée. Cela peut se produire lorsque le Hello usurpé spécifie un petit Hold Time, amenant le récepteur à attendre des Hello dans cet intervalle, tandis que le véritable voisin continue d'envoyer des Hello à la fréquence inférieure précédemment convenue.

   Les LSR directement connectés au niveau de la liaison échangent des messages Basic Hello sur la liaison. La menace de Basic Hellos usurpés peut être réduite en :

   o N'acceptant les Basic Hellos que sur les interfaces auxquelles des LSR dignes de confiance sont directement connectés.

   o Ignorant les Basic Hellos qui ne sont pas adressés au groupe multicast All Routers on this Subnet.

   Les LSR qui ne sont pas directement connectés au niveau de la liaison peuvent utiliser des messages Extended Hello pour indiquer leur volonté d'établir une session LDP. Un LSR peut réduire la menace d'Extended Hellos usurpés en les filtrant et en n'acceptant que ceux provenant de sources autorisées par une liste d'accès.

2. La communication de session transportée par TCP

   LDP spécifie l'utilisation de l'option TCP MD5 Signature pour assurer l'authenticité et l'intégrité des messages de session.

   [RFC2385] affirme que l'authentification MD5 est aujourd'hui considérée par certains comme trop faible pour cette application. Il souligne également qu'une option TCP similaire dotée d'un algorithme de hachage plus robuste (il cite SHA-1 en exemple) pourrait être déployée. À notre connaissance, aucune telle option TCP n'a été définie ni déployée. Toutefois, nous notons que LDP peut utiliser toutes les techniques de condensé de message TCP disponibles, et que lorsqu'une technique plus robuste que MD5 sera spécifiée et mise en œuvre, faire évoluer LDP pour l'utiliser serait relativement simple.

5.2. Confidentialité

LDP ne fournit aucun mécanisme permettant de protéger la confidentialité de la distribution d'étiquettes.

Les exigences de sécurité des protocoles de distribution d'étiquettes sont essentiellement identiques à celles des protocoles qui distribuent des informations de routage. En fournissant un mécanisme pour garantir l'authenticité et l'intégrité de ses messages, LDP offre un niveau de sécurité au moins aussi bon que celui que peuvent fournir les protocoles de routage eux-mêmes, mais pas meilleur. La question plus générale de savoir si la confidentialité devrait être exigée pour les protocoles de routage dépasse le cadre de ce document.

On pourrait soutenir que la distribution d'étiquettes exige la confidentialité pour contrer la menace d'usurpation d'étiquettes. Toutefois, cette confidentialité ne protégerait pas contre les attaques par usurpation d'étiquettes, puisque les paquets de données transportent les étiquettes en clair. De plus, les attaques par usurpation d'étiquettes peuvent être menées sans connaître la FEC liée à une étiquette.

Pour éviter les attaques par usurpation d'étiquettes, il est nécessaire de garantir que les paquets de données étiquetés sont étiquetés par des LSR dignes de confiance et que les étiquettes apposées sur les paquets sont correctement apprises par les LSR qui les apposent.

5.3. Déni de service

LDP offre deux cibles potentielles à des attaques par déni de service (Denial of Service, DoS) :

1. Port UDP bien connu pour la découverte LDP

   Un administrateur de LSR peut parer la menace d'attaques DoS via des Basic Hellos en s'assurant que le LSR n'est directement connecté qu'à des pairs dont on peut attendre qu'ils n'initient pas une telle attaque. Les interfaces vers des pairs internes au domaine de l'administrateur ne devraient pas représenter une menace, puisque les pairs internes sont sous le contrôle de l'administrateur. Les interfaces vers des pairs extérieurs au domaine représentent une menace potentielle, puisque les pairs extérieurs ne sont pas sous son contrôle. Un administrateur peut réduire cette menace en ne connectant le LSR qu'à des pairs extérieurs dont on peut attendre qu'ils n'initient pas une attaque par Basic Hello.

   Les attaques DoS via des Extended Hellos sont potentiellement une menace plus grave. Cette menace peut être traitée en filtrant les Extended Hellos au moyen de listes d'accès qui définissent les adresses avec lesquelles la découverte étendue (Extended Discovery) est autorisée. Toutefois, effectuer ce filtrage consomme des ressources du LSR.

   Dans un environnement où un nuage MPLS de confiance peut être identifié, les LSR à la périphérie du nuage peuvent servir à protéger les LSR intérieurs contre les attaques DoS via des Extended Hellos en filtrant les Extended Hellos provenant de l'extérieur du nuage MPLS de confiance et en n'acceptant que ceux provenant d'adresses autorisées par des listes d'accès. Ce filtrage protège les LSR à l'intérieur du nuage mais consomme des ressources aux extrémités.

2. Port TCP bien connu pour l'établissement de session LDP

   Comme les autres protocoles de plan de contrôle qui utilisent TCP, LDP peut être la cible d'attaques DoS, telles que les attaques SYN. LDP n'est ni plus ni moins vulnérable à de telles attaques que les autres protocoles de plan de contrôle qui utilisent TCP.

   La menace de telles attaques peut être quelque peu atténuée par ce qui suit :

   o Un LSR DEVRAIT (SHOULD) éviter les écoutes TCP promiscuitaires pour l'établissement de session LDP. Il DEVRAIT (SHOULD) n'utiliser que des écoutes spécifiques aux pairs découverts. Cela lui permet d'abandonner les paquets d'attaque tôt dans leur traitement, car ils sont moins susceptibles de correspondre à des connexions existantes ou en cours.

   o L'utilisation de l'option MD5 aide quelque peu, puisqu'elle empêche un SYN d'être accepté à moins que la somme de contrôle du segment MD5 ne soit valide. Toutefois, le récepteur doit calculer la somme de contrôle avant de pouvoir décider d'écarter un segment SYN par ailleurs acceptable.

   o L'utilisation de mécanismes de listes d'accès appliqués à la frontière du nuage MPLS d'une manière similaire à celle suggérée ci-dessus pour les Extended Hellos peut protéger l'intérieur contre les attaques provenant de l'extérieur du nuage.