Résumé

  • La RFC 4084 classe plusieurs formes de connectivité sans transformer la plus large en jugement moral : elle demande surtout que les fonctions autorisées, les filtres et les conditions soient annoncés.
  • Un reçu de capacités doit séparer la promesse commerciale, le contrat, la configuration du fournisseur et l’observation mesurée. Un contournement qui fonctionne aujourd’hui ne devient pas pour autant une fonction prise en charge.

Le mot commun masque des services différents

Deux clients peuvent acheter un « accès Internet » et recevoir des surfaces d’exploitation incompatibles. Le premier obtient une adresse publique stable, accepte des connexions entrantes et choisit ses résolveurs DNS. Le second partage une adresse, dépend d’un relais pour les applications pair à pair et doit soumettre son courrier par le serveur du fournisseur. Les deux connexions ouvrent des pages Web. Cette réussite commune ne décrit pas le produit.

La RFC 4084 part de cette confusion. Publiée en 2005 comme BCP 104, elle propose cinq descriptions croissantes : connectivité Web ; connectivité client sans adresse publique ; client avec adresse publique ; connectivité Internet protégée par pare-feu ; connectivité Internet complète. Le texte précise que ces termes ne sont pas péjoratifs. Reconnaître une offre limitée ne revient ni à l’approuver ni à la condamner. Le fournisseur peut vendre le périmètre qu’il choisit ; l’acheteur doit savoir ce qu’il reçoit.

Cette neutralité est une force de négociation. Elle empêche le débat de se réduire à « vrai » ou « faux » Internet. La question utile devient : quelles opérations le client peut-il exécuter, sous quelle responsabilité et avec quel niveau de continuité ?

L’adresse visible ne suffit pas

Le premier piège consiste à prendre une adresse pour une capacité. La RFC 4084 distingue une adresse non publique, une adresse publique mais destinée au seul client, et une adresse statique associée à une connectivité complète. Même une adresse publique n’accorde pas automatiquement le droit d’héberger un serveur : le contrat peut l’interdire ou le réseau peut filtrer les tentatives entrantes.

L’inventaire doit donc préciser la famille IP, le caractère exclusif ou partagé, la stabilité, la qualification dynamique publiée aux tiers, le DNS inverse et la portée entrante. Il doit identifier la traduction d’adresses, son emplacement et son opérateur.

La RFC 4787 montre pourquoi un test ponctuel est insuffisant. Le comportement de mappage d’un NAT n’est pas son comportement de filtrage. Les temporisations et le sens des paquets qui entretiennent l’état comptent. Une application peut établir un échange direct dans une condition et nécessiter un relais dans une autre. Le résultat doit conserver le moment, le point d’observation, les ports, la direction et les répétitions.

Un tunnel, un rendez-vous pair à pair ou un relais peut rétablir le service applicatif. C’est une solution technique valable. Ce n’est toutefois ni une preuve que le fournisseur autorise un serveur, ni un engagement à maintenir le chemin, ni une description de la capacité native de l’accès.

Quatre registres au lieu d’un feu vert

Le reçu proposé contient quatre registres autonomes.

Le registre annoncé conserve le nom de l’offre, sa version, la catégorie déclarée et les formulations commerciales. Le registre contractuel indique les permissions et interdictions : serveurs, pair à pair, stabilité d’adresse, relais de courrier, filtrage, option de pare-feu et obligations d’assistance.

Le registre configuré décrit ce que le fournisseur contrôle : NAT, filtres entrants et sortants, proxy, interception, résolveurs imposés, comportement ICMP, tunnels, redirection du courrier et paramètres demandés par le client. Il doit porter une date ou une identité de changement.

Le registre observé décrit une épreuve reproductible. Il indique les deux extrémités, l’heure, le protocole, le port, la direction, l’adresse vue, la durée d’inactivité, le nombre d’essais et les écarts. Une observation ne corrige pas le contrat et n’attribue pas une intention. Elle dit seulement ce qui s’est produit dans un cadre défini.

Trois indicateurs complètent ces registres : restriction demandée par le client, dépendance à un contournement et déclencheur de nouvel essai. Ils évitent d’accuser le réseau pour une règle du pare-feu d’entreprise et empêchent, à l’inverse, qu’une restriction du fournisseur soit cachée sous un mot générique comme « sécurité ».

Le courrier révèle les couches invisibles

La RFC 4084 consacre une attention particulière au courrier. Un fournisseur peut imposer son serveur de soumission, bloquer certains ports, détourner le trafic sortant, limiter l’accès POP3 ou IMAP4, ou signaler une adresse comme dynamique d’une manière qui affecte la délivrabilité. « Le webmail fonctionne » ne répond à aucune de ces questions.

Le reçu doit distinguer la soumission authentifiée, l’accès à des serveurs externes, la récupération distante, les domaines d’expéditeur autorisés, le DNS inverse, le traitement de réputation et toute redirection. Il faut appliquer la même précision aux VPN : famille de tunnel, sens, durée d’inactivité, changement d’adresse et solution de repli. Pour DNS et ICMP, le reçu précise ce qui traverse réellement la frontière. Pour HTTP, HTTPS, SMTP, FTP et les applications inconnues, il distingue interdiction, filtrage, interception et absence de test.

Qui a demandé la restriction ?

La RFC 7754 sépare l’auteur d’une politique de l’acteur qui l’applique. Cette distinction complète la RFC 4084. Un échec depuis un point de mesure ne révèle pas à lui seul le motif, la légalité ou le décideur. Le reçu doit associer chaque restriction à une partie responsable et à une surface technique.

Une formulation bornée est plus solide : « les connexions TCP entrantes sur tel port ont échoué depuis deux réseaux externes ; la clause contractuelle désigne tel filtrage ; le pare-feu géré a été ou non demandé par le client ». Ce langage protège l’acheteur contre l’ambiguïté et le fournisseur contre une attribution sans preuve.

Sources