12. Considérations de sécurité

Considérations de sécurité

L'introduction de protocoles de routage qui prennent en charge les préfixes classless et un passage à un modèle de transfert qui exige que les routes plus spécifiques (à correspondance la plus longue) soient préférées lorsqu'elles chevauchent des routes vers des préfixes moins spécifiques introduit au moins deux préoccupations de sécurité :

Le trafic peut être détourné en annonçant un préfixe pour une destination donnée qui est plus spécifique que l'agrégat qui est normalement annoncé pour cette destination. Par exemple, supposons qu'un système terminal populaire avec l'adresse 192.168.17.100 est connecté à un fournisseur de services qui annonce 192.168.16.0/20. Un opérateur de réseau malveillant intéressé à intercepter le trafic pour ce site pourrait annoncer, ou au moins tenter d'annoncer, 192.168.17.0/24 dans le système de routage global. Parce que ce préfixe est plus spécifique que le préfixe « normal », le trafic sera dévié du système terminal légitime vers le réseau détenu par l'opérateur malveillant. Avant l'avènement du CIDR, il était possible d'induire du trafic depuis certaines parties du réseau à suivre une fausse annonce qui correspondait exactement à un numéro de réseau particulier ; le CIDR aggrave quelque peu ce problème, puisque le routage à correspondance la plus longue amène généralement tout le trafic à préférer les routes plus spécifiques aux routes moins spécifiques. Le remède à l'attaque basée sur le CIDR est toutefois le même que pour une attaque antérieure au CIDR : l'établissement de relations de confiance entre fournisseurs, combiné à de forts filtres de politique de routage aux frontières des fournisseurs. Malheureusement, la mise en œuvre de tels filtres est difficile dans un Internet très décentralisé. Comme solution de contournement, de nombreux fournisseurs mettent en œuvre des filtres génériques qui fixent des limites supérieures, dérivées des directives des RIR pour les tailles des blocs qu'ils allouent, sur les longueurs de préfixes acceptés des autres fournisseurs. Notez que des « spammeurs » ont été observés utilisant ce type d'attaque pour détourner temporairement l'espace d'adressage afin de masquer l'origine du trafic (les messages courriel « spam ») qu'ils génèrent.
Des attaques par déni de service peuvent être lancées contre de nombreuses parties de l'infrastructure de l'Internet en annonçant un grand nombre de routes dans le système. Une telle attaque vise à provoquer des défaillances de routeurs en saturant les tables de routage et de transfert. Un bon exemple d'incident non malveillant ayant causé ce type de défaillance fut l'infame événement « AS 7007 » [7007], où une mauvaise configuration d'un routeur par un opérateur provoqua la propagation d'un nombre énorme de routes invalides à travers le système de routage global. Encore une fois, ce type d'attaque n'est pas vraiment nouveau avec le CIDR ; en utilisant les routes « classe A/B/C » héritées, il était possible d'annoncer un maximum de 16 843 008 numéros de réseau uniques dans le système de routage global, un nombre suffisant pour causer des problèmes même pour les équipements de routage les plus modernes fabriqués en 2005. Ce qui est différent, c'est que la complexité modérée de la configuration correcte des routeurs en présence du CIDR tend à rendre plus probables les « attaques » accidentelles de ce type. Les mesures pour prévenir ce type d'attaque sont en grande partie les mêmes que celles décrites ci-dessus pour le détournement, avec en plus le fait que la meilleure pratique courante consiste également à configurer un nombre maximal raisonnable de préfixes qu'un routeur de bordure acceptera de ses voisins.

Notez que ceci n'a pas l'intention d'être une analyse exhaustive des sorts d'attaques que le CIDR facilite ; une analyse plus complète des vulnérabilités de sécurité dans le système de routage global dépasse le cadre du présent document.