Aller au contenu principal

10. Security Considerations

10. Security Considerations​

Nous examinons les conséquences d'un message falsifié de chaque type.

Message de requête (Query Message) :

Un message de requête falsifié provenant d'une machine ayant une adresse IP inférieure à celle du questionneur (Querier) actuel entraînera l'attribution des fonctions de questionneur au faussaire. Si le faussaire n'envoie ensuite plus de messages de requête, le minuteur « Autre questionneur présent » (Other Querier Present) des autres routeurs expirera et l'un d'eux reprendra le rôle de questionneur. Pendant ce temps, si le faussaire ignore les messages de départ (Leave Messages), le trafic pourrait circuler vers des groupes sans membres pendant une durée pouvant aller jusqu'à [Intervalle d'appartenance au groupe] (Group Membership Interval).

Un message de requête falsifié envoyé à un groupe avec des membres incitera les hôtes membres du groupe à signaler leur appartenance. Cela génère une petite quantité de trafic supplémentaire sur le réseau local, mais ne cause aucun problème de protocole.

Messages de rapport (Report messages) :

Un message de rapport falsifié peut amener les routeurs multicast à penser qu'il y a des membres d'un groupe sur un sous-réseau alors qu'il n'y en a pas. Les messages de rapport falsifiés provenant du sous-réseau local n'ont aucun sens, car rejoindre un groupe sur un hôte est généralement une opération non privilégiée, de sorte qu'un utilisateur local peut trivialement obtenir le même résultat sans falsifier aucun message. Les messages de rapport falsifiés provenant de sources externes sont plus gênants ; il existe deux défenses contre les rapports falsifiés de l'extérieur :

  • Ignorez le rapport si vous ne pouvez pas identifier l'adresse source du paquet comme appartenant à un sous-réseau attribué à l'interface sur laquelle le paquet a été reçu. Cette solution signifie que les rapports envoyés par des hôtes mobiles sans adresse sur le sous-réseau local seront ignorés.

  • Ignorez les messages de rapport sans options d'alerte routeur (Router Alert) [RFC 2113], et exigez que les routeurs ne transmettent pas les messages de rapport. (Cette exigence n'est pas une exigence de filtrage généralisé dans le chemin de transfert, car les paquets contiennent déjà des options d'alerte routeur). Cette solution rompt la compatibilité ascendante avec les implémentations des versions antérieures de cette spécification qui ne nécessitaient pas d'alerte routeur.

Un message de rapport de version 1 falsifié peut placer un routeur dans l'état « membres de version 1 présents » pour un groupe particulier, ce qui signifie que le routeur ignorera les messages de départ. Cela peut entraîner l'envoi de trafic vers des groupes sans membres pendant une durée pouvant aller jusqu'à [Intervalle d'appartenance au groupe]. Il existe deux défenses contre les rapports v1 falsifiés :

  • Pour se défendre contre les rapports v1 provenant de l'extérieur, ignorez le rapport si vous ne pouvez pas identifier l'adresse source du paquet comme appartenant à un sous-réseau attribué à l'interface sur laquelle le paquet a été reçu. Cette solution signifie que les rapports v1 envoyés par des hôtes mobiles sans adresse sur le sous-réseau local seront ignorés.

  • Fournissez aux routeurs un commutateur de configuration pour ignorer complètement les messages de version 1. Cela rompt la compatibilité automatique avec les hôtes de version 1 et ne doit donc être utilisé que dans les situations où le « départ rapide » (fast leave) est critique. Cette solution protège également contre les rapports de version 1 falsifiés provenant du sous-réseau local.

Message de départ (Leave message) :

Un message de départ falsifié amènera le questionneur à envoyer des requêtes spécifiques au groupe (Group-Specific Queries) pour le groupe en question. Cela entraîne un traitement supplémentaire sur chaque routeur et sur chaque membre du groupe, mais ne peut pas entraîner la perte du trafic souhaité. Il existe deux défenses contre les messages de départ falsifiés de l'extérieur :

  • Ignorez le message de départ si vous ne pouvez pas identifier l'adresse source du paquet comme appartenant à un sous-réseau attribué à l'interface sur laquelle le paquet a été reçu. Cette solution signifie que les messages de départ envoyés par des hôtes mobiles sans adresse sur le sous-réseau local seront ignorés.

  • Ignorez les messages de départ sans options d'alerte routeur [RFC 2113], et exigez que les routeurs ne transmettent pas les messages de départ. (Cette exigence n'est pas une exigence de filtrage généralisé dans le chemin de transfert, car les paquets contiennent déjà des options d'alerte routeur). Cette solution rompt la compatibilité ascendante avec les implémentations des versions antérieures de cette spécification qui ne nécessitaient pas d'alerte routeur.