RFC2811 page - 12 - Kalt

Groupe de travail Réseau

C. Kalt

Request for Comments : 2811

avril 2000

RFC mise à jour : 1459


Catégorie : Information

Traduction Claude Brière de L’Isle



Relais pour la causette Internet : gestion de canal



Statut de ce mémoire

Le présent mémoire fournit des informations pour la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.


Résumé

Une des caractéristiques les plus notables du protocole de relais pour la causette Internet (IRC, Internet Relay Chat) est de permettre aux utilisateurs de se grouper dans des forums, appelés canaux, fournissant le moyen à plusieurs utilisateurs de communiquer ensemble.


Il y avait à l’origine un type unique de canal, mais au fil des ans, de nouveaux types sont apparus, soit en réponse à un besoin, soit à titre d’expériences.


Le présent document spécifie comment sont gérés les canaux, leurs caractéristiques et leurs propriétés, par les serveurs IRC.


Table des matières

1. Introduction 2

2. Caractéristiques des canaux 2

2.1 Espace de noms 2

2.2 Portée du canal 3

2.3 Propriétés du canal 3

2.4 Membres privilégiés du canal 3

2.4.1 Fonctionnement du canal 3

2.4.2 Créateur du canal 3

3. Durée de vie du canal 4

3.1 Canaux standard 4

3.2 Canaux sûrs 4

4. Modes de canal 5

4.1 États de membre 5

4.1.1 Statut de "créateur de canal" 5

4.1.2 Statut d’opérateur de canal 5

4.1.3 Privilège vocal 5

4.2 Fanions de canal 5

4.2.1 Fanion Anonyme 5

4.2.2 Fanion Seulement sur invitation 6

4.2.3 Fanion Canal modéré 6

4.2.4 Pas de messages au canal des clients de l’extérieur 6

4.2.5 Canal silencieux 6

4.2.6 Canaux privés et secrets 6

4.2.7 Fanion Serveur Reop 6

4.2.8 Sujet 7

4.2.9 Limite d’utilisateur 7

4.2.10 Clé de canal 7

4.3 Contrôle d’accès de canal 7

4.3.1 Interdiction de canal et exception 7

4.3.2 Invitation de canal 7

5. Mises en œuvre actuelles 7

5.1 Suivi des canaux récemment utilisés 8

5.2 Canaux sûrs 8

5.2.1 Identifiant de canal 8

5.2.2 Délai de canal 8

5.2.3 Fenêtre d’abus 8

5.2.4 Préserver la santé de l’espace de noms 9

5.2.5 Mécanisme Serveur Reop 9

6. Problèmes en cours 9

6.1 Étiquettes 9

6.1.1 Délai de canal 9

6.1.2 Canaux sûrs 10

6.2 Délais de propagation de mode 10

6.3 Collisions et modes de canal 10

6.4 Épuisement des ressources 10

7. Considérations pour la sécurité 11

7.1 Contrôle d’accès 11

7.2 Confidentialité du canal 11

7.3 Anonymat 11

8. Prise en charge et disponibilité actuelle 11

9. Remerciements 11

10. Références 11

11. Adresse de l’auteur 12

12. Déclaration complète de droits de reproduction 12



1. Introduction


Le présent document définit en détail comment sont gérés les canaux par les serveurs IRC et il sera le plus utile aux personnes qui travaillent à la mise en œuvre d’un serveur IRC.

Bien que les concepts définis ici constituent une partie importante de l’IRC, ils restent non essentiels pour la mise en œuvre des clients. Alors que la tendance semble aller vers des clients de plus en plus complexes et "intelligents" qui sont capables de tirer parti de la connaissance du fonctionnement interne des canaux pour fournir aux utilisateurs une interface plus conviviale, les simples clients peuvent être mis en œuvre sans l’aide du présent document.

Beaucoup des concepts définis ici ont été conçus en gardant présente à l’esprit l’architecture de l’IRC [RFC2810] et ils prennent tout leur sens dans ce contexte. Cependant, de nombreux autres pourraient être appliqués à d’autres architectures afin de fournir des forums pour un système de conférences.

Finalement, on notera que les utilisateurs d’IRC peuvent trouver un intérêt à certaines des sections qui suivent, en particulier les sections 2 (Caractéristiques des canaux) et 4 (Modes des canaux).


Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit dans le BCP 14, [RFC2119].


2. Caractéristiques des canaux


Un canal est un groupe désigné d’un ou plusieurs utilisateurs qui vont tous recevoir les messages adressés à ce canal. Un canal est caractérisé par son nom, des propriétés et ses membres actuels.


2.1 Espace de noms


Les noms des canaux sont des chaînes (commençant par un caractère '&', '#', '+' ou '!') d’une longueur pouvant aller jusqu’à cinquante (50) caractères. Les noms des canaux sont insensibles à la casse.


À part l’exigence que le premier caractère soit '&', '#', '+' ou '!' (appelé ici le "préfixe de canal") la seule restriction qui s’applique au nom du canal est qu’il NE DEVRA PAS contenir d’espaces (' ') de contrôle G (^G ou ASCII 7) de virgule (',' qui est utilisée par le protocole comme séparateur d’élément d’une liste). Enfin, le caractère deux-points (':') est utilisé comme délimiteur pour le gabarit de canal. La syntaxe exacte du nom de canal est définie dans la [RFC2813] "Protocole de serveur IRC".


L’utilisation des différents préfixes crée effectivement quatre (4) espaces de noms distincts pour les noms de canaux. C’est important à cause des limitations du protocole en ce qui concerne les espaces de noms (en général). Voir au paragraphe 6.1 (Étiquettes) des précisions sur ces limitations.


2.2 Portée du canal


Une entité de canal est connue par un ou plusieurs serveurs sur le réseau IRC. Un utilisateur ne peut devenir membre que d’un canal connu par le serveur auquel l’usager est directement connecté. La liste des serveurs qui connaissent l’existence d’un canal particulier DOIT être une partie contiguë du réseau IRC, afin que les messages adressés au canal soient envoyés à tous les membres du canal.


Les canaux avec une éperluette '&' comme préfixe sont locaux pour le serveur où ils sont créés.


Les autres canaux sont connus d’un (1) ou plusieurs serveurs qui sont connectés au réseau, selon le gabarit du canal :


Si il n’y a pas de gabarit de canal, le canal est alors connu de tous les serveurs.


Si il y a un gabarit de canal, le canal DOIT alors n’être connu que des serveurs qui ont un utilisateur local sur le canal, et de ses voisins si le gabarit correspond à la fois au nom du serveur local et à celui de ses voisins. Comme les autres serveurs n’ont absolument aucune connaissance de l’existence d’un tel canal, la zone formée par les serveurs qui ont un nom qui correspond au gabarit doit être contiguë pour que le canal soit connu de tous ces serveurs. Les gabarits de canal sont le mieux utilisés en conjonction avec le gabarit d’hôte de serveur [RFC2813].


2.3 Propriétés du canal


Chaque canal a ses propres propriétés, qui sont définies par mode de canal. Les modes de canal peuvent être manipulés par les membres du canal. Les modes affectent la façon dont les serveurs gèrent les canaux.


Les canaux avec '+' comme préfixe ne prennent pas en charge les modes de canal. Cela signifie que tous les modes sont non établis, à l’exception du fanion 't' de canal qui est établi.


2.4 Membres privilégiés du canal


Afin que les membres du canal gardent une certaine forme de contrôle sur un canal, et par mesure de sûreté, certains membres du canal sont privilégiés. Seuls ces membres sont autorisés à effectuer les actions suivantes sur le canal :

INVITE - Inviter un client sur un canal à invitation seule (mode +i).

KICK - Éjecter un client du canal.

MODE - Changer le mode du canal, ainsi que les privilèges des membres.

PRIVMSG - Envoyer des messages au canal (mode +n, +m, +v).

TOPIC - Changer le sujet du canal en un mode de canal +t.


2.4.1 Fonctionnement du canal

Les opérateurs du canal (qu’on appelle aussi "chop" ou "chanop" pour channel operator) sur un certain canal sont considérés comme les 'possesseurs' de ce canal. La possession d’un canal est partagé entre les opérateurs du canal.


Les opérateurs de canal sont identifiés par le symbole '@' à côté de leur pseudonyme chaque fois qu’il est associé à un canal (c’est-à-dire dans des réponses aux commandes NAMES, WHO et WHOIS).


Comme les canaux qui commencent par le caractère '+' comme préfixe ne prennent pas en charge les modes de canal, aucun membre ne peut donc avoir le statut d’opérateur de canal.


2.4.2 Créateur du canal

Un utilisateur qui crée un canal avec le caractère '!' comme préfixe est identifié comme "créateur du canal". À la création du canal, cet utilisateur reçoit aussi le statut d’opérateur du canal.


En reconnaissance de ce statut, les créateurs de canal sont dotés de la capacité de modifier certains modes du canal que les opérateurs de canal n’ont pas la permission de manipuler.


Un "créateur de canal" peut être distingué d’un opérateur de canal parce qu’il peut produire la commande MODE appropriée. Voir dans la [RFC2812] "Protocole de client IRC" des précisions sur ce sujet.


3. Durée de vie du canal


En ce qui concerne la durée de vie d’un canal, il y a normalement deux groupes de canaux : les canaux standard dont le préfixe est '&', '#' ou '+', et les "canaux sûrs" dont le préfixe est '!'.


3.1 Canaux standard


Ces canaux sont créés implicitement lorsque le premier utilisateur s’y adjoint, et ils cessent d’exister lorsque le dernier utilisateur les quitte. Tant que le canal existe, tout client peut faire référence au canal en utilisant le nom du canal.


L’utilisateur qui crée un canal devient automatiquement un opérateur de canal sauf l’exception notable des canaux dont le nom est précédé du caractère '+' (voir la section 4 Modes de canal). Des précisions sur cette question figurent au paragraphe 2.4.1 (Opérateurs de canal).


Afin d’éviter la création de canaux dupliqués (normalement lorsque le réseau IRC devient disjoint à cause d’une séparation entre deux serveurs) les noms de canal NE DEVRAIENT PAS être réutilisés par un utilisateur si un opérateur de canal (voir au paragraphe 2.4.1 Opérateurs de canal) a récemment laissé le canal à cause d’un partage du réseau. Si cela arrive, le nom du canal est temporairement indisponible. La durée pendant laquelle un canal reste indisponible devrait être réglée par chaque réseau IRC. Il est important de noter que cela empêche les utilisateurs locaux de créer un canal en utilisant le même nom, mais cela n’empêche pas que le canal soit créé à nouveau par un utilisateur distant. Cela se produit normalement lorsque le réseau IRC se réunifie. Évidemment, ce mécanisme n’a de sens que pour les canaux dont le nom commence par le caractère '#', mais il PEUT être utilisé pour les canaux dont le nom commence par le caractère '+'. Ce mécanisme est habituellement appelé "délai de canal".


3.2 Canaux sûrs


À la différence des autres canaux, les "canaux sûrs" ne sont pas créés implicitement. Un utilisateur qui souhaite créer un tel canal DOIT demander la création par l’envoi d’une commande spéciale JOIN au serveur dans laquelle l’identifiant de canal (alors encore inconnu) est remplacé par le caractère '!'. Le processus de création pour ce type de canal est strictement contrôlé. L’utilisateur choisit seulement une partie du nom du canal (qu’on appelle le "petit nom" du canal) le serveur ajoutant automatiquement le nom fourni par l’utilisateur à un identifiant de canal qui consiste en cinq (5) caractères. Le nom de canal qui résulte de la combinaison de ces deux éléments est unique, rendant le canal sûr contre des violations fondées sur des partages du réseau.


L’utilisateur qui crée un tel canal devient automatiquement un "créateur de canal". Voir au paragraphe 2.4.2 (Créateur de canal) des précisions sur ce sujet.


Un serveur NE DOIT pas permettre la création d’un nouveau canal si un autre canal avec le même petit nom existe, ou si un autre canal avec le même petit nom existait récemment ET si un ou plusieurs de ses membres ont quitté à cause d’un partage du réseau. Un tel canal cesse d’exister après que le dernier utilisateur a quitté ET qu’aucun autre membre n’a récemment quitté le canal à cause d’un partage de réseau.


À la différence du mécanisme décrit au paragraphe 5.2.2 (Délai de canal) dans ce cas, les noms de canal ne deviennent pas indisponibles : ces canaux peuvent continuer d’exister après le départ du dernier utilisateur. Seul l’utilisateur qui crée le canal devient un "créateur de canal", les utilisateurs qui se joignent à un canal vide existant ne deviennent pas automatiquement "créateur de canal" ni "opérateur de canal".


Pour assurer l’unicité des noms de canal, l’identifiant de canal créé par le serveur DOIT suivre des règles spécifiques. Pour des précisions sur cette question, voir au paragraphe 5.2.1 (Identifiant de canal).


4. Modes de canal


Les divers modes disponibles pour les canaux sont les suivants :


O – donne le statut de "créateur de canal" ;

o – donne/retire le privilège d’opérateur de canal ;

v – donne/retire le privilège vocal ;


a – bascule le fanion Canal anonyme ;

i – bascule le fanion Canal seulement sur invitation ;

m – bascule le fanion Canal à modérateur ;

n – bascule le fanion Pas de message au canal de la part de clients extérieurs ;

q – bascule le fanion Canal silencieux ;

p – bascule le fanion Canal privé ;

s – bascule le fanion Canal secret ;

r – bascule le fanion Canal reop de serveur ;

t – bascule le fanion Sujet réglable seulement par l’opérateur du canal ;


k – établi/retire la clé du canal (mot de passe) ;

l – établi/retire la limitation d’utilisateur sur le canal ;


b – établi/retire l’interdiction de gabarit pour écarter des utilisateurs ;

e – établi/retire un gabarit d’exception pour outrepasser un gabarit d’interdiction ;

I – établi/retire un gabarit d’invitation pour outrepasser automatiquement le fanion Sur invitation seulement ;


Sauf mention contraire ci-dessous, tous ces modes peuvent être manipulés par les "opérateurs de canaux" à l’aide de la commande MODE définie dans la [RFC2812] "Protocole de client IRC".


4.1 États de membre


Les modes dans cette catégorie prennent un pseudonyme de membre de canal comme argument et affectent les privilèges donnés à cet utilisateur.


4.1.1 Statut de "créateur de canal"

Le mode 'O' n’est utilisé qu’en conjonction avec les "canaux sûrs" et NE DEVRA PAS être manipulé par les utilisateurs. Les serveurs l’utilisent pour donner à l’utilisateur qui crée le canal le statut de "créateur de canal".


4.1.2 Statut d’opérateur de canal

Le mode 'o' est utilisé pour basculer du statut d’opérateur à celui de membre du canal.


4.1.3 Privilège vocal

Le mode 'v' est utilisé pour donner et retirer le privilège vocal à un membre du canal. Les utilisateurs qui ont ce privilège peuvent parler sur les canaux modérés. (Voir au paragraphe 4.2.3 (Fanion canal modéré).


4.2 Fanions de canal


Les modes de cette catégorie sont utilisés pour définir les propriétés qui affectent le fonctionnement des canaux.


4.2.1 Fanion Anonyme

Le fanion de canal 'a' définit un canal anonyme. Cela signifie que lorsque un message envoyé au canal est envoyé par le serveur aux utilisateurs, et que l’origine est un utilisateur, il DOIT alors être masqué. Pour masquer le message, l’origine est changée en "anonymous!anonymous@anonymous". (Par exemple, un utilisateur avec le pseudonyme "anonymous", le nom d’utilisateur "anonymous" et provenant d’un hôte appelé "anonymous".) À cause de cela, les serveurs DOIVENT interdire aux utilisateurs de se servir du pseudonyme "anonymous". Les serveurs NE DOIVENT PAS non plus envoyer des messages QUIT pour les utilisateurs qui quittent de tels canaux aux autres membres du canal mais générer à la place un message PART.


Sur les canaux qui ont comme préfixe le caractère '&', ce fanion peut être inversé par les opérateurs de canal, mais sur les canaux qui ont comme préfixe le caractère '!', ce fanion peut être établi (mais NE DEVRA PAS être non établi) par le seul "créateur du canal". Ce fanion NE DOIT PAS être rendu disponible sur les autres types de canaux.


Les réponses aux commandes WHOIS, WHO et NAMES NE DOIVENT PAS révéler la présence des autres utilisateurs sur les canaux pour lesquels le fanion Anonyme est établi.


4.2.2 Fanion Seulement sur invitation

Lorsque le fanion de canal 'i' est établi, les nouveaux membres ne sont acceptés que si leur gabarit correspond à la liste d’invitations (Invite-list) (voir au paragraphe 4.3.2) ou si ils ont été invités par un opérateur du canal. Ce fanion restreint aussi l’usage de la commande INVITE (voir la [RFC2812] "Protocole de client IRC") aux opérateurs de canal.


4.2.3 Fanion Canal modéré

Le fanion de canal 'm' est utilisé pour contrôler qui peut parler sur un canal. Lorsque il est établi, seuls les opérateurs du canal, et les membres auquel a été accordé le privilège vocal peuvent envoyer des messages au canal.


Ce fanion n’affecte que les utilisateurs.


4.2.4 Pas de messages au canal des clients de l’extérieur

Lorsque le fanion de canal 'n' est établi, seuls les membres du canal PEUVENT envoyer des messages au canal.


Ce fanion n’affecte que les utilisateurs.


4.2.5 Canal silencieux

Le fanion de canal 'q' est à utiliser par les seuls serveurs. Lorsque il est établi, il restreint le type de données envoyées aux utilisateurs aux opérations du canal : les adhésions des autres utilisateurs, les changements de parties et de pseudonymes ne sont pas envoyés.

Du point de vue d’un utilisateur, le canal ne contient qu’un seul utilisateur.


C’est normalement utilisé pour créer des canaux locaux particuliers sur lesquels le serveur envoie des notices qui se rapportent à son fonctionnement. Cela a été utilisé de la façon la plus efficace et la plus souple pour remplacer le mode d’utilisateur 's' défini dans la [RFC1459].


4.2.6 Canaux privés et secrets

Le fanion de canal 'p' est utilisé pour marquer un canal comme "privé" et le fanion de canal 's' pour marquer un canal comme "secret". Les deux propriétés sont similaires et dissimulent l’existence du canal aux autres utilisateurs.


Cela signifie qu’il n’y a pas de moyen d’obtenir du serveur le nom de ce canal si on n’en est pas membre. En d’autres termes, ces canaux DOIVENT être omis des réponses aux interrogations du style de la commande WHOIS.


Lorsque un canal est "secret", en plus de la restriction ci-dessus, le serveur va agir comme si le canal n’existait pas pour les interrogations comme celles des commandes TOPIC, LIST, NAMES. Noter qu’il y a une exception à cette règle : les serveurs vont répondre correctement à la commande MODE. Finalement, les canaux secrets ne sont pas pris en compte dans la réponse à la commande LUSERS (voir la [RFC2812] "Protocole de client IRC") lorsque le paramètre <gabarit> est spécifié.


Les fanions de canal 'p' et 's' NE DOIVENT PAS être établis en même temps. Si un message MODE généré par un serveur établit le fanion 'p' et que le fanion 's' est déjà établi pour le canal, le changement est ignoré en silence. Cela ne devrait survenir que dans une phase de réparation de partage (mentionnée dans la [RFC2813] "Protocole de serveur IRC").


4.2.7 Fanion Serveur Reop

Le fanion de canal 'r' n’est disponible que sur les canaux dont le nom commence par le caractère '!' et il ne PEUT être basculé que par le "créateur du canal".


Ce fanion est utilisé pour empêcher un canal de n’avoir pas d’opérateur de canal pendant une période trop longue. Lorsque ce fanion est établi, tout canal qui a perdu tous ses opérateurs de canal depuis plus longtemps que la période "reop délai" déclenche un mécanisme dans les serveurs pour désigner comme opérateur (reop) certains ou tous les habitants du canal. Ce mécanisme est décrit plus en détails au paragraphe 5.2.5 (Mécanisme Serveur Reop).


4.2.8 Sujet

Le fanion de canal 't' (pour topic) est utilisé pour restreindre l’usage de la commande TOPIC aux opérateurs de canal.


4.2.9 Limite d’utilisateur

Une limite d’utilisateur peut être établie sur les canaux en utilisant le fanion de canal 'l'. Lorsque la limite est atteinte, les serveurs DOIVENT interdire à leurs utilisateurs locaux de se joindre au canal.


La valeur de la limite DOIT n’être disponible que pour les membres du canal dans la réponse envoyée par le serveur à une interrogation MODE.


4.2.10 Clé de canal

Lorsque une clé de canal est établie (en utilisant le mode 'k') les serveurs DOIVENT rejeter les demandes de leurs utilisateurs locaux de se joindre au canal sauf si ils donnent cette clé.


La clé de canal DOIT n’être visible qu’aux membres du canal dans la réponse envoyée par le serveur à une interrogation MODE.


4.3 Contrôle d’accès de canal


La dernière catégorie de modes est utilisée pour le contrôle d’accès au canal ; ces modes prennent un gabarit comme argument.


Afin de réduire la taille de la base de données globale pour les modes de contrôle d’accès établis pour les canaux, les serveurs PEUVENT mettre une limite maximum au nombre de ces modes établis pour un canal particulier. Si une telle restriction est imposée, elle DOIT n’affecter que les demandes des utilisateurs. La limite DEVRAIT être homogène sur un même réseau IRC.


4.3.1 Interdiction de canal et exception

Lorsque un utilisateur demande à se joindre à un canal, son serveur local vérifie si l’adresse de l’utilisateur correspond à un des gabarits d’interdiction établis pour le canal. Si une correspondance est trouvée, la demande de l’utilisateur est refusée, sauf si l’adresse correspond aussi à un gabarit d’exception établi pour le canal.


Les serveurs NE DOIVENT PAS permettre qu’un membre du canal qui est interdit sur le canal parle sur le canal, sauf si ce membre est un opérateur du canal ou a le privilège vocal (voir au paragraphe 4.1.3 "Privilège vocal").


Un utilisateur qui est interdit sur un canal et qui porte une invitation envoyée par un opérateur du canal est admis à se joindre au canal.


4.3.2 Invitation de canal

Pour les canaux qui ont le fanion Seulement sur invitation établi (voir au paragraphe 4.2.2 “Seulement sur invitation”) les utilisateurs dont l’adresse correspond à un gabarit d’invitation établi pour le canal sont admis à se joindre au canal sans aucune invitation.


5. Mises en œuvre actuelles


La seule mise en œuvre actuelle de ces règles au titre du protocole IRC est le serveur IRC, version 2.10.


Le reste de cette section traite des questions qui sont importantes pour ceux qui souhaitent mettre en œuvre un serveur mais certaines parties peuvent aussi intéresser les mises en œuvre de client.


5.1 Suivi des canaux récemment utilisés


Ce mécanisme est couramment appelé le "délai de canal" et ne s’applique généralement qu’aux canaux dont le nom a pour préfixe le caractère '#' (voir au paragraphe 3.1 "Canaux standard").


Lorsque survient un partage de réseau, les serveurs DEVRAIENT garder trace des canaux qui ont perdu un "opérateur de canal" par suite de la cassure. Ces canaux sont alors dans un état spécial qui dure pendant un certain temps. Dans cet état particulier, les canaux ne peuvent pas cesser d’exister. Si tous les membres du canal le quittent, le canal devient indisponible : les clients locaux du serveur ne peuvent se joindre au canal tant qu’il est vide.


Une fois qu’un canal est indisponible, il va redevenir disponible soit parce qu’un utilisateur éloigné s’est joint au canal (le plus vraisemblablement parce que le réseau est malade) soit parce que le délai est expiré (auquel cas le canal cesse d’exister et peut être créé à nouveau).


La durée pendant laquelle la mort d’un canal est retardée DEVRAIT être réglée en prenant en considération de nombreux facteurs parmi lesquels figurent la taille (en nombre d’utilisateurs) du réseau IRC, et la durée usuelle des partages de réseau. Elle DEVRAIT être uniforme sur tous les serveurs pour un certain réseau IRC.

5.2 Canaux sûrs


Le présent document introduit la notion de "canaux sûrs". Ces canaux ont comme préfixe de nom le caractère '!' et de gros efforts sont faits pour éviter les collisions dans cet espace de noms. Les collisions ne sont pas impossibles, cependant, elles sont très improbables.


5.2.1 Identifiant de canal

L’identifiant de canal est une fonction du temps. L’heure actuelle (telle que définie sous UNIX par le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 GMT) est convertie en une chaîne de cinq (5) caractères utilisant la base suivante :

"ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"

(chaque caractère a une valeur décimale commençant à 0 pour 'A' jusqu’à 35 pour '0').


L’identifiant de canal a donc une périodicité de 36^5 secondes (environ 700 jours).


5.2.2 Délai de canal

Ces canaux DOIVENT être soumis au mécanisme de "délai de canal" décrit au paragraphe 5.1 "Délai de canal". Cependant, le mécanisme a subi une légère adaptation pour mieux répondre aux besoins.


Les serveurs DOIVENT garder trace de tous les canaux qui perdent des membres par suite d’un partage de réseau, sans prendre en considération si l’utilisateur est ou non un "opérateur du canal".


Cependant, ces canaux NE DEVIENNENT JAMAIS indisponibles, il est toujours possible de se joindre à eux même lorsque ils sont vides.


5.2.3 Fenêtre d’abus

Comme la périodicité est si longue, des attaques contre un canal particulier (son nom) ne peuvent survenir qu’une seule fois sur une très longue période. Cependant, avec de la chance et de la patience, il est toujours possible qu’un utilisateur cause une collision de canaux. Afin de l’éviter, les serveurs DOIVENT "regarder dans l’avenir" et conserver une liste des noms de canal dont l’identifiant est sur le point d’être utilisé par exemple, dans les quelques jours qui viennent). Une telle liste devrait rester petite, et ne pas constituer un fardeau pour les serveurs qui doivent l’entretenir et elle devrait être utilisée pour éviter les collisions de canal en empêchant la recréation de tels canaux pendant une plus longue période que ne le fait le délai de canal.


Finalement, un serveur PEUT choisir d’étendre cette procédure pour interdire la création de canaux avec seulement le même petit nom (ignorant alors l’identifiant de canal).


5.2.4 Préserver la santé de l’espace de noms

La combinaison des mécanismes décrits aux paragraphes 5.2.2 et 5.2.3 rend assez difficile à un utilisateur de créer une collision de canal. Cependant, un autre type d’abus consiste à créer de nombreux canaux avec le même petit nom, mais des identifiants différents. Pour empêcher que cela arrive, les serveurs DOIVENT interdire la création d’un nouveau canal avec le même petit nom qu’un canal déjà existant.


5.2.5 Mécanisme Serveur Reop

Lorsque un canal a été sans opérateur (opless) pendant plus longtemps que la période "reop délai" et que le fanion 'r' est établi (voir au paragraphe 4.2.7 (Fanion Serveur Reop)) les serveurs IRC sont chargés de donner au hasard le statut d’opérateur de canal à certain des membres.


La logique exacte utilisée pour ce mécanisme par les mises en œuvre actuelles est décrit ci-dessous. Les serveurs PEUVENT utiliser une logique différente, mais il est fortement RECOMMANDÉ que tous les serveurs utilisent la même logique sur un certain réseau IRC pour conserver la cohérence ainsi que l’équité. Pour la même raison, le "délai de reop" DEVRAIT être uniforme sur tous les serveurs pour un même réseau IRC. Comme avec le "délai de canal", la valeur du "délai de reop" DEVRAIT être réglée en prenant en considération de nombreux facteurs parmi lesquels sont la taille du réseau IRC (en nombre d’utilisateurs) et la durée habituelle des partages de réseau.


a) Le mécanisme reop est déclenché après un délai aléatoire suivant l’expiration du "délai de reop". Cela devrait limiter l’éventualité que le mécanisme soit déclenché au même moment (pour le même canal) sur deux serveurs distincts.


b) Si le canal est petit (cinq utilisateurs ou moins) et si le "délai de canal" est arrivé à expiration pour ce canal, il faut alors attribuer le statut d’opérateur à tous les membres du canal si au moins un membre est local sur le serveur.


c) Si le canal est petit (cinq utilisateurs ou moins) et si le "délai de canal" est arrivé à expiration pour ce canal, et si le "délai de reop" est arrivé a expiration depuis plus longtemps que sa valeur, il faut alors attribuer le statut d’opérateur à tous les membres du canal.


d) Pour les autres cas, on attribut le statut d’opérateur à au plus un membre sur le canal, sur la base d’une méthode incorporée au serveur. Si on ne réattribut pas la qualité d’opérateur à un membre, la méthode devrait être telle qu’un autre serveur va probablement désigner quelqu’un comme opérateur. La méthode DEVRAIT être la même sur l’ensemble du réseau. Une bonne heuristique pourrait juste attribuer la qualité d’opérateur au hasard. (La mise en œuvre actuelle essaye en fait de choisir un membre local au serveur et qui n’a pas été inactif depuis trop longtemps ; elle diffère éventuellement l’action, laissant donc à d’autres serveurs la chance de trouver un membre "pas trop inactif". Ceci est très compliqué parce que les serveurs ne connaissent que les temps"d’inactivité" de leurs utilisateurs locaux.)


6. Problèmes en cours


On connaît un certain nombre de problèmes concernant la façon dont sont gérés les canaux IRC. Certains d’entre eux peuvent être directement attribués aux règles définies dans le présent document, tandis que d’autres sont le résultat du protocole de serveur IRC [RFC2810] sous-jacent. Bien qu’il soit dérivé de la [RFC1459], le présent document introduit plusieurs nouveautés en tentant de résoudre certains des problèmes connus.


6.1 Étiquettes


Le présent document définit une des nombreuses étiquettes utilisées par le protocole IRC. Bien qu’il y ait plusieurs espaces de noms distincts (fondés sur le préfixe du nom du canal) les duplications à l’intérieur de chacun d’eux ne sont pas permises. Actuellement, il est possible aux utilisateurs sur différents serveurs de prendre l’étiquette, ce qui peut résulter en des collisions (à l’exception des canaux connus d’un seul serveur où ils peuvent être annoncés).


6.1.1 Délai de canal

Le mécanisme du délai de canal décrit au paragraphe 5.1 (Suivi des canaux récemment utilisés) et utilisé pour les canaux dont le préfixe est le caractère '#' est une simple tentative pour empêcher les collisions de se produire. L’expérience a montré que, dans des circonstances normales, il est très efficace ; cependant, il a évidemment des limitations sévères qui l’empêchent d’être une solution adéquate pour le problème exposé ici.


6.1.2 Canaux sûrs

Les "canaux sûrs" décrits au paragraphe 3.2 (Canaux sûrs) sont un meilleur moyen pour empêcher les collisions de survenir car il empêche les utilisateurs d’avoir un contrôle total sur leur choix d’étiquette. L’inconvénient évident de telles étiquettes est qu’elles ne sont pas très conviviales. Cependant, il est parfaitement trivial pour un programme client d’y apporter des améliorations.


6.2 Délais de propagation de mode


À cause des délais de réseau induits par le réseau, et parce que il est EXIGÉ de chaque serveur sur le chemin qu’il vérifie la validité des changements de mode (par exemple, l’utilisateur existe et a les bons privilèges) il n’est pas anormal pour un message MODE de n’affecter qu’une partie du réseau, créant souvent une discordance entre les serveurs quant à l’état actuel d’un canal.


Bien que cela puisse sembler facile à corriger en faisant que seul le serveur d’origine vérifie la validité des changements de modes) il a été décidé de ne pas faire ainsi pour diverses raisons. Un souci est que les serveurs ne peuvent pas se faire mutuellement confiance, et que des serveurs qui se conduisent mal vont être facilement détectés. Cette façon de faire arrête aussi les effets de vague sur des canaux qui sont hors synchronisation lorsque les changements de mode sont produits par des directions différentes.


6.3 Collisions et modes de canal


La [RFC2813] "Relais pour la causette Internet : protocole serveur" décrit comment les données du canal sont échangées lorsque deux serveurs se connectent ensemble. Les collisions de canal (légitimes ou non) sont traitées comme des événements inclusifs, ce qui signifie que le canal résultant a pour membres tous les utilisateurs qui sont membres du canal sur l’un ou l’autre serveur avant la connexion.


De même, les deux serveurs s’envoient les modes de canal. Donc, chaque serveur reçoit aussi ces modes de canal. Il y a trois types de modes pour chaque canal : fanions, gabarits, et données. Les deux premiers types sont faciles à traiter car ils sont soit établi, soit non établi. Si un tel mode est établi sur un serveur, il DOIT être établi sur l’autre serveur par suite de la connexion.


Comme les sujets ne sont pas envoyés au titre de cet échange, ils ne posent pas de problème. Cependant, les modes de canal 'l' et 'k' sont échangés, et si ils sont établis sur les deux serveurs avant leur connexion, il n’y a pas de mécanisme pour décider laquelle des deux valeurs a la préséance. Il appartient aux utilisateur de réparer la discordance résultante.


6.4 Épuisement des ressources


Le mode fondé sur les gabarits défini au paragraphe 4.3 rend les serveurs IRC (et le réseau) vulnérables à un simple abus du système : un seul opérateur de canal peut régler autant de gabarits différents que possible sur un certain canal. Cela peut facilement causer un gaspillage de mémoire chez le serveur, ainsi que de la bande passante du réseau (car les informations sont propagées aux autres serveurs). Pour cette raison, il est RECOMMANDÉ qu’une limite soit établie quant au nombre de tels gabarits par canal, comme mentionné au paragraphe 4.3.


De plus, des mécanismes plus complexes PEUVENT être utilisés pour éviter d’avoir des gabarits redondants établis pour le même canal.


7. Considérations pour la sécurité

7.1 Contrôle d’accès


Une des principales façons de contrôler l’accès à un canal est d’utiliser des gabarits qui sont fondés sur le nom d’utilisateur et le nom d’hôte des connexions d’utilisateur. Ce mécanisme ne peut être efficace et sûr que si les serveurs IRC ont un moyen précis d’authentifier les connexions d’utilisateur, et si les utilisateurs ne peuvent pas le contourner facilement. Bien qu’il soit théoriquement possible de mettre en œuvre un tel mécanisme strict d’authentification, la plupart des réseaux IRC (en particulier les réseaux publics) n’ont rien de tout cela en place et fournissent peu de garanties sur la précision du nom d’utilisateur et du nom d’hôte pour une connexion client.


Une autre façon de contrôler l’accès est d’utiliser une clé de canal, mais comme cette clé est envoyée en clair, elle est vulnérable aux attaques traditionnelles par interposition.


7.2 Confidentialité du canal


Comme les collisions de canal sont traitées comme des événements inclusifs (voir au paragraphe 6.3) il est possible à des utilisateurs de se joindre à un canal en outrepassant ses réglages de contrôle d’accès. Cette méthode a longtemps été utilisée par des individus pour "subvertir" des canaux en obtenant de façon "illégitime" le statut d’opérateur du canal. La même méthode peut être utilisée pour découvrir la liste exacte des membres d’un canal, ainsi que finalement recevoir certains des messages envoyés au canal.


7.3 Anonymat


Le fanion Canal anonyme (voir au paragraphe 4.2.1) peut être utilisé pour rendre "anonymes" tous les utilisateurs sur un tel canal en présentant tous les messages au canal comme générés à partir d’un pseudo utilisateur dont le pseudonyme est "anonymous". Cela se fait au niveau client-serveur, et aucun anonymat n’est fourni au niveau serveur-serveur.


Il devrait être évident au lecteur que le niveau d’anonymat offert est assez pauvre et peu sûr, et que les clients DEVRAIENT afficher de forts avertissements pour les utilisateurs qui se joignent à de tels canaux.


8. Prise en charge et disponibilité actuelle


Listes de diffusion de discussion en rapport avec IRC :

Discussion générale : ircd-users@irc.org

Développement de protocole : ircd-dev@irc.org


Mises en œuvre de logiciels :

ftp://ftp.irc.org/irc/server

ftp://ftp.funet.fi/pub/unix/irc

ftp://coombs.anu.edu.au/pub/irc


Groupe de nouvelles : alt.irc



9. Remerciements


Certaines parties du présent document ont été copiées de la [RFC1459] qui a été la première à documenter formellement le protocole IRC. Il a aussi bénéficié de nombreuses séances de révision et de commentaires. En particulier, les personnes suivantes ont fourni des contributions significatives à ce document : Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.



10. Références


[RFC1459] J. Oikarinen et D. Reed, "Protocole Internet de relais de débats", mai 1993. (Exp.)


[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.


[RFC2810] C. Kalt, "Relais pour la causette Internet : architecture", avril 2000. (Information)


[RFC2812] C. Kalt, "Relais pour la causette Internet : protocole client", avril 2000. (Information)


[RFC2813] C. Kalt, "Relais pour la causette Internet : protocole serveur", avril 2000. (Information)



11. Adresse de l’auteur


Christophe Kalt

99 Teaneck Rd, Apt #117

Ridgefield Park, NJ 07660

USA

mél : kalt@stealth.net


12. Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2000). Tous droits réservés.


Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant la notice de droits d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.