Changement du comportement par défaut pour les diffusions dirigées dans les routeurs

Statut du présent mémoire

Ce document spécifie les bonnes pratiques en cours de l'Internet pour la communauté de l'Internet, et appelle à discussion et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.

1.   Introduction

Exigences pour les routeurs [1] spécifie que les routeurs doivent recevoir et transmettre les diffusions dirigées. Il spécifie aussi que les routeurs DOIVENT avoir une option pour désactiver ce dispositif, et que cette option DOIT revenir par défaut à permettre la réception et la transmission des diffusions dirigées. Bien que les diffusions dirigées aient leur utilité, leur utilisation sur le cœur de réseau Internet paraît ne comprendre que des attaques malveillantes contre les autres réseaux.

Changer le comportement exigé par défaut pour les routeurs aiderait à s'assurer que les nouveaux routeurs connectés à l'Internet n'ajoutent pas aux problèmes déjà présents.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la RFC 2119.

2.   Discussion

Des attaques dommageables de déni de service ont conduit à la rédaction de [2] sur le filtrage d'entrée. De nombreux fournisseurs de réseaux et de réseaux d'entreprises ont pris en compte l'utilisation de ces méthodes pour s'assurer que leurs réseaux ne sont pas la source de telles attaques.

Une tendance récente des attaques Smurf [3] est de cibler les réseaux qui permettent des diffusions dirigées à partir de l'extérieur de leurs réseaux. En permettant des diffusions dirigées, ces systèmes deviennent des "amplificateurs de Smurf."

Bien que la poursuite de la mise en œuvre de filtres d'entrée reste la meilleure façon de limiter ces attaques, l'interdiction des diffusions dirigées devrait aussi être prioritaire.

Les fournisseurs de services réseau et les opérateurs de réseaux d'entreprise sont invités à s'assurer que leurs réseaux ne sont pas susceptibles d'émettre des paquets de diffusion dirigée d'origine externe.

IP Mobile [4] a des dispositions pour utiliser les diffusions dirigées afin de découvrir l'agent de façon dynamique dans un nœud mobile. Bien que certaines mises en œuvre prennent en charge ce dispositif, il n'apparaît pas clairement qu'il soit utile. D'autres méthodes pour arriver au même résultat sont documentées dans [5]. Il peut valoir la peine de considérer le retrait les formules sur l'utilisation des diffusions dirigées alors qu'avance la normalisation de l'IP Mobile.

3.   Recommandation

Exigences pour les routeurs [1] est mis à jour comme suit :

Le paragraphe 4.2.2.11 (d) est remplacé par :

(d) { <Network-prefix>, -1 }

Diffusion dirigée – diffusion dirigée sur les préfixes de réseau spécifiés. Elle NE DOIT PAS être utilisée comme adresse de source. Un routeur PEUT générer des paquets Diffusion dirigée réseau. Un routeur PEUT avoir une option de configuration lui permettant de recevoir des paquets de diffusion dirigée, cependant cette option DOIT être désactivée par défaut, et donc le routeur NE DOIT PAS recevoir des paquets Diffusion dirigée réseau si ce n'est pas spécifiquement configuré par l'utilisateur final.

Le paragraphe 5.3.5.2, second alinéa est remplacé par :

Un routeur PEUT avoir une option pour activer la réception de diffusion dirigées sur des préfixes de réseau sur une interface et PEUT avoir une option pour activer la transmission de diffusions dirigées sur des préfixes de réseau. Ces options DOIVENT par défaut bloquer la réception et bloquer la transmission des diffusion dirigées sur des préfixes de réseaux.

4.   Considérations pour la sécurité

L'objectif du présent document est de réduire l'efficacité de certains types d'attaques de déni de service.

5.   Références

[1]   F. Baker, "Exigences pour les routeurs IP version 4", RFC 1812, juin 1995.

[2]   P. Ferguson et D. Senie, "Filtrage d'entrée", RFC 2267, janvier 1998.

[3]   Voir les pages de Craig Huegen à : http://www.quadrunner.com/~chuegen/smurf.txt, et l'avis du CERT à : http://www.cert.org/advisories/CA-98.01.smurf.html

[4]   C. Perkins, "Prise en charge de la mobilité IP", RFC 2002, octobre 1996.

[5]   P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Address Allocation Extensions", Travail en cours.

6.   Remerciements

L'auteur tient à remercier Brandon Ross de Mindspring et Gabriel Montenegro de Sun pour leurs apports.

7.   Adresse de l'auteur

Daniel Senie

Amaranth Networks Inc.

324 Still River Road

Bolton, MA 01740

téléphone : (978) 779-6813

mél : dts@senie.com

8.   Déclaration de copyright

 Copyright (C) The Internet Society (1999). Tous droits réservés.  

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.  Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

 Le présent document et les informations qu’il contient sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par Internet Society.