Résumé

  • La RFC 2267 plaçait le contrôle du préfixe source sur l’interface du fournisseur tournée vers le client, là où les préfixes autorisés pouvaient être connus localement.
  • En 2000, BCP 38 a élevé cette recommandation au rang de bonne pratique. Un paquet conforme désignait toujours une frontière réseau, et non l’hôte ou la personne qui se trouvait derrière.

Une adresse visible, un émetteur inconnu

Un serveur reçoit des demandes de connexion qui semblent provenir d’adresses injoignables. Il répond vers des chemins sans issue, tandis que l’émetteur change le champ source. Un autre paquet peut afficher l’adresse réelle d’un réseau qui n’a rien à voir avec l’attaque. Si la victime bloque cette adresse apparente, elle risque aussi de couper les communications légitimes du tiers innocent.

C’est l’angle mort opérationnel décrit dans la RFC 2267. Le destinataire lit l’adresse inscrite dans le paquet, sans pouvoir vérifier directement qui l’a choisie. Renforcer le serveur aide à absorber davantage de demandes ; cela ne dit pas à une victime distante si l’adresse source a été falsifiée. Le mémo présentait ces mesures comme complémentaires et proposait d’ajouter un contrôle plus près du réseau qui avait émis le paquet.

Le fournisseur connaissait déjà le port client

Prenons un fournisseur qui agrège les routes de plusieurs réseaux en aval. Sur le routeur relié à l’un d’eux, il peut poser une question locale : quels préfixes source sont autorisés sur cette liaison ? Dans l’exemple de la RFC, les paquets portant le préfixe du client passent ; ceux qui prétendent venir d’ailleurs sont rejetés. Le document recommande de conserver des journaux des rejets afin de repérer une activité suspecte.

Il ne s’agit pas de consulter un registre mondial des propriétaires d’adresses. La règle s’appuie sur une relation connue au bord du réseau : cette liaison client, cet ensemble de préfixes permis. Avant d’entrer plus loin dans le réseau du fournisseur, le champ source est comparé à cette relation. Un préfixe extérieur peut alors être arrêté près du point d’entrée, avant de devenir un indice ambigu chez la victime.

Le déplacement du contrôle change la charge de la preuve. Sans vérification en amont, la cible doit interpréter un champ non fiable et peut pénaliser le titulaire innocent d’une adresse apparente. Avec un filtre à l’entrée du fournisseur, le réseau qui transporte le trafic du client peut refuser les préfixes absents de cette liaison. Si l’attaque utilise malgré tout un préfixe autorisé, l’enquête peut au moins commencer dans un périmètre réseau plus restreint que l’Internet entier.

Vérifier un préfixe n’est pas vérifier une route retour

La RFC 2267 marque une distinction souvent effacée. Les auteurs ont envisagé de vérifier si la route de retour vers la source sortirait par la même interface que celle par laquelle le paquet est arrivé. Ils ont écarté cette exigence générale : les routes asymétriques étaient assez courantes pour la rendre problématique. Leur proposition portait plutôt sur la légitimité du préfixe source pour le réseau client relié à cette interface.

Ces contrôles se ressemblent parce qu’ils se font à l’entrée. Mais ils ne répondent pas à la même question. Le test de retour dépend du sens choisi par la table de routage ; le filtre client compare la source aux préfixes permis pour le réseau connecté. La RFC 3704 a ensuite examiné les mécanismes de filtrage pour les réseaux multiraccordés et mis à jour la RFC 2827. Ses modes strict, feasible et loose de vérification du chemin retour relèvent d’un autre sujet ; ils ne sont pas le propos de cet article.

La mobilité a révélé le bord de la règle

Une adresse peut être légitime pour un terminal mobile tout en étant inattendue sur le réseau auquel il est momentanément raccordé. La RFC 2267 cite Mobile IP : un paquet émis depuis un réseau visité pouvait porter l’adresse du réseau d’origine du terminal ; une règle simple par préfixe client aurait alors pu le rejeter. Le mémo renvoyait au tunnel inverse, ensuite décrit dans la RFC 2344, qui permet d’envoyer le paquet sortant à l’agent d’origine avant de le transmettre vers Internet.

Cet exemple montre que le filtre ne juge pas l’intention. Il applique une règle locale sur les préfixes autorisés à travers une interface client donnée. Un service légitime qui doit utiliser un autre préfixe a besoin d’un chemin ou d’une politique explicite compatible avec cette frontière. Les RFC ne disent pas que toute mobilité échoue ni qu’il faut supprimer toutes les exceptions. Elles montrent qu’une exception doit être réconciliée avec la règle d’entrée.

Une proposition est devenue BCP 38

Parue en janvier 1998, la RFC 2267 était un mémo informatif. En mai 2000, la RFC 2827 l’a remplacée sous le même titre, « Network Ingress Filtering », comme BCP 38, une bonne pratique actuelle. La proposition centrale restait reconnaissable : les fournisseurs devaient filtrer à l’entrée le trafic client pour qu’un client ne puisse pas émettre des paquets dont le préfixe source n’était pas légitimement utilisé par son réseau.

Le changement de statut du document compte, mais ce n’est pas une preuve de déploiement. La RFC 2827 recommande une pratique ; sa publication ne révèle pas quels routeurs, clients ou liens de fournisseur avaient un filtre installé. La RFC 2267 indiquait que certains fournisseurs commençaient à appliquer la technique, sans fournir de recensement ni de mesure de couverture. Un texte, une politique fournisseur, une règle installée sur une interface, un paquet rejeté et une enquête réussie sont des faits distincts.

La promesse du filtre restait circonscrite. Il pouvait empêcher un client d’émettre des sources falsifiées hors de l’ensemble permis. Il ne pouvait ni empêcher un attaquant de viser un hôte appartenant à cet ensemble, ni arrêter les attaques utilisant des adresses valides, ni reconnaître une machine ou une personne, ni établir une intention. Un journal de rejets pouvait aider à localiser un paquet suspect au niveau d’une frontière réseau ; il documentait une décision d’interface, pas un aveu de l’émetteur.

Le déplacement historique est donc modeste et concret. Au lieu de demander uniquement à la victime de donner un sens à une adresse falsifiée, la RFC 2267 plaçait un contrôle vérifiable à la frontière du client, où la relation entre réseau et préfixes pouvait être entretenue et appliquée. BCP 38 a donné un nom plus stable à cette pratique. Sur une liaison donnée, son efficacité dépendait encore d’une règle locale correcte, installée et active.

Sources

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering (BCP 38)
  3. RFC 1812 — Requirements for IP Version 4 Routers
  4. RFC 2002 — IP Mobility Support
  5. RFC 2344 — Reverse Tunneling for Mobile IP
  6. RFC 3704 — Ingress Filtering for Multihomed Networks (BCP 84)