Summary

  • Le RFC 2979 distingue le refus de sécurité intentionnel de l’échec involontaire d’un usage conforme ; dans le second cas, la responsabilité revient au pare-feu et aux logiciels associés.
  • Ses exemples de découverte du MTU et d’extensions SMTP montrent comment un intermédiaire pouvait interrompre un échange tout en appliquant une règle apparemment simple.

Refuser selon une règle et casser un protocole ne sont pas la même chose

Vers 2000, l’idéal de bout en bout se heurtait à une frontière pratique : les organisations reliaient de plus en plus leurs systèmes internes précieux à un réseau qu’elles ne contrôlaient pas entièrement. Le pare-feu fournissait un point de filtrage. Mais ses comportements étaient souvent mal spécifiés et variaient assez pour provoquer des problèmes au-delà de la politique qu’il devait appliquer.

Le RFC 2775 avait déjà décrit la « transparence » sous plusieurs angles : fonctions de bout en bout, performance et transparence des adresses. Le RFC 2979 resserrait la question sur un contrat opérationnel. Introduire un pare-feu, un tunnel ou un mécanisme de négociation d’accès ne devait pas provoquer l’échec involontaire d’un usage légitime et conforme qui aurait fonctionné sans lui. Si cela arrivait, il fallait corriger le pare-feu ou les logiciels associés, sans obliger à modifier le protocole existant ni son implémentation.

Ce n’était pas une obligation de laisser passer tous les paquets. Le RFC reconnaissait explicitement le droit d’un site à bloquer un accès jugé illégitime, même lorsque le trafic suivait une norme. Il permettait aussi des mécanismes supplémentaires d’authentification ou d’autorisation, comme SOCKS, y compris des configurations qui les imposaient. La distinction essentielle séparait le refus délibéré de la rupture accidentelle causée par un intermédiaire qui comprenait mal le trafic.

Une erreur ICMP supprimée pouvait immobiliser un flux valide

L’exemple de découverte du MTU rendait la règle tangible. En IPv4, un émetteur pouvait marquer un paquet « Don't Fragment ». Si un lien en aval ne pouvait pas le transporter, un routeur renvoyait un message ICMP « Destination Unreachable / Fragmentation Needed » afin que l’émetteur réduise la taille de ses paquets. Un pare-feu qui laissait sortir le paquet mais supprimait cette réponse pouvait laisser l’émetteur répéter un trafic toujours trop grand : un trou noir, pas une décision de sécurité pertinente.

Le RFC ne disait pas que tout ICMP devait passer. Il différenciait une erreur associée à un trafic sortant légitime des échos, redirections ou erreurs sans rapport, que le site pouvait bloquer. Le contexte et l’objet comptaient : une même famille de protocoles comportait des informations de contrôle indispensables à certains échanges et des messages qu’une politique pouvait raisonnablement refuser.

Une liste d’extensions créait un désaccord à trois

L’exemple SMTP révélait une défaillance plus subtile. Le client demande les extensions du serveur avec EHLO ; le serveur annonce ses capacités ; le client peut ensuite choisir une extension. Un proxy qui ajoutait simplement EHLO à la liste de commandes acceptées, sans filtrer les réponses du serveur, pouvait laisser les extrémités s’entendre sur une capacité que le proxy ne savait pas transporter correctement.

La leçon n’était pas que tout pare-feu devait implémenter chaque extension nouvelle. Le RFC recommandait aux protocoles applicatifs de faciliter le passage des pare-feu si cela ne nuisait pas à l’application. Il déconseillait d’envelopper un protocole inédit dans HTTP uniquement parce que le port 80 était souvent ouvert : un sous-ensemble sûr, un mécanisme de traversée approprié ou un port distinct pouvaient être des choix plus francs.

Ce que le RFC établit — et ce qu’il ne prouve pas

Le RFC 2979 est un mémo informatif, pas une norme Internet. L’historique du projet indique une approbation de l’IESG en août 2000, puis la publication en octobre. Ces archives établissent un principe de conception et des exemples ; elles ne démontrent ni adoption commerciale, ni conformité des produits, ni baisse du contournement, ni amélioration mesurée de la sécurité.

Sa contribution historique est une ligne de responsabilité : une règle de sécurité peut refuser un flux, mais une incompatibilité accidentelle ne doit pas devenir tacitement le problème du développeur d’application. Un opérateur peut s’en servir pour classer une panne : refus délibéré ou rupture involontaire par filtre, proxy ou analyseur ? Cette démarche est une déduction, pas une mesure de ce que les opérateurs ont effectivement fait.

Le RFC 3093, publié en avril 2001 et daté du 1er avril, est un voisin distinct : son « Firewall Enhancement Protocol » propose d’encapsuler IP/TCP dans HTTP. Il ne prouve ni l’échec du RFC 2979 ni le déploiement de ce tunnel. Le filtrage doit aussi rester distinct du NAT : le RFC 2979 sépare explicitement ces fonctions, même si un appareil les assure toutes deux.

Sources : RFC 2979 ; RFC 2775 ; RFC 3093 ; historique du projet ; RFC 1191 ; RFC 1869.