Network Working Group C.Kalt Request For Comments: 2811 Abril 2000 Actualizaciones: 1459 Traducción: Carlos García Argos Categoría: Información Charla Basada en Internet: Mantenimiento de canales Estado de este memorándum Este memo da información para la comunidad Internet. No especifica un estándar de Internet. La distribución de este memorándum es ilimitada. Aviso de Copyright Copyright (C) The Internet Society 2000. Todos los derechos reservados. Resumen Una de las características más importantes del IRC es que permite agrupar a varios usuarios en foros, llamados canales, proporcionando una forma de comunicación simultánea entre varios usuarios. Inicialmente existía un sólo tipo de canales, pero con los años, han aparecido nuevos tipos, bien como solución a una necesidad o para experimentación. Este documento especifica cómo los servidores manejan los canales, sus características y propiedades. Índice 1. Introducción .................................................. 3 2. Características de los canales ................................ 3 2.1. Espacio de Nombres ........................................ 3 2.2. Enfoque de los canales .................................... 4 2.3. Propiedades de canal ...................................... 5 2.4. Miembros de canal privilegiados ........................... 5 2.4.1. Operadores de canal ................................... 5 2.4.2. Creador de canal ...................................... 5 3. Tiempo de vida de un canal .................................... 6 3.1. Canales estándar .......................................... 6 3.2. Canales seguros ........................................... 7 4. Modos de canales .............................................. 8 4.1. Estatus de miembros ....................................... 8 4.1.1. Estatus de "creador de canal" ......................... 9 4.1.2. Estatus de operador de canal .......................... 9 Kalt Información [Pág. 1] RFC 2811 Charla Basada en Internet: Canales Abril 2000 4.1.3. Privilegio de voz ..................................... 9 4.2. Modos de canal ............................................ 9 4.2.1. Modo anónimo .......................................... 9 4.2.2. Modo de sólo invitados ................................10 4.2.3. Modo de canal moderado ................................10 4.2.4. Modo de no mensajes exteriores ........................10 4.2.5. Modo de canal callado .................................10 4.2.6. Canales privados y secretos ...........................11 4.2.7. Modo de reop de servidor ..............................11 4.2.8. Tópico ................................................12 4.2.9. Límite de usuarios ....................................12 4.2.10. Clave de canal .......................................12 4.3. Control de acceso al canal ................................12 4.3.1. Prohibición de entrada al canal y excepciones .........13 4.3.2. Invitación de canal ...................................13 5. Implementaciones actuales .....................................13 5.1. Seguimiento de canales recientes ..........................14 5.2. Canales seguros ...........................................14 5.2.1. Identificador de canal ................................14 5.2.2. Retardo de canal ......................................15 5.2.3. Ventana de abusos .....................................15 5.2.4. Preservando la salud del espacio de nombres ...........16 5.2.5. Mecanismo de reop .....................................16 6. Problemas actuales ............................................17 6.1. Etiquetas .................................................17 6.1.1. Retardo de canal ......................................18 6.1.2. Canales seguros .......................................18 6.2. Retardos de propagación de los modos ......................18 6.3. Colisiones y modos de canales .............................18 6.4. Consumo de recursos .......................................19 7. Consideraciones sobre seguridad ...............................20 7.1. Control de acceso .........................................20 7.2. Privacidad de los canales .................................20 7.3. Anonimato .................................................20 8. Soporte y disponibilidad actual ...............................21 9. Reconocimientos ...............................................21 10. Referencias ..................................................21 11. Dirección del autor ..........................................22 12. Dirección del traductor ......................................22 Kalt Información [Pág. 2] RFC 2811 Charla Basada en Internet: Canales Abril 2000 1. Introducción Este documento describe con detalle cómo los servidores de IRC mantienen los canales y resultará muy util a aquellas personas que tratan de implementar un servidor de IRC. Aunque los conceptos que se definen en este documento son una parte importante del IRC, no son esenciales para implementar clientes. La tendencia parece ser la implementación de clientes más complejos e "inteligentes" que aprovechan el funcionamiento interno de los canales, para dar una interfaz más amigable, pero clientes más sim­ ples pueden implementarse sin leer este documento. Muchos de los conceptos que aquí se presentan se diseñaron teniendo en cuenta la arquitectura del IRC [ARQUITECTURA-IRC] y tienen sentido mayoritariamente dentro de este contexto. Sin embargo, muchos otros conceptos pueden aplicarse a otras arquitecturas para proporcionar foros en un sistema de conferencias. Por último, es de resaltar que los usuarios del IRC pueden encontrar algunas de las secciones de este documento interesantes, sobre todo las secciones 2 (Características de los canales) y 4 (Modos de canales). 2. Características de los canales Un canal es un grupo, que se designa con un nombre, de uno o más usuarios que recibirán todos los mensajes dirigidos a ese canal. Un canal se caracteriza por su nombre, sus propiedades y sus miembros. 2.1. Espacio de Nombres Los nombres de canales son cadenas de caracteres (que comienzan con '&', '#', '+' o '!') de longitud máxima 50 caracteres. Los nombres de canales no son sensibles a las mayúsculas. Aparte del requerimiento que el primer carácter sea '&', '#', '+' o Kalt Información [Pág. 3] RFC 2811 Charla Basada en Internet: Canales Abril 2000 '!' (llamado "prefijo del canal"), la única restricción en un nombre de canal es que no contenga espacios en blanco (' '), un control G ('^G' o ASCII 7), una coma (',' que el protocolo usa como separador de ítemes). Además, los dos puntos (':') se usan como delimitador para la máscara del canal. La sintaxis exacta para el nombre de canales se define en "Protocolo de Servidor de IRC" [SERVIDOR-IRC]. El uso de prefijos diferentes genera cuatro espacios de nombres dis­ tintos para los nombres de canales. Esto es importante por las lim­ itaciones del protocolo en cuanto a nombres de canales. Ver la sección 6.1 (Etiquetas) para más detalles sobre estas limitaciones. 2.2. Enfoque de los canales Una entidad de canal la conocen uno o más servidores en la red de IRC. Un usuario sólo puede ser miembro de un canal que conozca el servidor de la red al que está directamente conectado. La lista de servidores que conocen la existencia de un canal en particular DEBE ser una parte contigua de la red de IRC, para que los mensajes dirigidos al canal se envíen a todos sus miembros. Los canales con el carácter '&' como prefijo son locales al servidor donde se crean. Los otros canales son conocidos por uno o más servidores conectados a la red, dependiendo de la máscara de canal: Si no hay máscara de canal, es conocido por todos los servidores de la red. Si hay máscara de canal, el canal sólo es conocido por los servi­ dores que tienen un usuario local en el canal y a sus vecinos si la máscara coincide con los servidores local y vecino. Dado que los demás servidores no tienen conocimiento del canal, el área formada por los servidores cuyo nombre coincida con la máscara debe ser contigua para que todos los servidores puedan conocer el canal. Las máscaras de canal se usan más adecuadamente en conjunción con enmascaramiento de host del servidor [SERVIDOR-IRC]. Kalt Información [Pág. 4] RFC 2811 Charla Basada en Internet: Canales Abril 2000 2.3. Propiedades de canal Cada canal tiene sus propiedades, definidas por los modos de canal. Los modos del canal pueden ser modificados por los usuarios del canal. Esto significa que todos los modos del canal están desactiva­ dos, con la salvedad del modo 't' que está activado. 2.4. Miembros de canal privilegiados Para que los miembros del canal puedan tener cierto control sobre el canal y un poco de cordura, hay algunos miembros de canal con privi­ legios. Sólo estos miembros pueden efectuar las siguientes acciones en el canal: INVITE - Invitar a un cliente a un canal sólo para invitados (modo +i) KICK - Expulsar a un cliente del canal MODE - Cambiar modos de canal y privilegios de los miembros PRIVMSG - Enviar mensajes al canal (modos +n, +m, +v) TOPIC - Cambiar el tópico en un canal con el modo +t activo 2.4.1. Operadores de canal Los operadores de canal (también conocidos como "chop" o "chanop", en inglés y "op" en español, N. del T.) de un canal dado, se consideran como 'poseedores' de ese canal. Esta posesión se comparte entre los operadores del canal. Los operadores de canal se identifican por el símbolo '@' al lado de su nick siempre que se le asocie con el canal (por ejemplo, respues­ tas a los comandos NAMES, WHO y WHOIS). Dado que los canales con el prefijo '+' no soportan los modos de canal, ningún miembro puede poseer el estatus de operador. 2.4.2. Creador de canal Kalt Información [Pág. 5] RFC 2811 Charla Basada en Internet: Canales Abril 2000 Un usuario que crea un canal con el carácter '!' como prefijo se identifica como el 'creador del canal'. En la creación de dicho canal, a este usuario también se le da el estatus de operador. Como reconocimiento a este estatus, los creadores de canal pueden cambiar algunos modos de canal que los operadores de canal no pueden. Un creador de canal puede distinguirse de un operador de canal ejecu­ tando el comando MODE apropiado. Vea el "Protocolo de Cliente de IRC" [CLIENTE-IRC] para más información al respecto. 3. Tiempo de vida de un canal En lo referente al tiempo de vida de un canal, hay dos grupos de canales típicos: los canales estándar cuyo prefijo es '#', '&' o '+' y los "canales seguros" cuyo prefijo es '!'. 3.1. Canales estándar Estos canales se crean implícitamente al entrar el primer usuario en él y deja de existir cuando el último usuario lo abandona. Mientras el canal exista, cualquier cliente puede referirse al canal usando su nombre. El usuario creador de un canal automáticamente obtiene el estatus de operador de canal, con la excepción de los canales cuyo prefijo es '+', ver sección 4 (Modos de canales). Ver la sección 2.4.1 (Oper­ adores de canal) para más detalles sobre el tema. Para evitar que se creen canales duplicados (normalmente cuando la red de IRC se separa debido a la desconexión entre dos servidores), los nombres de canal NO DEBERÍAN poder ser usados por un usuario si un operador de canal (ver sección 2.4.1, Operadores de Canal) ha dejado el canal debido a una separación de la red. Si esto ocurre, la red está inaccesible temporalmente. El tiempo que un canal permanece inaccesible debe ajustarse en base a la red de IRC. Es importante advertir que esto evita que un usuario local cree un canal del mismo Kalt Información [Pág. 6] RFC 2811 Charla Basada en Internet: Canales Abril 2000 nombre, pero no que un usuario remoto recree el canal. Esto último ocurre generalmente cuando la red vuelve a unirse. Obviamente, este mecanismo sólo tiene sentido con canales cuyo nombre empieza con '#', pero PUEDE usarse para canales que empiezan con '+'. Este mecanismo se conoce comúnmente como "Retardo de canal". 3.2. Canales seguros Al contrario que el resto de los canales, los "canales seguros" no se crean implícitamente. Un usuario que desee crear un canal de este tipo, DEBE hacer una petición de su creación enviando al servidor un comando JOIN especial en el cual el identificador del canal (entonces desconocido) se reemplaza por el carácter '!'. El proceso de creación de este tipo de canales está estrictamente controlado. El usuario sólo escoje parte del nombre del canal (que se denomina el "nombre abreviado" del canal), el servidor automáticamente antepone al nombre dado por el usuario un identificador que consta de 5 caracteres. El nombre de canal que resulta de la combinación de los dos elementos es único haciendo que el canal esté a salvo de abusos basados en separa­ ciones de la red. El usuario que crea un canal de este tipo automáticamente es "creador de canal". Ver la sección 2.4.2 (Creador de canal) para más detalles. Un servidor NO DEBE permitir la creación de un canal nuevo si ya existe un canal con el mismo nombre abreviado o si existía reciente­ mente Y alguno de sus miembros dejó el canal a causa de una sepa­ ración de la red. Al contrario que el mecanismo descrito en la sección 5.2.2 (Retardo de canal), en este caso, el canal no se vuelve inaccesible: estos canales pueden existir después que el último usuario deje el canal. Sólo el usuario que creó el canal es "creador de canal", los usuarios que entran a un canal vacío existente no son "creadores de canal" ni "operadores de canal" automáticamente. Para asegurar la unicidad de los nombres de canal, el identificador de canal creado por el servidor DEBE seguir reglas específicas. Para más detalles, ver la sección 5.2.1 (Identificador de canal). Kalt Información [Pág. 7] RFC 2811 Charla Basada en Internet: Canales Abril 2000 4. Modos de canales Los modos disponibles para los canales son los siguientes: O - dar estatus de "creador de canal" o - dar/quitar privilegio de operador de canal v - dar/quitar privilegio de voz a - cambiar el estado de canal anónimo i - cambiar el modo de sólo invitados m - cambiar el modo de canal moderado n - cambiar el modo de no recibir mensajes desde clientes fuera del canal q - cambiar el modo de canal callado p - cambiar el modo de canal privado s - cambiar el modo de canal secreto r - cambiar el modo de reop del canal t - cambiar el modo que permite cambiar el tópico sólo a los operadores de canal k - poner/quitar la clave del canal l - poner/quitar el límite de usuarios del canal b - poner/quitar una máscara de ban para mantener usuarios fuera del canal e - poner/quitar una máscara de excepción para reemplazar una máscara de ban I - poner/quitar una máscara de invitación para reemplazar el modo de sólo invitados automáticamente A menos que se especifique lo contrario, todos estos modos pueden ser cambiados por los "operadores de canal" por medio del comando MODE descrito en "Protocolo de Cliente IRC" [CLIENTE-IRC]. 4.1. Estatus de miembros Los modos en esta categoría pueden tomar el apodo de un miembro de canal como argumento y modificar los privilegios de ese usuario. Kalt Información [Pág. 8] RFC 2811 Charla Basada en Internet: Canales Abril 2000 4.1.1. Estatus de "creador de canal" El modo 'O' se usa únicamente con "canales seguros" y NO DEBE ser modificado por los usuarios. Los servidores lo usan para dar al usuario que creó el canal estatus de "creador del canal". 4.1.2. Estatus de operador de canal El modo 'o' se usa para modificar el estatus de operador de un miem­ bro de canal. 4.1.3. Privilegio de voz El modo 'v' se usa para dar y quitar privilegio de voz sobre un miem­ bro del canal. Los usuarios con este privilegio pueden hablar en un canal moderado (ver sección 4.2.3, Modo de canal moderado). 4.2. Modos de canal Los modos que se definen aquí se usan para definir propiedades que afectan la forma de operar de los canales. 4.2.1. Modo anónimo El modo 'a' define un canal anónimo. Esto significa que cuando un usuario envía un mensaje al canal, al enviarlo el servidor a los demás usuarios, el mensaje DEBE enmascararse. Para enmascarar el men­ saje, se cambia su origen a "anonymous!anonymous@anonymous" ("anónimo!anónimo@anónimo"). Por esta razón, los servidores DEBEN prohibir el uso del nick "anonymous" ("anónimo"). Además, los servi­ dores NO DEBEN enviar mensajes de QUIT de los usuarios que abandonan estos canales a los demás miembros, sino generar un mensaje de PART en su lugar. En los canales con el prefijo '&', este modo PUEDE cambiarlo uno de los operadores de canal, pero en los canales con el prefijo '!', sólo Kalt Información [Pág. 9] RFC 2811 Charla Basada en Internet: Canales Abril 2000 puede activarla (y NO DEBERÁ desactivarse) el "creador del canal". Este modo NO DEBE estar disponible para otro tipo de canales. Las respuestas a WHOIS, WHO y NAMES NO DEBEN revelar la presencia de otros usuarios en canales en los que el modo anónimo está activado. 4.2.2. Modo de sólo invitados Cuando el modo 'i' está activado en un canal, sólo se admiten nuevos miembros si su máscara cumple la Lista de Invitados (ver sección 4.3.2) o han sido invitados por un operador de canal. Este modo también restringe el uso del comando INVITE (ver "Protocolo de Cliente IRC" [CLIENTE-IRC]) a los operadores de canal. 4.2.3. Modo de canal moderado El modo de canal 'm' se usa para controlar quién puede hablar en un canal. Cuando se activa, sólo los operadores de canal y los miembros que tienen el privilegio de voz pueden enviar mensajes al canal. Este modo sólo afecta a los usuarios. 4.2.4. Modo de no mensajes exteriores Cuando el modo 'n' está activado, sólo los miembros del canal PUEDEN enviar mensajes al canal. Este modo sólo afecta a los usuarios. 4.2.5. Modo de canal callado El modo 'q' sólo es para uso de los servidores. Cuando está activado, restringe el tipo de datos que se envía a los usuarios sobre las operaciones del canal: no se envían mensajes de otros usuarios entrando al canal, saliendo y cambios de nick. Desde el punto de vista de un usuario, el canal sólo tiene un miembro. Kalt Información [Pág. 10] RFC 2811 Charla Basada en Internet: Canales Abril 2000 Esto se usa normalmente para crear canales locales especiales a los que el servidor envía noticias relacionadas con sus operaciones. Esto se usó como una forma más eficiente y flexible de reemplazar el modo 's' definida en el RFC 1459 [IRC]. 4.2.6. Canales privados y secretos El modo de canal 'p' se usa para marcar un canal como "privado" y el modo 's' para marcarlo como "secreto". Las dos propiedades son simi­ lares y ocultan la existencia del canal a los demás usuarios. Esto implica que no hay forma de obtener el nombre del canal desde el servidor si no se es miembro de él. En otras palabras, estos canales DEBEN omitirse de las respuestas a los comandos como WHOIS. Cuando un canal es "secreto", además de la restricción anterior, el servidor actuará como si el canal no existiese para peticiones como los comandos TOPIC, LIST y NAMES. Advierta que hay una excepción a esta regla: los servidores responderán correctamente al comando MODE. Por último, los canales secretos no se cuentan en la respuesta al comando LUSERS (ver "Protocolo de Cliente IRC" [CLIENTE-IRC]) cuando se especifica el parámetro . Los modos 'p' y 's' NO DEBEN activarse a la vez. Si un mensaje MODE desde un servidor activa el modo 'p' y el modo 's' está activado pre­ viamente, el cambio se ignora de forma silenciosa. Esto sólo debería ocurrir durante una fase de recuperación de separación de red (men­ cionado en el documento "Protocolo de Servidor de IRC" [SERVIDOR- IRC]). 4.2.7. Modo de reop de servidor El modo de canal 'r' sólo está disponible para canales cuyo nombre empieza por '!' y sólo PUEDE cambiarlo el "creador del canal". Este modo se usa para evitar que el canal no tenga operadores durante mucho tiempo. Cuando está activo, en un canal que haya perdido todos sus operadores de canal por más tiempo que el periodo de "retardo de Kalt Información [Pág. 11] RFC 2811 Charla Basada en Internet: Canales Abril 2000 reop" activa un mecanismo en los servidores para reopear (coloquial: volver a dar privilegio de operador de canal) alguno o a todos los miembros del canal. Este mecanismo se describe en más detalle en la sección 5.2.4 (Mecanismo de reop de canal). 4.2.8. Tópico El modo 't' se usa para restringir el uso del comando TOPIC a los operadores del canal. 4.2.9. Límite de usuarios Se puede poner un límite de usuarios en un canal usando el modo de canal 'l'. Cuando se alcance este límite, los servidores DEBEN pro­ hibir que sus usuarios locales entren al canal. El valor del límite DEBE hacerse disponible a los miembros del canal sólo en la respuesta enviada por el servidor al comando MODE. 4.2.10. Clave de canal Cuando se pone una clave al canal (usando el modo 'k'), los servi­ dores DEBEN rechazar las peticiones de sus usuarios locales de entrar al canal a menos que proporcionen la clave. La clave sólo DEBE ser visible por los miembros del canal en la respuesta enviada por el servidor al comando MODE. 4.3. Control de acceso al canal La última categoría de modos se usa para controlar los accesos al canal, y tienen como argumento una máscara. Para reducir el tamaño de la base de datos global para los modos de control de acceso de los canales, los servidores PUEDEN poner un tope Kalt Información [Pág. 12] RFC 2811 Charla Basada en Internet: Canales Abril 2000 al número de estos modos para un canal en particular. Si se impone este tipo de restricción, sólo DEBE afectar a las peticiones de los usuarios. El límite DEBERÍA ser homogéneo en base a la red de IRC. 4.3.1. Prohibición de entrada al canal y excepciones Cuando un usuario pide entrar a un canal, su servidor local chequea la dirección del usuario y comprueba si cumple alguna de las máscaras de prohibición del canal. Si es así, se rechaza la petición a menos que la dirección también cumpla alguna de las máscaras de excepción del canal. Los servidores NO DEBEN permitir que un miembro de canal baneado (al que se le ha prohibido la entrada, de ahora en adelante, "baneado", "banear" y "ban") hable en el canal a menos que sea un operador de canal o tenga privilegio de voz. (Ver sección 4.1.3: "Privilegio de Voz"). Un usuario baneado de un canal que reciba una invitación de un oper­ ador de canal puede entrar al canal. 4.3.2. Invitación de canal Para los canales que tengan el modo de sólo invitados activado (ver sección 4.2.2, "Modo de sólo invitados"), los usuarios cuya dirección coincida con la máscara de invitación del canal pueden entrar sin invitación. 5. Implementaciones actuales La única implementación en este momento de estas reglas como parte del protocolo IRC es el servidor de IRC, versión 2.10. El resto de esta sección trata de los apartados que son de mayor importancia al implementar un servidor pero algunas partes pueden ser también interesantes para los programadores de clientes. Kalt Información [Pág. 13] RFC 2811 Charla Basada en Internet: Canales Abril 2000 5.1. Seguimiento de canales recientes Este mecanismo se conoce normalmente como "Retardo de Canal" y gen­ eralmente sólo afecta a canales cuyo nombre comienza con '#' (Ver sección 3.1, "Canales Estándar"). Cuando hay una separación de la red, los servidores DEBERÍAN hacer un seguimiento de los canales que han perdido un operador de canal como conscuencia de la separación. Estos canales están entonces en un estado especial que dura un periodo de tiempo concreto. En este estado, los canales no pueden dejar de existir. Si todos los miembros del canal lo abandonan, el canal se hace inaccesible: los clientes locales al servidor no pueden entrar al canal mientras permanezca vacío. Una vez que un canal se hace inaccesible, volverá a ser accesible bien porque ha entrado un usuario remoto (muy probablemente porque la red se ha vuelto a unir) o porque el periodo del retardo de canal ha caducado (en cuyo caso el canal deja de existir y puede volver a crearse). El tiempo que debería retrasarse la desaparición del canal DEBERÍA calcularse considerando muchos factores entre los que se encuentra el tamaño (en términos de usuarios) de la red de IRC y la duración habitual de las separaciones. DEBERÍA ser uniforme en todos los servidores de la red de IRC. 5.2. Canales seguros Este documento introduce la noción de "canales seguros". Estos canales tienen un nombre precedido por el carácter '!' y se hace un gran esfuerzo por evitar las colisiones en este espacio de nombres. Las colisiones no son imposibles, sin embargo, son muy improbables. 5.2.1. Identificador de canal El identificador del canal es una función del tiempo. La hora actual (como se define bajo UNIX por el número de segundos transcurridos Kalt Información [Pág. 14] RFC 2811 Charla Basada en Internet: Canales Abril 2000 desde el 1 de Enero de 1970 a las 00:00:00 GMT) se convierte a una cadena de 5 caracteres usando la siguiente base: "ABCDEFGHI­ JKLMNOPQRSTUVWXYZ1234567890" (cada carácter tiene un valor decimal comenzando desde 0 para 'A' hasta 35 para '0'). Por tanto, el identificador de canal tiene una periodicidad de 36^5 segundos (unos 700 días). 5.2.2. Retardo de canal Estos canales DEBEN someterse al mecanismo del "retardo de canal" descrito en la sección 5.1. Sin embargo, este mecanismo se modifica ligeramente para adaptarse mejor. Los servidores DEBEN mantener un seguimiento de los canales que pier­ den miembros como resultado de una separación de la red, ya sean operadores de canal o no. Sin embargo, estos canales NO se hacen inaccesibles nunca, siempre es posible entrar a ellos incluso cuando están vacíos. 5.2.3. Ventana de abusos Debido a que la periodicidad es muy alta, puede haber ataques en un (nombre de) canal específico, una vez cada mucho tiempo. Sin embargo, con suerte y paciencia, es posible que un usuario genere una colisión en los canales. Para evitarlo, los servidores DEBEN "mirar al futuro" y mantener una lista de los nombres de canales cuyo identificador vaya a usarse (en los días siguientes por ejemplo). Dicha lista deberá ser pequeña, no una preocupación para los servidores y usarse para evitar las colisiones de canales impidiendo la re-creación de los canales de la lista en un periodo de tiempo mayor que el retardo de canal. En ocasiones, un servidor PUEDE extender este procedimiento para pro­ hibir sólo la creación de canales con el mismo nombre abreviado (ignorando el identificador de canal). Kalt Información [Pág. 15] RFC 2811 Charla Basada en Internet: Canales Abril 2000 5.2.4. Preservando la salud del espacio de nombres La combinación de los mecanismos descritos en las secciones 5.2.2 y 5.2.3 hace bastante complicado que un usuario genere una colisión de canal. Sin embargo, otro tipo de abuso consiste en crear muchos canales con el mismo nombre abreviado pero con identificadores dis­ tintos. Para evitar esto, los servidores DEBEN prohibir la creación de un canal nuevo que tenga el mismo nombre abreviado que un canal que ya exista. 5.2.5. Mecanismo de reop Cuando un canal ha permanecido sin operadores de canal por más tiempo que el "retardo de reop" y tiene el modo 'r' activado (ver sección 4.2.7, "Modo de reop de servidor"), los servidores de IRC son los responsables de dar el estatus de operador de canal a uno de sus miembros aleatoriamente. La lógica exacta usada por este mecanismo en la implementación actual se describe más abajo. Los servidores PUEDEN usar una lógica dis­ tinta, pero se RECOMIENDA encarecidamente que todos los servidores de una red de IRC usen la misma lógica para mantener la coherencia y la justicia. Por la misma razón, el "retardo de reop" DEBERÍA ser uni­ forme en todos los servidores de una red de IRC. De la misma forma que para el "retardo de canal", el valor del "retardo de reop" DEBERÍA ponerse en función de muchos factores entre los cuales se encuentra el tamaño de la red de IRC y la duración habitual de las separaciones de la red. a) el mecanismo de reop se dispara después de un tiempo aleatorio tras haber pasado el periodo del "retardo de reop". Esto debería evitar que el mecanismo se dispare en dos servidores distintos a la vez (para un mismo canal). b) si el canal es pequeño (5 usuarios o menos) y el "retardo de canal" para ese canal ha pasado, Entonces reopear a todos los miembros del canal si al menos uno de ellos es local al servidor. Kalt Información [Pág. 16] RFC 2811 Charla Basada en Internet: Canales Abril 2000 c) si el canal es pequeño (5 usuarios o menos) y el "retardo de canal" para ese canal ha pasado y el "retardo de reop" también ha pasado, Entonces reopear a todos los miembros del canal. d) para otros casos, reopear como mucho uno de los miembros del canal, basándose en algún método interno al servidor. Si un servi­ dor no reopea a un miembro, el método debería ser tal que otro servidor probablemente lo haga. El método DEBERÍA ser el mismo para todos los servidores de la red. Una buena heurística podría ser simplemente reopear al azar. (La implementación actual intenta escojer un miembro local al servidor que no haya estado inactivo durante mucho tiempo, posponiendo la acción para dejar a los demás servidores que encuentren algún miembro que no haya estado inactivo durante demasiado tiempo. Esto es complicado debido al hecho que los servidores sólo conocen el tiempo de inactividad de sus usuar­ ios locales). 6. Problemas actuales Hay algunos problemas reconocidos en la forma en que se manejan los canales de IRC. Algunos pueden atribuirse directamente a las reglas definidas en este documento, mientras que otros son resultado del propio "Protocolo de Servidor de IRC" [SERVIDOR-IRC]. Aunque está derivado del RFC 1459 [IRC], este documento introduce algunas novedades en un intento de solucionar algunos de los problemas cono­ cidos. 6.1. Etiquetas Este documento describe algunas de las muchas etiquetas usadas en el protocolo IRC. Aunque hay varios espacios de nombre distintos (basa­ dos en el prefijo del nombre de canal), no se permiten duplicados en cada uno de ellos. Es posible que usuarios en servidores distintos escojan una etiqueta que pueda resultar en colisiones (con la excepción de los canales que sólo conoce el servidor en el que están alojados). Kalt Información [Pág. 17] RFC 2811 Charla Basada en Internet: Canales Abril 2000 6.1.1. Retardo de canal El mecanismo de retardo de canal descrito en la sección 5.1 (Seguimiento de canales recientes) usado para canales con el prefijo '#' es un intento simple de prevenir colisiones. La experiencia ha mostrado que, bajo circunstancias normales, es muy eficiente; sin embargo, tiene limitaciones que hacen que no sea la solución más ade­ cuada al problema que aquí se trata. 6.1.2. Canales seguros Los "canales seguros" descritos en la sección 3.2 son una forma más adecuada de prevenir las colisiones ya que evita que los usuarios tengan un control total sobre la etiqueta que escojen. La desventaja obvia de estas etiquetas es que no son muy intuitivas. Sin embargo, es bastante trivial la mejora de esto para un programa cliente. 6.2. Retardos de propagación de los modos Debido a los retrasos que se producen en la red y porque se REQUIERE que cada servidor verifique la validez de los cambios de modo (por ejemplo, el usuario existe y tiene los privilegios adecuados), no es infrecuente que un comando MODE sólo afecte a parte de la red, a menudo creando discrepancias entre servidores sobre el estado de la red. Aunque esto puede parecer sencillo de arreglar (con hacer que única­ mente el servidor de origen chequee la validez de los cambios de modo), se decidió no hacerlo por varias razones. Una de las preocupa­ ciones es que los servidores no pueden fiarse unos de otros y que un mal comportamiento de un servidor puede detectarse fácilmente. Esta forma de hacerlo también evita los efectos de onda en canales que están desincronizados cuando se realizan cambios de modo desde difer­ entes partes. 6.3. Colisiones y modos de canales Kalt Información [Pág. 18] RFC 2811 Charla Basada en Internet: Canales Abril 2000 El documento "Charla Basada en Internet: Protocolo de Servidor" [SERVIDOR-IRC] describe la forma de intercambiar la información de los canales entre dos servidores al conectarse entre ellos. Las coli­ siones de canales (ya sean legítimas o no) se tratan como eventos inclusivos, lo que significa que el canal resultante tiene como miem­ bros a todos los usuarios que eran miembros del canal en cada servi­ dor previo a la conexión. De forma similar, cada servidor envía los modos del canal al otro. Por tanto, cada servidor recibe también estos modos de canal. Hay tres tipos de modos de canal: banderas, máscaras y datos. Los dos primeros tipos son sencillos de manejar ya que están o bien activados o desactivados. Si un modo está activado en un servidor, DEBE acti­ varse en el otro servidor como resultado de la conexión. Dado que los tópicos no se envían como parte del intercambio, no rep­ resentan ningún problema. Sin embargo, los modos 'l' y 'k' sí se intercambian, y si estaban activados en ambos servidores antes de la conexión, no hay ningún mecanismo que sirva para decidir cual de los dos valores tiene preferencia. Se deja a los usuarios arreglar la posible discrepancia resultante. 6.4. Consumo de recursos El modo basado en máscaras definido en la sección 4.3 hace que los servidores (y la red) de IRC sean vulnerables a un simple abuso del sistema: un único operador de canal puede activar tantas máscaras como sea posible en un canal en particular. Esto puede causar fácil­ mente un desperdicio de memoria del servidor, además de ancho de banda (ya que la información se propaga a los demás servidores). Por esta razón, se RECOMIENDA que se ponga un límite al número de estas máscaras por canal como se menciona en la sección 4.3. Además, PUEDEN usarse mecanismos más complejos para evitar tener máscaras redundantes activas para un mismo canal. Kalt Información [Pág. 19] RFC 2811 Charla Basada en Internet: Canales Abril 2000 7. Consideraciones sobre seguridad 7.1. Control de acceso Una de las formas de controlar el acceso a un canal es usar máscaras basadas en el nombre de usuario y el nombre de host de las conexiones de los usuarios. Este mecanismo sólo es eficiente y seguro si los servidores de IRC tienen una forma precisa de autenticar las conex­ iones de los usuarios, y si los usuarios no pueden saltársela fácil­ mente. Aunque en teoría es posible implementar un sistema muy estricto de autenticación, la mayoría de las redes de IRC (especial­ mente las redes públicas) no disponen de él y dan pocas garantías de la veracidad del nombre de usuario y de host de una conexión de cliente en particular. Otra forma de controlar el acceso es el uso de una clave de canal, pero dado que se envía en forma de texto plano, es vulnerable a ataques por parte de terceros. 7.2. Privacidad de los canales Dado que las colisiones de canales se tratan como eventos inclusivos (ver sección 6.3), los usuarios pueden entrar a un canal superando los controles de acceso. Este método se ha usado desde hace tiempo para "tomar" canales obteniendo de forma "ilegítima" el estatus de operador de canal. El mismo método puede usarse para obtener la lista exacta de los miembros de un canal, además de recibir de vez en cuando algunos de los mensajes enviados al canal. 7.3. Anonimato El modo de canal anónimo (ver sección 4.2.1) se puede usar para ocul­ tar a los usuarios en ese canal "anónimo" presentando todos los men­ sajes al canal como si viniesen desde un pseudo usuario cuyo apodo es "anónimo". Esto se hace a nivel de cliente-servidor, y no se propor­ ciona ningún anonimato en el nivel de servidor-servidor. Kalt Información [Pág. 20] RFC 2811 Charla Basada en Internet: Canales Abril 2000 Debería ser obvio para el lector que el nivel de anonimato que se ofrece es bastante pobre e inseguro, y que los clientes DEBERÍAN mostrar avisos visibles a los usuarios que entren a estos canales. 8. Soporte y disponibilidad actual Listas de correo para discusiones sobre IRC: Discusión general: ircd-users@irc.org Desarrollo del protocolo: ircd-dev@irc.org Implementaciones del software: ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc Grupo de noticias: alt.irc 9. Reconocimientos Partes de este documento se han copiado del RFC 1459 [IRC] que docu­ mentó formalmente por primera vez el protocolo IRC. También se ha visto beneficiada por varias rondas de revisiones y comentarios. En particular, las siguientes personas han hecho contribuciones signi­ ficativas a este documento: Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl. 10. Referencias [PALABRAS CLAVE] Bradner, S., "Key words for use in RFCs to Indi­ cate Requirement Levels", BCP 14, RFC 2119, March 1997. [IRC] Oikarinen, J. and D. Reed (Trad. Carlos García Kalt Información [Pág. 21] RFC 2811 Charla Basada en Internet: Canales Abril 2000 Argos), "Protocolo de Charla Basado en Internet", RFC 1459, May 1993. [ARQUITECTURA-IRC] Kalt, C., "Charla Basada en Internet: Arquitec­ tura", RFC 2812, Abril de 2000 [CLIENTE-IRC] Kalt, C., "Charla Basada en Internet:Protocolo del Cliente", RFC 2812, Abril de 2000. [SERVIDOR-IRC] Kalt, C., "Charla Basada en Internet: Protocolo de Servidor", RFC 2813, Abril de 2000. [CANALES-IRC] Kalt, C., "Charla Basada en Internet: Manten­ imiento de canales", RFC 2811, Abril de 2000. 11. Dirección del autor Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 Estados Unidos Correo Electrónico: kalt@stealth.net 12. Dirección del traductor Carlos García Argos C/Antonio Trueba, 14 4-8-2 29017 Málaga España Correo Electrónico: cgasoft@yahoo.com Kalt Información [Pág. 22]