Summary

  • Le port observé est un fait de transport ; son association habituelle à un service est une convention entre extrémités, non une authentification de l'application.
  • Un contrôle fondé sur cette association peut bloquer un usage légitime et pousser les communications vers un autre port, une négociation dynamique, un relais, un tunnel ou du chiffrement.

Imaginons un dispositif intermédiaire qui lit correctement le port 25. Il sait quel nombre figure dans le segment. Il peut aussi connaître la convention qui associe ce nombre à SMTP. Il ne sait pas encore si le flux est réellement du courrier, si l'émetteur est autorisé, si le message est indésirable ni si la livraison réussira. Entre le nombre et ces conclusions se trouvent plusieurs preuves absentes.

RFC 3639 fixe la frontière : même un port « bien connu » n'est garanti comme porteur de sens que pour les systèmes d'extrémité. Un intermédiaire ne devrait normalement pas lui attribuer un sens précis sans signal fourni par une extrémité ou convention partagée avec les parties. Cette réserve tient à l'exécution réelle. Deux extrémités peuvent choisir n'importe quel port. Un protocole peut négocier un port après un échange de contrôle. L'observateur qui n'a ni participé à l'échange ni reçu son résultat ne possède pas cette correspondance.

Le texte n'écarte pas l'utilité des ports stables. Ils peuvent aider le filtrage, le marquage de qualité de service, l'analyse agrégée et la mesure de charge. Il demande plutôt de maîtriser le degré de certitude. Son exemple du port 25 montre qu'un blocage visant le spam peut aussi empêcher du courrier légitime. Ce n'est pas une mesure actuelle d'un opérateur ; c'est la démonstration qu'une règle utile peut dépasser sa preuve.

Vient ensuite l'effet de retour. Une restriction perçue comme contraire aux intérêts des parties peut être contournée par un port alternatif, un relais, une négociation dynamique ou un tunnel. GRE place le paquet initial dans une nouvelle enveloppe ; ESP peut en masquer et chiffrer les informations. Le chiffrement voulu par l'utilisateur n'est pas suspect en soi. Mais l'intermédiaire perd le raccourci qu'il avait transformé en point de contrôle.

La doctrine ultérieure confirme cette limite. RFC 7605 rappelle que la corrélation entre service et port est, au fond, un accord entre extrémités. RFC 6335 organise l'attribution IANA ; le registre des services et ports fournit une convention par défaut, pas un droit exclusif sur le trafic. TCP, UDP et SCTP conservent la fonction de démultiplexage. Le registre des numéros de protocole coordonne un autre champ ; aucun de ces documents n'authentifie l'application observée.

Une information explicite peut améliorer le dossier. RSVP illustre un signal adressé au réseau ; SIP illustre une allocation dynamique que l'observateur doit connaître. Pourtant, signal, identité du pair, autorisation de politique et résultat de service restent quatre constats distincts.

Les limites historiques sont vérifiables dans la notice RFC Editor, l'entrée Datatracker, l'historique, les errata et l'édition texte. Les essais de Heng Lu sur les couches de réalité, la spécification commune minimale et la primauté du code en service donnent la méthode : ne jamais transformer une convention coordonnée en autorité supérieure à la pratique vérifiable.