Responsabilités des gestionnaires d'hôte et de réseau : un résumé des "traditions orales" de l'Internet

Statut de ce mémoire

Cette RFC pour information décrit les conventions que doivent suivre ceux qui ont la responsabilité des réseaux et des hôtes de l'Internet. C'est un résumé de la "tradition orale" de l'Internet sur le sujet. [Note de l'éditeur des RFC : Le présent mémoire est une contribution par l'auteur sur sa vision de ces conventions. Il est prévu que la présente RFC fournisse une base pour le développement de politiques officielles à l'avenir.] Ces conventions peuvent être complétées ou amendées par les politiques des composants spécifiques locaux et régionaux de l'Internet. La présente RFC ne spécifie pas une norme, ni une politique de l'IAB. La distribution du présent mémoire n'est soumise à aucune restriction.

1.   Responsabilités de base

L'Internet est une entreprise coopérative, et son utilité dépend du comportement raisonnable de chaque utilisateur, hôte et routeur sur l'Internet. Il s'ensuit que les personnes en charge des composants de l'Internet DOIVENT être conscientes de leurs responsabilités et être attentives aux conditions locales. De plus, elles DOIVENT être accessibles à la fois via la messagerie Internet et par téléphone, et répondre aux rapports de problèmes et initiatives de diagnostic provenant des autres participants.

Même des problèmes locaux aussi simples et transitoires que des pannes systèmes ou des défaillances d'alimentation peuvent avoir de graves effets ailleurs sur le réseau. Les problèmes qui exigent la coopération entre deux ou plusieurs individus responsables pour faire un diagnostic et des corrections sont relativement courants. De même, les outils, les accès et l'expérience nécessaire à l'efficacité d'une analyse peuvent ne pas tous exister sur un seul site.

Cette approche communautaire de la gestion et de la maintenance de l'Internet est dictée par la structure d'organisation décentralisée actuelle. La structure, à son tour, existe parce qu'elle n'est pas coûteuse et qu'elle répond à divers besoins locaux. De plus, pour le court terme, c'est notre seul choix ; je ne vois aucune perspective que le gouvernement ou une entreprise privée construise dans le siècle qui vient une fourniture de réseau de datagrammes monolithique, centralisé et omniprésent.

2.   Responsabilités des gestionnaires de réseau

Un ou plusieurs individus sont responsables de chaque réseau ou sous-réseau IP qui est connecté à l'Internet. Leurs noms, numéros de téléphone et adresses postales DOIVENT être fournies au NIC Internet (ou au NIC du réseau de transit local ou régional) avant la connexion initiale de leur réseau à l'Internet, et les mises à jour et corrections DOIVENT être fournies à temps aussi longtemps que le réseau reste connecté.

Afin de traiter de façon adéquate les problèmes qui pourraient survenir, un gestionnaire de réseau doit avoir :

a.   des privilèges d'accès de gestion système sur tout hôte et routeur connecté au réseau local, ou

b.   l'autorité et l'accès pour soit débrancher, réinitialiser, déconnecter physiquement ou désactiver la transmission de datagrammes IP à partir de tout système d'hôte individuel qui pourrait se mal conduire.

Pour tous les réseaux, un gestionnaire de réseau capable d'exercer ce niveau de contrôle DOIT être accessible via téléphone 8 heures par jour, 5 jours par semaine. Pour les réseaux qui portent du trafic de transit, un gestionnaire de réseau DEVRAIT être accessible par téléphone 24 heures sur 24.

3.   Responsabilités des gestionnaires de système d'hôte

Un ou plusieurs individus doivent être responsables pour chaque hôte connecté à l'Internet. Cette personne DOIT avoir l'autorité, l'accès et les outils nécessaires pour configurer, faire fonctionner et contrôler l'accès au système. Pour les hôtes importants en temps partagé, les serveurs principaux de nom de domaine et les relais ou routeurs de messagerie, le ou les individus responsables DEVRAIENT être accessibles par téléphone 24 heures sur 24, 7 jours sur 7.

Pour les hôtes en temps partagé moins importants ou les micro ordinateurs ou stations de travail à utilisateur unique, le ou les individus responsables DOIVENT être prêts pour la possibilité que leur gestionnaire de réseau ait à intervenir en leur absence, si la résolution d'un problème de l'Internet l'exige.

4.   Postmaster@foo.bar.baz

Chaque hôte Internet qui traite de la messagerie au delà du réseau local DOIT entretenir une boîte aux lettres nommée "postmaster". En général, elle ne devrait pas simplement transmettre les messages ailleurs, mais plutôt être lue par un dispositif de maintenance de système logé dans la machine. Cette boîte aux lettres DEVRAIT être lue au moins cinq jours par semaine, et des dispositions DOIVENT être prises pour traiter les messages entrants dans l'éventualité d'une absence de l'agent normal de maintenance.

Le "postmaster" d'une machine est le point de contact normal pour les problèmes qui se rapportent à la livraison de messagerie. Comme la plupart du trafic sur les segments à longue portée de l'Internet est sous la forme de messages électroniques, un problème local peut avoir des conséquences significatives ailleurs dans l'Internet. Certains problèmes peuvent être à l'échelle du système, comme un disque ou fichier système plein, ou un serveur de messagerie ou de noms de domaines suspendu, en panne, ou en dérangement. D'autres peuvent être spécifiques d'un utilisateur particulier ou d'une liste de diffusion (alias ou noms de transmission incorrects, quota excédé, etc.).

Dans l'un ou l'autre cas, celui qui est chargé de la maintenance d'une machine distante va normalement envoyer un message sur les problèmes de livraison au "postmaster". Aussi, "postmaster" est normalement spécifié dans le champ "reply-to:" des messages d'erreur de messagerie qui sont générés automatiquement ("incapable de livrer car le nom d'utilisateur n'existe pas", "incapable de transmettre", "en-tête mal formé", etc.). Si la boîte aux lettres n'est pas lue à temps, des quantités significatives de messages peuvent être perdues ou retournées à l'envoyeur.

5.   Problèmes et solutions

Les progrès des outils de gestion de réseau peuvent éventuellement rendre possible qu'un agent de maintenance de réseau détecte et règle la plupart des problèmes avant qu'ils n'affectent les utilisateurs, mais à présent, les utilisateurs au jour le jour des services de réseautage représentent la ligne de front. Aucun individu responsable ne devrait permettre que son filtre de "questions idiotes" ne devienne trop restrictif ; les rapports de la forme "Je n'ai reçu aucun message depuis une semaine ... " ou "Je pouvais aller là ce matin, mais plus maintenant ..." devraient recevoir une écoute attentive.

Il y a trois classes de problèmes de base qui peuvent être d'importance pour l'ensemble du réseau : en rapport avec l'utilisateur, en rapport avec l'hôte, et en rapport avec le réseau.

a.   Les problèmes en rapport avec l'utilisateur peuvent aller de la messagerie active ou du comportement incivil sur des listes de diffusion à des questions plus sérieuses comme des violation de confidentialité, tentatives d'effraction ou vandalisme.

b.   Les problèmes en rapport avec l'hôte peuvent inclure un logiciel mal configuré, obsolète ou défectueux et des trous dans la sécurité.

c.   Les problèmes en rapport avec le réseau se rapportent le plus fréquemment à l'acheminement : annonces de connexité incorrectes, boucles d'acheminement et trous noirs peuvent tous avoir des impacts majeurs. Les mécanismes sont normalement en place pour le traitement des défaillances des routeurs ou des liaisons, mais les problèmes autres que des défaillances caractérisées peuvent aussi avoir des effets sévères.

Chaque classe de problème a ses propres caractéristiques. Les problèmes en rapport avec l'utilisateur peuvent généralement se résoudre par l'éducation, mais les gestionnaires de système devraient être conscients aussi des lois fédérales et étatiques applicables ; les violations de confidentialité ou les tentatives "d'effraction" ont toujours visé à tirer abusivement sur le compte d'un utilisateur, mais elles peuvent aussi donner lieu maintenant à des poursuites. Les problèmes en rapport avec l'hôte peuvent habituellement se résoudre par une reconfiguration ou une mise à niveau du logiciel, mais parfois, le fabricant a besoin d'être mis au courant d'une erreur ou d'une difficulté dans un logiciel pour pouvoir y faire quelque chose ; les erreurs qui ne peuvent être corrigées peuvent être assez sérieuses pour exiger un déni de service partiel ou total du système fautif. Des niveaux d'escalade similaires existent pour les problèmes en rapport avec les réseaux, avec comme solution en dernier ressort l'ostracisme à l'égard du réseau fautif.

6.   L'illusion de la sécurité

Chaque gestionnaire d'hôte et de réseau DOIT être conscient que l'Internet tel qu'il est présentement constitué N'EST PAS sûr. Au niveau du protocole, beaucoup plus d'efforts ont été mis dans l'interopérabilité, la fiabilité et au côté pratique qu'il n'en a été consacré à la sécurité, bien que cela change maintenant. De récents événements ont rendu les développeurs de logiciels et les fabricants plus sensibles à la sécurité, à la fois dans la configuration et dans la mise en œuvre sous-jacente, mais il reste à démontrer quels effets à long terme cela pourra avoir. D'ici là, le système existant doit survivre par la coopération de tous les individus responsables.

La sécurité est subjective ; un site peut la voir comme une curiosité inutile alors qu'un autre la verra comme une marque d'hostilité. Comme en fin de compte l'existence de l'Internet dépend de son utilité pour tous les membres de la communauté, il est important que les gestionnaires soient d'accord pour accepter d'agir sur les questions de sécurité des autres sites, en avertissant ou en refusant l'accès aux utilisateurs qui se conduisent mal. Le site attaqué, à son tour, doit être raisonnable dans ses demandes (quelqu'un qui débranche une alarme sur un système inactif pour voir si le trou "DEBUG" d'envoi de messagerie a été fermé sur un hôte "sensible" devrait probablement recevoir un avertissement, plutôt que des poursuites en justice).

Comme les questions de sécurité de l'Internet peuvent exiger que les gens de la gestion locale se mettent en contact avec n'importe lequel de leurs utilisateurs, ou qu'ils refusent à un individu ou groupe qui se conduit mal l'accès aux autres sites, il est nécessaire que des mécanismes existent pour le permettre. En conséquence, les sites Internet NE DEVRAIENT PAS avoir de serveur de terminal en compte "d'utilisation générale", ou "ouvert" (sans mot de passe) qui puisse accéder au reste de l'Internet.

De leur côté, les sites "sensibles" DOIVENT être conscients qu'il est impossible à long terme de refuser l'accès à l'Internet aux craqueurs de code, aux anciens employés mécontents, aux concurrents sans scrupule ou aux agents de puissances ennemies. Prendre sur le fait un agresseur est au mieux un bouche trou, qui fournit un peu d'air l'espace d'un jour ou d'une heure pendant que les trous de la sécurité qui ont été attaqués sont bouchés. Il s'ensuit que chaque gestionnaire d'hôte est en fin de compte responsable de sa sécurité ; plus l'application ou les données sont "sensibles", plus le gestionnaire doit avoir une connaissance intime du système d'exploitation et du logiciel réseau de l'hôte et de leurs faiblesses.

7.   Résumé

Le cœur de l'Internet est la communauté d'intérêt unique des ses utilisateurs, opérateurs, mainteneurs et fournisseurs. La conscience et l'acceptation de l'intérêt commun à un Internet utilisable sont vitales à sa survie et sa croissance. Les conventions simples présentées ici devraient être complétées par le bon sens en tant que de besoin, pour réaliser cet objectif.

8.   Considérations pour la sécurité

Les questions de sécurité sont exposées aux Sections 5 et 6.

9.   Adresse de l'auteur

James B. VanBokkelen

FTP Software Inc.

26 Princess St.

Wakefield, MA 01880

téléphone : 617-246-0900

mél : jbvb@ftp.com