Résumé

  • Un hôte muni d’une passerelle par défaut pouvait atteindre sa destination tout en traversant deux fois le même réseau local : une fois vers G1, puis de G1 vers le meilleur prochain saut G2. ICMP Redirect permettait à G1 d’acheminer le premier paquet puis d’indiquer le raccourci à l’hôte.
  • Le message n’était pas un protocole de routage miniature. L’hôte devait reconnaître son premier saut actuel, vérifier que la passerelle proposée se trouvait sur le lien d’arrivée et ne modifier qu’une entrée de cache propre à la destination.
  • IPv6 a rendu la frontière locale plus vérifiable grâce à une source link-local, un Hop Limit de 255 et des contraintes sur la cible. SEND pouvait authentifier l’émetteur dans une chaîne de confiance, sans certifier la propriété de la destination ni l’optimalité universelle du chemin.

Le détour qui fonctionnait trop bien

La simplicité d’une route par défaut est une forme de liberté opérationnelle. Un poste n’a pas besoin de parler le protocole de routage de ses voisins ni de conserver toutes les destinations de l’Internet. Quand aucune route plus précise ne s’applique, il confie le datagramme à une passerelle connue.

Cette économie de connaissance peut toutefois produire un triangle. Plaçons un hôte H et deux routeurs, G1 et G2, sur le même réseau local. H utilise G1 par défaut. Pour une destination lointaine X, la table de G1 désigne pourtant G2 comme prochain saut. Le paquet traverse donc le lien de H vers G1, puis le traverse à nouveau de G1 vers G2.

Rien n’est nécessairement en panne. Le paquet peut arriver et les échanges se poursuivre. Mais le succès masque une répétition inutile : H continuera d’envoyer chaque paquet à G1 tant qu’il ne possède qu’une règle générale.

RFC 791 distingue le nom, l’adresse et la route. IP déplace des datagrammes indépendants; les hôtes et les passerelles prennent des décisions successives; les procédures du réseau local réalisent ensuite le prochain saut. L’identité de X n’exige pas que H sache tout ce que G1 sait de la topologie.

G1 dispose donc d’une observation utile mais limitée. Il vient de recevoir un paquet de H, il a choisi G2, et il voit que H et G2 partagent le même réseau. La question de conception n’était pas de transférer à G1 le pouvoir de programmer H. Il fallait transmettre exactement cette observation, sans davantage.

Servir d’abord, conseiller ensuite

RFC 792 a défini le message Redirect autour de cette géométrie. G1 reçoit le datagramme d’un hôte attaché, consulte sa table et trouve G2 sur la route vers le réseau X. Si G2 et la source se trouvent sur le même réseau, G1 conseille à l’hôte d’envoyer désormais ce trafic directement à G2.

G1 achemine aussi le datagramme déclencheur. Il ne retient pas le service en attendant que H accepte une nouvelle règle. Le paquet actuel avance par le mécanisme déjà disponible; le contrôle proposé ne concerne que les suivants.

Cet ordre empêche le conseil de se transformer en chantage. Le mot « Redirect » évoque une prise de contrôle instantanée, mais le message ne saisit pas le paquet au milieu de l’Internet. Il rapporte à une seule source qu’un voisin local éviterait un passage intermédiaire la prochaine fois.

ICMP ne promet pas que ce rapport arrivera. RFC 792 précise que les messages de contrôle donnent un retour sur l’environnement sans rendre IP fiable. Le datagramme peut disparaître; le Redirect aussi. En son absence, H conserve un chemin général qui fonctionnait déjà. L’absence de conseil ne prouve pas que G1 est optimal, et sa présence ne garantit pas que G2 le restera.

Un fragment du paquet comme pièce justificative

Le Redirect ne transporte pas seulement l’adresse de G2. Il reprend l’en-tête IP du datagramme original et ses 64 premiers bits de données. Lorsque les ports de transport se trouvent au début, cette citation aide l’hôte à rattacher le message à la communication qui l’a provoqué.

La citation joue le rôle d’un reçu borné. G1 ne publie pas un manifeste sur tous les chemins. Il renvoie la trace d’un traitement concret : H m’a confié ce paquet pour cette destination, je l’ai transmis, et mon prochain saut était ce voisin.

Le code du message distinguait les redirections destinées à un réseau, à un hôte et aux variantes de type de service de l’époque. Le champ Gateway nommait le prochain exécutant. Mais aucun champ n’apportait la route complète au-delà de G2, la politique ayant produit la table de G1, la disponibilité future de G2 ou un titre de propriété sur X.

Cette absence définit la portée de la preuve. L’événement est identifiable, le messager est situé, l’alternative est nommée. Ce qui n’a pas été observé ne doit pas être inventé. H demeure responsable de comparer le message avec son propre état avant d’agir.

Le messager devait déjà être le premier saut

Un paquet de contrôle capable de changer le prochain saut crée une surface d’influence considérable malgré sa petite taille. Savoir fabriquer ICMP ne saurait suffire. RFC 1122 a donc entouré l’acceptation de deux contrôles relationnels.

La nouvelle passerelle doit appartenir au même sous-réseau connecté que celui par lequel le Redirect est arrivé. Un appareil distant ne peut pas désigner comme exécuteur une adresse que H ne peut atteindre directement sur ce lien.

La source du Redirect doit en outre être le premier saut actuellement employé par H pour cette destination. Un routeur auquel H n’a pas confié le paquet ne possède pas la position opérationnelle dont le conseil tire sa légitimité. La proximité ou la maîtrise du format ne remplacent pas cette relation existante.

Ces règles n’attestent pas la bonne foi de G1. Une passerelle compromise peut mentir et un lien partagé garde ses risques d’usurpation. Elles retirent néanmoins au message une prétention beaucoup plus large : n’importe quel locuteur ne peut pas acquérir le droit de déplacer le trafic simplement parce qu’il sait parler ICMP.

Le contrôle reste technique et local. H n’a pas à décider si G1 représente l’organisation de X, une région ou un registre. Il vérifie deux faits qu’il peut connaître : est-ce mon premier saut actuel, et puis-je joindre la cible proposée sur le réseau où j’ai reçu le conseil ?

Une destination ne faisait pas une carte

Après validation, RFC 1122 demande de mettre à jour le prochain saut dans l’entrée appropriée du cache de routes. Les datagrammes ultérieurs vers cette destination peuvent alors aller directement à G2.

Les anciens codes distinguaient Network Redirect et Host Redirect. Pourtant, un hôte ignore généralement le masque applicable au réseau distant. Transformer une observation sur X en règle pour un ensemble d’adresses supposerait une information que le message ne fournit pas. Les exigences pour les hôtes traitent donc un Network Redirect comme un Host Redirect et ne changent que l’entrée de l’hôte destinataire.

Cette décision refuse l’expansion silencieuse. G1 a pu prendre une bonne décision pour le paquet observé sans prouver que toute une plage distante suit le même prochain saut. Une règle large déplacerait des flux jamais testés par l’événement cité.

Le cache n’est pas davantage un registre de propriété. Il mémorise comment ce poste exécutera les prochains envois dans les conditions présentes. Un autre hôte, une autre interface ou un autre instant peut légitimement aboutir à un autre prochain saut. La valeur de l’entrée dépend justement de sa possibilité d’être remplacée.

Le raccourci demeure ainsi une exception au-dessus d’un défaut, non une constitution du réseau. Le chemin général reste nécessaire quand l’observation locale expire, lorsque G2 disparaît ou lorsque la topologie change.

Découvrir des routeurs sans apprendre toutes les routes

Avant toute redirection, H doit trouver au moins une passerelle. Un fichier statique rend l’intention lisible, mais demande une maintenance et suit mal les changements de disponibilité. Écouter le protocole de routage local oblige l’hôte à comprendre un langage qui peut varier d’un réseau à l’autre.

RFC 1256 a introduit Router Solicitation et Router Advertisement. Les hôtes pouvaient découvrir les adresses de routeurs voisins, leur préférence et la durée de validité de l’annonce, sans participer à leur protocole de routage.

Le texte prévient expressément que Router Discovery n’est pas un protocole de routage. Une annonce indique quels routeurs existent; elle ne choisit pas le meilleur pour chaque destination. En l’absence d’information précise, H prend un défaut parmi les candidats les mieux classés. Si ce choix est médiocre pour X, G1 peut fournir un Redirect vers G2.

Les deux mécanismes portent donc des preuves différentes. L’annonce est assez large pour établir une liste temporaire d’exécutants possibles, mais ne prétend pas optimiser X. Le Redirect est plus précis parce qu’il suit un paquet réel, mais ne gouverne ni les autres destinations ni la liste générale.

H garde ainsi une interface minimale avec la couche de routage. Il sait choisir, vérifier et réviser un premier saut; il n’est pas transformé en routeur ni enrôlé dans toutes les décisions de topologie.

Pourquoi un routeur ne devait pas obéir

Une indication utile à un hôte simple peut être toxique dans le plan de contrôle d’un routeur. RFC 1812 interdit à un routeur utilisant un protocole de routage de prendre en compte les chemins appris par Redirect pour transférer des paquets.

Les routeurs possèdent d’autres sources de preuve : configuration statique, annonces, métriques, retrait et règles contre les boucles. Introduire un message déclenché par un seul paquet permettrait de contourner ces procédures. Une contradiction entre Redirect et état de routage pourrait créer précisément la boucle que le raccourci local devait supprimer.

Le même RFC borne aussi l’émission. Le paquet doit ressortir par la même interface physique que celle où il est entré. Sa source et le meilleur prochain saut doivent appartenir au même sous-réseau IP logique. Il ne doit pas contenir de route source. L’adresse source choisie pour le Redirect doit relever du même sous-réseau logique que l’hôte destinataire du message.

Chaque condition empêche un changement d’échelle. Deux interfaces différentes signifieraient une instruction à travers une frontière, non l’élimination d’un triangle local. Une cible hors sous-réseau ne serait pas directement exécutable. Une route source exprime déjà un choix exceptionnel de l’émetteur et ne doit pas être recouverte par une optimisation ordinaire.

Les octets du Redirect restent identiques, mais leur autorité dépend du rôle du récepteur. Le cache étroit d’un hôte peut l’employer; la table partagée d’un routeur ne le peut pas.

IPv6 a rendu la localité testable

IPv6 a conservé Redirect dans Neighbor Discovery. Le message peut annoncer un meilleur routeur de premier saut ou préciser que la destination est elle-même un voisin on-link. RFC 4861 rend la frontière locale observable dans les champs reçus.

La source doit être une adresse link-local. Le Hop Limit doit valoir 255. Comme tout routeur décrémente cette valeur, un message reçu à 255 n’a pas pu être acheminé depuis un autre lien. La somme de contrôle et le code doivent être valides, et la source doit correspondre au premier saut actuel de la destination.

La destination ICMP ne peut pas être multicast. La Target Address est soit l’adresse link-local d’un routeur, soit la destination elle-même lorsqu’on affirme qu’elle est directement sur le lien. Un message qui échoue à l’un de ces contrôles est abandonné.

Le test de 255 ne certifie pas l’honnêteté du voisin. Il établit une propriété plus petite : le message n’a pas franchi un routeur avant d’arriver. Le protocole prouve d’abord la géographie de la prétention, puis vérifie la relation de premier saut et la cible.

Un Redirect valide met à jour le Destination Cache de l’hôte et peut aussi renseigner le Neighbor Cache si l’adresse de couche liaison de la cible est fournie. L’exécution reste chez l’hôte. RFC 4861 interdit au routeur de modifier sa propre table de routage à la réception d’un Redirect.

Authentifier sans fabriquer une vérité universelle

Être sur le même lien ne suffit pas à être digne de confiance. Un hôte a justement besoin d’informations de routeur avant de pouvoir consulter un service extérieur capable de l’aider. RFC 3971 a conçu Secure Neighbor Discovery, SEND, autour de cette difficulté de démarrage.

Signatures, adresses générées cryptographiquement et chemins de certification rattachés à des ancres configurées protègent les messages Neighbor Discovery. Les certificats de routeur peuvent autoriser des plages d’adresses; certaines déclarations de Redirect doivent rester dans ces plages. La réception peut donc établir qu’une clé a signé le message et qu’une chaîne de confiance choisie autorise cette clé dans un rôle borné.

Cette assurance ne répond pas à toutes les questions. Elle ne prouve pas que G2 est le chemin mondialement le plus court, qu’il respecte une politique commerciale, qu’il restera disponible ou qu’il possède X. Une plage autorisée n’est pas un transfert de souveraineté sur les adresses qu’elle contient.

SEND prévoit aussi la coexistence de messages sécurisés et non sécurisés selon la configuration. Refuser tout message non protégé renforce une frontière mais peut perdre l’interopérabilité; accepter les deux conserve une surface non authentifiée. La cryptographie rend le choix et sa provenance plus précis, elle ne choisit pas à la place de l’opérateur.

Sources et limites de preuve

RFC 791 fournit le modèle IP; RFC 792 décrit le triangle G1/G2; RFC 1122 fixe la validation par l’hôte et l’étendue du cache; RFC 1256 sépare découverte et choix par destination; RFC 1812 limite l’émission et empêche les routeurs d’apprendre par Redirect; RFC 3971 ajoute l’autorisation SEND; RFC 4861 décrit la validation IPv6 et ses effets de cache.

Ces textes ne donnent ni date mondiale unique de déploiement, ni valeur par défaut actuelle de tous les systèmes. Ils ne mesurent pas la fréquence des attaques et ne permettent pas d’affirmer que Redirect est partout activé, désactivé, sûr ou dangereux. Ils démontrent une architecture plus modeste : un premier saut peut proposer une correction locale à partir d’un transfert observé, tandis que l’hôte garde la vérification, l’exécution et la limite de l’état modifié.