Network Working Group D. Wessels Petición de Comentarios: 2187 K. Claffy Categoría: Informativo National Laboratory for Applied Network Research/UCSD Septiembre 1997 Aplicación del Protocolo de Caché de Internet (ICP), versión 2 Estado de este memorándum Este documento proporciona información para la comunidad Internet. No es la especificación de ningún estándar de Internet. La distribución de este memorándum no está limitada. Nota de Copyright Copyright (C) The Internet Society (1997). Todos los derechos reservados. Resumen Este documento describe la aplicación de ICPv2 (Internet Cache Protocol version 2, RFC2186) a las cachés web. ICPv2 es un protocolo con un formato de mensaje pequeño utilizado para la comunicación entre cachés web. Actualmente hay implementaciones de cachés independientes que implementan ICP[3,5], haciendo importante codificar la existencia de usos prácticos de ICP para aquellos que intentan implementar, desarrollar y extender su uso. Las peticiones y respuestas ICP se refieren a la existencia de URLs (u objetos) en cachés vecinas. Las cachés intercambian mensajes ICP y utilizan la información recopilada para seleccionar la localización más adecuada desde la cual retirar un objeto. El documento asociado (RFC2186) describe el formato y sintaxis del protocolo. En este documento nos centramos en aspectos del desarrollo ICP, eficiencia, seguridad, e interacción con otros aspectos del comportamiento del tráfico web. Wessels & Claffy Informativo [Pág. 1] RFC 2187 ICP Septiembre 1997 Indice 1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Jerarquías de cachés web . . . . . . . . . . . . . . . . . . . 4 3. ¿Cuál es el valor añadido de ICP? . . . . . . . . . . . . . . 6 4. Ejemplo de configuración de una jerarquía ICP . . . . . . . . 7 4.1 Configurando la caché de `proxy.cliente.org' . . . . . . . . . 7 4.2 Configurando la caché `cache.isp.com' . . . . . . . . . . . . 8 5. Aplicando el protocolo . . . . . . . . . . . . . . . . . . . . 9 5.1 Enviando peticiones ICP . . . . . . . . . . . . . . . . . . . 9 5.2 Recibiendo peticiones ICP y enviando respuestas . . . . . . . 11 5.3 Recibiendo respuestas ICP . . . . . . . . . . . . . . . . . . 12 5.4 Opciones ICP . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Lecciones aprendidas . . . . . . . . . . . . . . . . . . . . . 19 8.1 Diferencias entre ICP y HTTP . . . . . . . . . . . . . . . . . 19 8.2 Padres, hermanos, aciertos y fallos . . . . . . . . . . . . . 19 8.3 Distintos roles de ICP . . . . . . . . . . . . . . . . . . . . 19 8.4 Fallos de diseño de protocolo de ICPv2 . . . . . . . . . . . . 20 9. Consideraciones de seguridad . . . . . . . . . . . . . . . . . 22 9.1 Inserción de preguntas ICP falsas . . . . . . . . . . . . . . 22 9.2 Inserción de respuestas ICP falsas . . . . . . . . . . . . . . 22 9.3 Escucha disimulada . . . . . . . . . . . . . . . . . . . . . . 23 9.4 Bloqueando mensajes ICP . . . . . . . . . . . . . . . . . . . 23 9.5 Retrasando mensajes ICP . . . . . . . . . . . . . . . . . . . 23 9.6 Denegación del servicio . . . . . . . . . . . . . . . . . . . 24 9.7 Alterando campos ICP . . . . . . . . . . . . . . . . . . . . . 24 9.8 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . 28 12. Direcciones de los autores . . . . . . . . . . . . . . . . . . 29 Declaración completa de Copyright . . . . . . . . . . . . . . 30 Wessels & Claffy Informativo [Pág. 2] RFC 2187 ICP Septiembre 1997 1. Introducción ICP es un formato de mensajes de pequeño tamaño utilizado para la comunicación entre cachés web. ICP se utiliza para intercambiar pistas sobre la existencia de URLs en cachés vecinas. Las cachés intercambian mensajes ICP y utilizan la información recopilada para seleccionar la localización más adecuada desde la cual retirar un objeto. Este documento describe la implementación software de ICP. Para una descripción del protocolo y del formato de mensaje, por favor ver el documento asociado (RFC2186). Se intentará evitar realizar juicios sobre cuando o cómo debería utilizarse ICP en configuraciones particulares de cachés web. ICP podría ser positivo en algunas situaciones y en otras positivo. Reconocemos que ciertas prácticas descritas en este documento no son del todo óptimas. Algunas de ellas existen por razones históricas. Algunos aspectos se irán mejorado en versiones posteriores. Partiendo de que este documento sólo sirve para describir las prácticas actuales, nosotros nos centramos en documentar más que en evaluar. De todas formas, se apuntan los problemas de seguridad conocidos y otros defectos. El resto del documento está escrito de la siguiente manera. Primero se describen las jerarquías de las cachés web, explicando los motivos de usar ICP, y demostrando cómo configurar su uso en las jerarquías. Después se proporciona una descripción paso a paso de una transacción petición-respuesta ICP. Más adelante se analiza la interacción de ICP con los cortafuegos, y se toca brevemente multicast con ICP. Se finaliza con lecciones que se han aprendido hasta ahora durante el desarrollo y despliegue, y otras consideraciones de seguridad. ICP fue inicialmente desarrollado por Peter Danzig, et. al. en la Universidad de California del Sur como parte central de la jerarquía de cachés en el Harvest research project[3]. Wessels & Claffy Informativo [Pág. 3] RFC 2187 ICP Septiembre 1997 2. Jerarquías de cachés web Una sola caché web reduce el tráfico generado por los clientes que están detrás de ella. De modo similar, un grupo de cachés web se pueden beneficiar compartiendo otra caché de forma parecida. Investigadores del proyecto Harvest previeron que podría ser importante conectar las cachés web de forma jerárquica. En una jerarquía de cachés (o una malla) una caché establece relaciones entre pares de cachés vecinas. Hay dos tipos de relaciones: padres y hermanos. Una caché padre es esencialmente un nivel más en la jerarquía de cachés. Una caché hermana está al mismo nivel. Los términos vecino y par se utilizan para referirse a tanto padres como a hermanos, los cuales están sólo a un 'salto de caché' de distancia. La figura 1 muestra una configuración jerárquica simple. Pero ¿qué significa estar en el mismo nivel o en un nivel superior? El flujo general de documentos pedidos recorre hacia arriba la jerarquía. Cuando una caché no tiene un objeto pedido, debe preguntar vía ICP cuál de sus cachés vecinas tiene el objeto. Si alguna de sus vecinas tiene el objeto pedido ( un acierto en el vecino), la caché lo retirará desde él. Si ninguno de los vecinos tiene el objeto (un fallo en el vecino), entonces la caché debe remitir la petición o al padre o directamente al servidor original. La diferencia esencial entre un padre y un hermano es que un acierto en un vecino puede venir de cualquiera, pero un fallo resuelto en el vecino no puede venir desde un hermano. En otras palabras, en una relación entre hermanos, una caché sólo puede preguntar para retirar objetos que el hermano ya tiene en su caché, mientras que la misma caché puede preguntar a un padre para retirar cualquier objeto independientemente de si lo tiene o no en su caché. Un rol del padre es I N T E R N E T =========================== | || | || | || | || | +----------------------+ | | | | | CACHE | | | PADRE | | | | | +----------------------+ | || RECUPERACIONES || DIRECTAS || | || Wessels & Claffy Informativo [Pág. 4] RFC 2187 ICP Septiembre 1997 | ACIERTOS | Y | FALLOS | RESUELTOS | || | || | || V \/ +------------------+ +------------------+ | | | | | LOCAL |/------ACIERTOS-----| CACHE | | CACHE |\-----RESUELTOS-----| HERMANA | | | | | +------------------+ +------------------+ | | | | | | | | | | | | | | | V V V V V =================== CACHE CLIENTE FIGURA 1: una jerarquía simple de cachés web. La caché local puede retirar aciertos desde cachés hermanas, aciertos y fallos desde las cachés padres, y algunas peticiones directamente desde los servidores de origen. Para proporcionar "tránsito" a la petición si es necesario, las cachés padres están colocadas idealmente dentro o sobre el camino de tránsito a un proveedor de servicios de Internet (ISP). Squid y Harvest permiten complejas configuraciones jerárquicas. Por ejemplo, uno podría especificar que un vecino dado sólo sea utilizado para una cierta clase de peticiones, como URLs desde un dominio DNS específico. Adicionalmente, es posible tratar a un vecino como a un hermano para unas peticiones y como padre para otras. El modelo jerárquico descrito aquí incluye un número de características para prevenir que las cachés del nivel más alto se conviertan en puntos congestionados. Uno es la posibilidad de restringir padres tal y como se describía anteriormente (por dominios). Otra optimización es que la caché sólo remite peticiones que se pueden guardar en la caché a sus vecinos. Una gran cantidad de clases de peticiones web no se pueden guardar en la caché: peticiones que requieren ciertos tipos de autenticación, datos de sesiones encriptadas, respuestas altamente personalizadas, y ciertos tipos de peticiones de bases de datos. Las cachés de bajo nivel deberían encargarse de esas solicitudes mejor que cargarlas al padre. Wessels & Claffy Informativo [Pág. 5] RFC 2187 ICP Septiembre 1997 3. ¿Cuál es el valor añadido de ICP? Aunque es posible mantener jerarquías de caché sin utilizar ICP, la carencia de ICP o algo similar prohíbe la existencia de relaciones meta-comunicativas entre hermanos, p.e., mecanismos para solicitar a cachés cercanas un documento dado. Una preocupación en el uso de ICP es el retardo que añade un intercambio petición/respuesta a una transacción HTTP. Sin embargo, si la petición ICP puede localizar el objeto en un vecino cercano, entonces el retardo ICP puede ser más que la compensación por la rápida entrega del dato desde el vecino. Con el propósito de minimizar los retardos ICP, las cachés (así como el protocolo en sí mismo) está diseñadas para devolver peticiones ICP rápidamente. De hecho, la aplicación tiene una cantidad de proceso mínima debido a la petición, la mayor parte del retardo ICP es debido a la transmisión por la red. ICP también sirves para obtener la accesibilidad del vecino. Si la respuesta ICP desde un vecino no llega, entonces ese camino de red está congestionado o caído, o la aplicación de caché no está funcionando en la máquina vecina. En ese caso, la caché no debería usar ese vecino en ese momento. Adicionalmente, debido a que una caché libre pueda devolver las respuestas más rápido que otra que esté muy ocupada, si todos los otros factores siguen igual, ICP proporciona alguna forma de balanceo de carga. Wessels & Claffy Informativo [Pág. 6] RFC 2187 ICP Septiembre 1997 4. Ejemplo de configuración de una jerarquía ICP Configurar cachés mediante una jerarquía requiere establecer relaciones entre pares, los cuales implican configuración manual en los dos sistemas finales. Una caché debe indicar que otra es un padre o un hermano. La otra caché muy probablemente tendrá que añadir la primera caché a su lista de control de acceso. Más abajo se muestran algunas líneas de configuraciones para una hipotética situación. Se tienen dos cachés, una administrada por un ISP, y otra administrada por un cliente. Primero se describe cómo el cliente podría configurar su caché para conectarse con el ISP. Después, se describe cómo el ISP podría permitir al cliente el acceso a su caché. 4.1 Configurando la caché de `proxy.cliente.org' En Squid, para configurar padres y hermanos en una jerarquía, se introduce una directiva `cache_host' en el archivo de configuración El formato es: cache_host nombre_host tipo puerto-http puerto-icp [opciones] Donde tipo es o bien 'parent'(padre), 'sibling'(hermano) o 'multicast'. Para nuestro ejemplo sería: cache_host cache.isp.com parent 8080 3130 Esta configuración causará que la caché del cliente resuelva la mayoría de los fallos de caché a través del padre (`cgi-bin' y peticiones que no sean GET se resolverían directamente). La utilización del padre podría ser indeseable para ciertos servidores, por ejemplo los servidores que estén también en el dominio cliente.org. Para manejar tales dominios locales directamente, el cliente añadiría esto a su archivo de configuración: local_domain cliente.org Puede también darse el caso de que el cliente quiera utilizar la caché del ISP sólo para un subconjunto de dominios DNS. La necesidad de limitar peticiones de esta forma es realmente más común para los niveles más altos de las jerarquías de cachés, pero no obstante se ilustra aquí. Para limitar la caché del ISP a un subconjunto de dominios DNS, el consumidor utilizaría: cache_host_domain cache.isp.com com net org Entonces, cualquier petición que NO esté en los dominios .com, .net, Wessels & Claffy Informativo [Pág. 7] RFC 2187 ICP Septiembre 1997 o .org se manejará directamente. 4.2 Configurando la caché `cache.isp.com' Para configurar la parte de recepción de peticiones de la relación de cachés pares se utilizan listas de acceso, parecido a las utilizadas entre encaminadores. Las listas de acceso dan soporte a un alto grado de configuración en la relación entre pares. Si no hay líneas de acceso la caché permite la petición por defecto. Observar que la caché cache.isp.com no necesita explícitamente especificar a la caché cliente como un par, ni está codificada el tipo de relación dentro de la petición ICP. Las entradas de control de acceso regulan las relaciones entre esta caché y sus vecinas. Para nuestro ejemplo el ISP usaría: acl src cliente proxy.cliente.org http_access allow Cliente icp_access allow Cliente Esto define una entrada de control de acceso llamada 'cliente' que especifica una dirección IP fuente de la máquina caché cliente. La caché cliente tendría entonces permiso de formular cualquier petición a los puertos HTTP e ICP (incluidos fallos de caché). Esta configuración implica que la caché ISP es padre del cliente. Si el ISP quisiera forzar una relación de hermanos, sería necesario denegar el acceso a fallos de caché. Esto se haría de la siguiente forma: miss_access deny Cliente Por supuesto el ISP podría comunicarle esto al cliente, con el fin de que el cliente cambie su configuración de padre a hermano. Si no, si el cliente pide un objeto que no está en la caché del ISP, se generaría un mensaje de error. Wessels & Claffy Informativo [Pág. 8] RFC 2187 ICP Septiembre 1997 5. Aplicando el protocolo Las siguientes secciones describen la implementación de ICP en la versión Harvest[3] (versión de investigación) y en los paquetes de la caché web de Squid [5]. En términos de números de versión, esto significa la versión 1.4pl2 de Harvest y la versión 1.1.10 de Squid. La secuencia básica de eventos en una transacción ICP es como sigue: 1. La caché local recibe una petición HTTP[1] desde la caché cliente. 2. La caché local envía solicitudes ICP (sección 5.1). 3. Las caché(s) pares recibe(n) las solicitudes y envían respuestas ICP (sección 5.2). 4. La caché local recibe las respuestas ICP y decide a dónde remitir la petición (sección 5.3). 5.1 Enviando peticiones ICP 5.1.1 Determinar cuándo usar ICP No todas las peticiones HTTP requieren que se envíen peticione ICP. Obviamente, los aciertos de caché no necesitarán ICP porque la petición se satisface inmediatamente. Para los servidores del origen cercanos a la caché, no necesitaremos utilizar ninguna caché vecina. En Squid y en Harvest, el administrador especifica lo que constituye un servidor 'local' con las opciones de configuración 'local_domain' y `local_ip'. La caché siempre contacta con un servidor local directamente, nunca pregunta a una caché par. Hay otras clases de peticiones que la caché, (o el administrador del servidor) preferiría remitir directamente al servidor del origen. En Squid y Harvest, tal clase incluye todas las peticiones de métodos no GET. Una caché puede también estar configurada para no usar pares para URLs que estén en la `hierarchy_stoplist'. Con el fin de que una petición HTTP produzca una transacción ICP, debe: o no ser un acierto de caché o no estar dirigida a un servidor local o ser una petición GET o no estar en la configuración de la `hierarchy_stoplist'. Esto se llama petición jerárquica. Una petición no jerárquica es Wessels & Claffy Informativo [Pág. 9] RFC 2187 ICP Septiembre 1997 aquella que no necesita generar ningún tráfico ICP. Para evitar procesar peticiones que probablemente bajen el rendimiento de la caché, uno puede configurar la caché para no consultar la jerarquía de URLs que contengan ciertas cadenas, (e.g. 'cgi_bin'). 5.1.2 Determinar a qué pares preguntar Por defecto, una caché envía un mensaje ICP_OP_QUERY a cada par, a menos que algo de lo siguiente se cumpla: o restricciones que evitan preguntar a un par a esta petición, basadas en la directiva de configuración `cache_host_domain', que especifica un conjunto de dominios DNS (a partir de las URLs) para los cuales el par debe o no debe ser preguntado. En Squid una directiva más flexible ('cache_host_acl') soporta restricciones en otras partes de la petición (método, número de puerto, fuente, etc.) o El par es un hermano, y la petición HTTP incluye una cabecera "Pragma: no-cache". Esto es porque invitarían al hermano a transitar la petición, que no está permitido. o El par está configurado para que no le envíen nunca peticiones ICP (p.e. con la opción `no-query'). Si sólo se rinde a un par ICP, y la directiva de configuración de Squid `single_parent_bypass' está activada, entonces se puede saltar el esperar a una sola respuesta ICP y enviar la petición HTTP directamente a la caché. La opción de configuración de Squid `source_ping', configura una caché Squid para enviar un ping a la fuente original simultáneamente a sus peticiones ICP, en el caso de que el origen esté más cerca que cualquiera de las cachés. 5.1.3 Cálculo del número esperado de respuestas ICP Harvest y Squid pretenden maximizar la probabilidad de obtener una respuesta de acierto desde algún par. Por lo tanto, la caché espera que todas las respuestas ICP sean recibidas. Normalmente, se espera recibir una respuesta ICP por cada solicitud enviada, excepto: o cuando se cree que el par está 'caído'. Si el par está caído Squid y Harvest continúan enviando sus peticiones ICP, pero no esperan que el par responda. Cuando una respuesta ICP se recibe de nuevo desde ese par, su estado será cambiado a 'ok'. La determinación del estado caído/estado ok varía un poco en los desarrollos de Harvest y Squid. Ambos marcan como caído a un par Wessels & Claffy Informativo [Pág. 10] RFC 2187 ICP Septiembre 1997 cuando no responde a 20 peticiones ICP consecutivas. Squid también marca como 'caído' a un par cuando una conexión TCP falla, y como 'ok' cuando una conexión de diagnóstico TCP tiene éxito. o Enviando a una dirección multicast. En este caso probablemente esperaremos recibir más de una respuesta, y no tener forma de determinar definitivamente cuánto tiempo esperar. Se analizan los aspecto multicast más abajo en la sección 7. 5.1.4 Instalar eventos de tiempo de espera Debido a que ICP utiliza UDP como capa de transporte, las peticiones ICP y sus respuestas pueden a veces ser eliminadas por la red. La caché instala un sistema de eventos de tiempo de espera en el caso de que no todas las peticiones lleguen. Por defecto Squid y Harvest utilizan un tiempo de espera de 2 segundos. Si la retirada del objeto no ha comenzado cuando termina el tiempo de espera, la fuente seleccionada como se describe debajo en la sección 5.3.9. 5.2 Recibiendo peticiones ICP y enviando respuestas Cuando se recibe un mensaje ICP_OP_QUERY, la caché lo examina y decide qué mensaje de respuesta debe ser enviado. Se enviarán uno de los siguientes opcodes de respuesta: probados para su uso en el orden listado: 5.2.1 ICP_OP_ERR La URL se extrae de la Carga útil y se analiza. Si el análisis falla, se devuelve un mensaje de ICP_OP_ERR. 5.2.2 ICP_OP_DENIED Se comprueban los controles de acceso. Si el par no tiene permiso para realizar esta petición, se devuelve ICP_OP_DENIED. Squid cuenta el número de mensajes ICP_OP_DENIED enviados a cada par. Si hay más del 90% denegadas de más de 100 respuestas, entonces no se le manda ninguna respuesta más. Esto previene de cachés desconfiguradas que envían mensajes ICP innecesarios hacia delante y hacia atrás. 5.2.3 ICP_OP_HIT Si la caché alcanza este punto sin haber encajado con ninguno de los anteriores opcodes, significa que la petición está permitida y debemos determinar si es un fallo o un acierto, por lo que veremos si la URL existe en la caché local. Si existe, y la entrada de la caché es reciente, por lo menos durante los siguientes 30 segundos, podemos Wessels & Claffy Informativo [Pág. 11] RFC 2187 ICP Septiembre 1997 devolver un mensaje ICP_OP_HIT. La determinación de reciente utiliza las normas de refresco locales (o TTL). Observar que existe una condición de carrera para respuestas ICP_OP_HIT a pares de hermanos. El ICP_OP_HIT significa que la subsecuente petición HTTP para la URL llamada tiene como resultado un acierto. Se asume que la petición HTTP viene rápidamente después del ICP_OP_HIT. Sin embargo, existe una pequeña posibilidad de que el objeto sea eliminado de la caché antes de que se reciba la petición HTTP. Si esto ocurre, y el par que contesta tiene configurado el `miss_access' de Squid entonces el usuario recibirá muy confuso un mensaje de acceso denegado. 5.2.3.1 ICP_OP_HIT_OBJ Antes de devolver un mensaje ICP_OP_HIT, se verá si se puede enviar un mensaje ICP_OP_HIT_OBJ. Podemos usar ICP_OP_HIT_OBJ si: o El mensaje ICP_OP_QUERY tiene activado el flag ICP_FLAG_HIT_OBJ. o El objeto entero (más la URL) cabe en el mensaje ICP. El tamaño máximo del mensaje ICP es de 16 Kbytes, pero una aplicación podría escoger seleccionar un máximo menor para las respuestas ICP_OP_HIT_OBJ. Normalmente las respuestas ICP se envían inmediatamente después de recibir la petición, pero el mensaje ICP_OP_HIT_OBJ no puede ser enviado hasta que los datos del objeto estén listos para ser copiados dentro del mensaje de respuesta. Para Squid y Harvest esto significa que el objeto debe ser 'traído' desde el disco si no está todavía en memoria. Por lo tanto, en media, una respuesta ICP_OP_HIT_OBJ tendrá una latencia mayor que un ICP_OP_HIT. 5.2.4 ICP_OP_MISS_NOFETCH En este punto tenemos un fallo de caché. ICP tiene dos tipos de respuestas ante fallos. Si la caché no quiere que el otro no retire el objeto desde ella, envía un mensaje ICP_OP_MISS_NOFETCH. 5.2.5 ICP_OP_MISS Finalmente, una respuesta ICP_OP_MISS se devuelve por defecto. Si la caché que responde es el padre de la caché que hace la petición, el ICP_OP_MISS indica una invitación a buscar la URL a través de la caché que responde. 5.3 Recibiendo respuestas ICP Algunas respuestas ICP serán ignoradas; específicamente, cuando alguna de las condiciones siguientes se cumpla: Wessels & Claffy Informativo [Pág. 12] RFC 2187 ICP Septiembre 1997 o el mensaje de respuesta se originó desde un par desconocido. o el objeto llamado por la URL no existe. o el objeto está siendo buscado todavía. 5.3.1 ICP_OP_DENIED Si más del 95% de más de 100 respuestas desde una caché has sido ICP_OP_DENIED, entonces tal tasa de denegaciones indica probablemente un error de configuración, tanto e localmente como en el otro par. Por esta razón, no se enviarán más peticiones al par mientras dure el proceso de caché. 5.3.2 ICP_OP_HIT La retirada del objeto comienza comienza inmediatamente desde el par que contesta. 5.3.3 ICP_OP_HIT_OBJ Los datos del objeto se extraen desde el mensaje ICP y la retirada se completa. Si hay algún problema con el mensaje ICP_OP_HIT_OBJ (e.g. faltan los datos) la respuesta será tratada como un ICP_OP_HIT. 5.3.4 ICP_OP_SECHO La retirada del objeto comienza inmediatamente desde el servidor de origen porque la respuesta ICP_OP_SECHO llega antes que cualquier ICP_OP_HIT. Si un ICP_OP_HIT llegase antes, este ICP_OP_SECHO debe ser ignorado por que la retirada ya ha comenzado. 5.3.5 ICP_OP_DECHO Una respuesta ICP_OP_DECHO se maneja como un ICP_OP_MISS. Los pares No ICP deben siempre estar configurados como padres; un hermano no- ICP no tiene sentido. un problema serio con ICP_OP_DECHO es que como envía sus mensajes por el puerto de eco UDP, no indica que la caché funciona realmente -- sólo indica que existe conectividad a nivel de red entre esos pares. 5.3.6 ICP_OP_MISS Si el par es un hermano, la respuesta ICP_OP_MISS se ignora. Si no, el par podría ser "recordado" para uso futuro en caso de que no se reciban respuestas después (sección 5.3.9). Wessels & Claffy Informativo [Pág. 13] RFC 2187 ICP Septiembre 1997 Harvest y Squid recuerdan el primer padre en devolver un mensaje ICP_OP_MISS. Con Squid, los padres pueden estar cargados por tanto el "primer padre al fallar" puede no ser realmente el de la primera respuesta recibida. Esto se denomina FIRST_PARENT_MISS. Recordar que los fallos de hermanos se ignoran, sólo se tienen en cuenta fallos de padres. Las RTT de los fallos de padres pueden estar sobrecargadas porque a veces el padre más cercano no es el que la gente quiere usar. Además, recientes versiones de Squid pueden recordar el padre con el menor RTT al servidor original, utilizando la opción ICP_FLAG_SRC_RTT. Esto se denomina CLOSEST_PARENT_MISS. 5.3.7 ICP_OP_MISS_NOFETCH Esta respuesta es esencialmente ignorada. Una caché no debe reenviar una petición a un par que devuelve ICP_OP_MISS_NOFETCH. 5.3.8 ICP_OP_ERR Se ignora sin más. 5.3.9 Cuando todos los pares fallan. Para ICP_OP_HIT y ICP_OP_SECHO la petición se remite inmediatamente. Para ICP_OP_HIT_OBJ no hay necesidad de remitir la petición. Para el resto de los opcodes de respuesta, se espera hasta que el número esperado de respuestas se hayan recibido. Cuando tengamos todas las respuestas esperadas, o cuando termine el tiempo de espera de la petición, será el momento de remitir la petición. Partiendo de que las respuestas de fallo hayan sido recibidas de todos los pares, se debe seleccionar una caché padre o el servidor original o Si los pares están usando el flag ICP_FLAG_SRC_RTT, se remite la petición al par con el menor RTT hasta el servidor del origen Si la caché local también está midiendo RTTs a los servidores del origen, y está más cerca que cualquiera de los padres, la petición se transmite directamente al servidor del origen. o Si hay un padre FIRST_PARENT_MISS disponible, la petición será transmitida allí. o Si el intercambio petición/respuesta ICP no produce ningún padre apropiado, la petición se enviará directamente al servidor del origen (a no ser las restricciones de un cortafuegos no lo permitan). Wessels & Claffy Informativo [Pág. 14] RFC 2187 ICP Septiembre 1997 5.4 Opciones ICP Las siguientes opciones se añadieron a Squid para dar soporte a algunas características nuevas manteniendo compatibilidad hacia atrás con la implementación de Harvest. 5.4.1 ICP_FLAG_HIT_OBJ Este flag está desactivado por defecto y será activado en un mensaje ICP_OP_QUERY sólo si se cumplen estos tres criterios: o Está habilitado en el archivo de configuración de la caché con `udp_hit_obj on'. o El sistema debe estar usando ICP versión 2. o La petición HTTP no debe incluir la cabecera "Pragma: no-cache". 5.4.2 ICP_FLAG_SRC_RTT Este flag está desactivado por defecto y será activado en un mensaje ICP_OP_QUERY sólo si estas tres condiciones se cumplen: o Está habilitado en el archivo de configuración de la caché con `query_icmp on'. o El sistema debe estar usando la versión 2 de ICP. Wessels & Claffy Informativo [Pág. 15] RFC 2187 ICP Septiembre 1997 6. Cortafuegos Trabajar con una caché web detrás de un cortafuegos o en una red privada plantea algunos problemas interesantes. La parte dura es calcular si la caché puede conectar con el servidor del origen de fuera. Harvest y Squid proporcionan una directiva de configuración `inside_firewall' para listar dominios DNS en la parte de dentro del cortafuegos. Todo lo demás se asume que está al otro lado del cortafuegos. Squid tiene también una directiva `firewall_ip' para poder especificar hosts interiores por sus direcciones IP. En una configuración sencilla, una caché Squid detrás de un cortafuegos tendrá sólo una caché padre (la cual estará en el cortafuegos). En este caso, Squid debe utilizar ese padre para todos los servidores más allá del cortafuegos por lo que no hay necesidad de utilizar ICP. En una configuración más compleja, puede haber un número de cachés también detrás del cortafuegos. Aquí, ICP puede ser utilizado para comprobar aciertos de caché en esos pares. Ocasionalmente, cuando ICP se está utilizando, puede no haber ninguna respuesta recibida. Si la caché no estuviera detrás del cortafuegos, la petición sería remitida directamente al servidor original. Pero en esta situación, la caché debe escoger una caché padre, bien aleatoriamente, o bien debido a la información de configuración. Por ejemplo, Squid permite a un padre ser designado por defecto cuando no hay otros disponibles. Wessels & Claffy Informativo [Pág. 16] RFC 2187 ICP Septiembre 1997 7. Multicast Para una eficiente distribución, una caché puede entregar solicitudes ICP a una dirección multicast, y las cachés vecinas pueden unirse al grupo multicast para recibir esas solicitudes. La práctica actual es que la caché envían respuestas ICP sólo a direcciones unicast, por muchas razones: o realizar multicast con las respuestas ICP no reduce el número de paquetes enviados. o previene a otros grupos de recibir respuestas inesperadas. o la respuesta debería seguir caminos de ruteo unicast para indicar (unicast) conectividad entre el receptor y el emisor puesto que la petición subsecuente del HTTP será ruteada como unicast. La confianza es un aspecto importante de las relaciones entre cachés. Una caché web no debe confiar automáticamente en cualquier caché que responda a una petición ICP. Las cachés deben ignorar mensajes ICP desde direcciones no específicamente configuradas como vecinas. Si no, uno podría fácilmente producir un desorden haciendo funcionar una caché ilegítima, uniéndola a un grupo, devolver ICP_OP_HIT para todas las peticiones, y luego entregar el contenido falso. Cuando se esté enviando a grupos multicast, los administradores de caché deben tener cuidado de usar el mínimo TTL multicast requerido para alcanzar a todos los miembros del grupo. Unirse a un grupo multicast no requiere privilegios especiales y no hay forma de prevenir que cualquiera se una a tu grupo. Dos grupos de cachés utilizando la misma dirección multicast podría solaparse, lo que causaría que una caché reciba respuestas ICP desde vecinos desconocidos. Los vecinos desconocidos no podrían recuperar los datos del objeto, pero la caché recibiría constantemente las contestaciones del ICP a las que nunca debe hacer caso. Para prevenir un solapamiento en la malla de cachés, éstas deberían limitar el alcance de sus solicitudes ICP con los apropiados TTLs; una aplicación como mtrace[6] puede determinar los apropiados TTLs de multicast. Como se menciona en la sección 5.1.3, se necesita estimar el número de respuestas esperado para un mensaje ICP_OP_QUERY. Para unicast se espera una respuesta por cada petición si el par está funcionando. Sin embargo, para multicast se espera generalmente más de una respuesta, pero sin forma de saber exactamente cuántas puede haber. Squid periódicamente (cada 15 minutos) envía mensajes de test Wessels & Claffy Informativo [Pág. 17] RFC 2187 ICP Septiembre 1997 ICP_OP_QUERY sólo a los miembros de los grupos multicast. Como en una petición ICP real, se instala un evento de tiempo de espera y las respuestas se cuentan hasta que el éste expira. Se ha visto que las cuentas de recibidos varían considerablemente. Por lo tanto, el número de respuestas a esperar se calcula como una media [moving: variante, móvil], redondeada a la baja al entero más cercano. Wessels & Claffy Informativo [Pág. 18] RFC 2187 ICP Septiembre 1997 8. Lecciones aprendidas 8.1 Diferencias entre ICP y HTTP ICP es claramente diferente a HTTP. HTTP soporta un rico y sofisticado conjunto de características. En contraste, ICP fue diseñado para ser simple, pequeño y eficiente. Las cabeceras de petición y respuesta HTTP consisten en líneas de texto ASCII delimitadas por un par de CRLF, mientras que ICP utiliza una longitud fija de cabecera y representa sus números en binario. Lo único que tienen en común ICP y HTTP es la URL. Observar que el mensaje ICP no incluye el método HTTP. La implementación original asume que sólo interesa guardar en caché peticiones GET y no hay necesidad de localizar peticiones que no sean GET en cachés vecinas. Así, la versión actual de ICP no soporta peticiones que no sean GET, aunque las siguiente versión de este protocolo probablemente incluya un campo para el método de petición. HTTP define características que son importantes para las cachés pero no expresamente con el protocolo ICP. Como ésas están pragma: no- cache, If-Modified-Since, y todos las características del control de caché de HTTP/1.1. Un mensaje ICP_OP_HIT_OBJ pude entregar un objeto que quizá no obedezca todas los requerimientos de las cabeceras de la petición. Esas diferencias entre ICP y HTTP son las razones por las cuales desaconsejamos el uso de ICP_OP_HIT_OBJ. 8.2 Padres, hermanos, aciertos y fallos Observar que el mensaje ICP no tiene un campo para indicar el intento de la caché solicitante. Esto es, en ninguna parte de la petición o contestación ICP se dice que las dos cachés tienen una relación de hermanos o de padres. Una caché hermana puede sólo responder con un acierto o con un fallo, no con "tú puedes recuperar esto desde aquí" o "tú no puedes retirar esto de aquí." La caché solicitante debe aplicar el acierto o el fallo a su configuración local para prevenirse de resolver fallos a través de una caché hermana. Esta método es torpe, porque debido a que este aspecto de la relación puede ser configurado sólo en la caché que origina las peticiones, e indirectamente vía los controles de acceso como se describió anteriormente en la sección 4.2. 8.3 Distintos roles de ICP Hay dos formas de entender cuál es el papel de ICP en una malla de cachés. Una es forma es considerar que el papel de ICP es sólo de localización de objetos, específicamente, proporcionar pistas sobre existe o no un objeto en una caché vecina. Se asume implícitamente Wessels & Claffy Informativo [Pág. 19] RFC 2187 ICP Septiembre 1997 que los aciertos en la caché son altamente deseables, e ICP se utiliza para maximizar la probabilidad de obtenerlo. Si un mensaje ICP se pierde debido a congestión, no se pierde nada importante; la petición será satisfecha de todas formas. ICP está llamado a llevar un papel más complejo: transporte de políticas de uso de caché. Por ejemplo, muchas organizaciones (e.g.universidades) instalarán una caché web en el final de sus redes. A tales organizaciones les gustaría establecer relaciones con otras cachés cercanas, sujetas a los siguientes términos: o cualquier cliente o usuario de la organización puede pedir cualquier objeto (de la caché o no). o cualquiera puede pedir un objeto que esté en la caché. o cualquiera puede pedir cualquier objeto desde los servidores de la organización detrás de la caché. o todas las otras peticiones serán denegadas; específicamente, la organización no dejará pasar peticiones las cuales o bien el cliente o el servidor no estén dentro de su dominio. Para Transportar con éxito las políticas el intercambio ICP debe predecir con precisión el resultado (acierto, fallo) de la petición HTTP. El resultado puede depender a menudo de otros campos pedidos, como control de caché. De esta forma no es posible para ICP predecir con precisión el resultado sin más, o quizá todas, las de la petición HTTP. 8.4 Fallos de diseño de protocolo de ICPv2 Se reconocen ciertos defectos con el diseño original del ICP, y hacemos notar que las futuras versiones pueden evitar los mismo errores. o La URL terminada con NULL en el campo de carga útil requiere ir octeto por octeto a través del mensaje para encontrar alguno de de los campos (p.e. el comienzo de los datos de un objeto en un mensaje ICP_OP_HIT_OBJ). o Dos campos (Dirección del host emisor y dirección del host solicitante) son específicas de IPv4. Sin embargo, ninguno de esos campos se utilizan en la práctica; normalmente están llenas de ceros. Si las direcciones IP tienen un papel en el mensaje ICP, tiene que ser un descriptor de la familia de direcciones para cada dirección, y los clientes necesitan ser capaces de decir cuando quieren escuchar respuestas IPv6 o no. Wessels & Claffy Informativo [Pág. 20] RFC 2187 ICP Septiembre 1997 o Las opciones están limitadas a 32 flags de opciones y 32 bits de datos de opción. Esto debería ser más bien como en TCP, con un descriptor de opción seguido de los datos de opciones. o Aunque actualmente se utiliza como una entrada de caché, la cadena URL no realiza su papel adecuadamente. Algunas respuestas HTTP actualmente varían de acuerdo al 'User-Agent' del solicitante y otras cabeceras. Una entrada de caché debe incorporar todas las cabeceras no de transporte presentes en la petición del cliente. Todas las cabeceras de la petición [no-salto-por-salto: non-hop- by-hop] deben ser enviadas en una petición ICP. o ICPv2 utiliza diferentes valores de opcodes para peticiones y respuestas. ICP debería utilizar el mismo opcode para los dos lados de una transacción entre dos partes, con un indicador "solicitud/respuesta" indicando que lado es cual. o ICPv2 no incluye campos de autenticación de ningún tipo Wessels & Claffy Informativo [Pág. 21] RFC 2187 ICP Septiembre 1997 9. Consideraciones de seguridad La seguridad en una preocupación con ICP sobre UDP debido a su naturaleza no orientada a conexión. Más adelante exponemos varias vulnerabilidades y métodos de ataque, y sus implicaciones. La primera línea de defensa es comprobar la dirección IP de la fuente del mensaje ICP, e.g. como la obtenida por recvfrom(2). Los mensajes de petición ICP deben ser procesados si las reglas de control de acceso permiten que la dirección solicitante acceda a la caché. Sin embargo, los mensajes de respuesta ICP no deben ser aceptados sólo de vecinos conocidos; una caché debe ignorar respuestas de direcciones desconocidas. Debido a que nos creemos la validez de una dirección en un paquete IP, ICP es susceptible a una [spoofing: robo] de la dirección IP. En este documento indicamos varias consecuencias del robo de direcciones IP. Normalmente, direcciones robadas pueden ser detectadas sólo por los encaminadores, no por los hosts. Sin embargo, la cabecera de autenticación IP[7,8] puede ser utilizada por debajo de ICP para proporcionar autenticación criptográfica del paquete IP entero que contiene el protocolo ICP, así eliminamos el riesgo de robo de direcciones IP. 9.1 Inserción de preguntas ICP falsas Procesar un mensaje ICP_OP_QUERY no tiene implicaciones de seguridad conocidas, siempre y cuando a la dirección de la petición se le conceda el acceso a la caché. 9.2 Inserción de respuestas ICP falsas Aquí nos referimos a una tercera parte generando respuestas ICP las cuales se devuelven a las caché solicitante antes de que la respuesta real llegue, o antes de que llegue alguna respuesta. La tercera parte puede insertar respuestas falsas ICP que puede que parezcan venir desde un vecino legítimo. Estas son las tres vulnerabilidades: o Evitar que un cierto vecino de ser utilizado Si una tercera parte pudiera devolver una respuesta ICP_OP_MISS_NOFETCH antes de que llegue la verdadera respuesta, el vecino (falsificado) no sería utilizado. Una tercera parte podría arruinar una caché con mensajes ICP_OP_DENIED hasta que el umbral descrito en la sección 5.3.1 sea alcanzado, causando por tanto que la relación con el vecino estuviese momentáneamente interrumpida. o Forzar a un cierto vecino a ser utilizado Si una tercera parte pudiera devolver una respuesta ICP_OP_HIT antes de que la respuesta real haya llegado, el vecino (falsificado) sería utilizado. Esto podría violar los términos de una relación entre hermanos; las respuestas ICP_OP_HIT significan que la subsiguiente Wessels & Claffy Informativo [Pág. 22] RFC 2187 ICP Septiembre 1997 petición HTTP será también un acierto. De forma parecida, si se pueden generar mensajes ICP_OP_SECHO falsos, la caché retiraría peticiones directamente desde el servidor original. o Envenenamiento de la caché El mensaje ICP_OP_HIT_OBJ es especialmente sensible a problemas de seguridad dado que contiene los datos del objeto actual. En combinación con un robo de una dirección IP, esta opción abre la posibilidad de tener la caché contaminada con objetos inválidos. 9.3 Escucha disimulada Utilizar multicast para solicitudes ICP proporciona un método simple para los demás de fisgonear en mensajes ICP. Si se habilita el multicast, los administradores de la caché deberían configurar la aplicación para utilizar el mínimo TTL requerido, usando un protocolo como mtrace[6]. Observar que el mecanismo de encapsulado de seguridad de la carga útil [7,9] puede ser utilizado para proporcionar protección contra escucha disimulada de mensajes ICP. La escucha disimulada de tráfico ICP puede proporcionar a terceras partes una lista de las URLs que ven los usuarios de la caché. Debido a que la dirección del host solicitante está puesta a cero por Squid y Harvest, las URLs no pueden ser mapeadas hacia hosts individuales. Por defecto, Squid y Harvest no envían mensajes ICP para URLs que contengan `cgi-bin' o `?'. Esas URLs a veces contienen información sensible como argumento. Los administradores de las cachés tienen que estar prevenidos de que alterar la configuración para realizar peticiones ICP para esas URLs puede exponer información sensible a forasteros, especialmente cuando se utiliza multicast. 9.4 Bloqueando mensajes ICP Bloqueo intencionado (o descarado) de peticiones o respuestas ICP parecerá una caída de enlace o congestión en un nodo, y previene el empleo de un vecino ya que se le dirige a producir timeouts (ver sección 5.1.4). Si todos los mensajes son bloqueados, la caché supondrá que el vecino está caído y lo quitará del algoritmo de selección. Sin embargo, si, por ejemplo, cada dos por tres las peticiones se bloquean, el vecino permanecerá 'vivo', pero cada dos por tres las peticiones sufrirán el timeout ICP. 9.5 Retrasando mensajes ICP El algoritmo de selección de vecino normalmente espera a que lleguen Wessels & Claffy Informativo [Pág. 23] RFC 2187 ICP Septiembre 1997 todas las respuestas de fallos ICP. Retrasar peticiones y respuestas, para que lleguen más tarde de lo que normalmente harían, causaría un retraso adicional a la subsiguiente petición HTTP. Por supuesto, si los mensajes se retrasan tanto que llegan después del timeout, el comportamiento es el mismo que el bloqueo comentado arriba. 9.6 Denegación del servicio Un ataque de denegación del servicio, donde el puerto ICP es inundado por una continua llegada de falsos mensajes tiene tres vulnerabilidades: o La aplicación podría anotar cada mensaje falso y eventualmente llenar una partición de disco. o La cola de recepción de sockets puede llenarse, causando que los mensajes legítimos sean tirados. o El host podría gastar muchos ciclos de CPU recibiendo los mensajes falsos. 9.7 Alterando campos ICP Aquí se asume que una tercera parte es capaz de cambiar uno o más campos de los mensajes de respuestas ICP. Opcode El cambio del campo opcode es como insertar los mensajes falsos descritos arriba. Cambiar un acierto por un fallo evitaría que el par fuera utilizado. Cambiar un fallo por un acierto forzaría al par a ser utilizado. Versión Alterar el campo de versión podría tener consecuencias impredecibles si el número de versión es soportado y reconocido. La aplicación receptora debería ignorar mensajes con números de versión inválidos. En el momento de escribir este documento, ambas versiones, la 2 y la 3 están en uso. Esas dos versiones utilizan algunos campos (e.g. Opciones) de una forma ligeramente diferente. Longitud de mensaje Una longitud de mensaje incorrecta debe ser detectada por la aplicación receptora como un mensaje ICP inválido. Wessels & Claffy Informativo [Pág. 24] RFC 2187 ICP Septiembre 1997 Número de petición El número de petición se utiliza a menudo como parte de la entrada de la caché. Harvest no utiliza el número de petición. Squid utiliza el número de petición en conjunto con la URL para crear una entrada de caché. Alterar el número de petición causará que una búsqueda de la caché falle. Esto es parecido en conjunto a bloquear la respuesta ICP . No hay necesidad de que una caché utilice la URL y el número de petición para localizar peticiones HTTP con peticiones ICP excepcionales (de todas formas Squid y Harvest lo hacen). El número de petición debe siempre permanecer igual en la petición y en la respuesta. Sin embargo, si la caché solicitante utiliza sólo el número de petición para localizar peticiones pendientes, Existe alguna posibilidad de que la caché que responde incremente el número de petición de la repuesta para dar la falsa impresión de que las dos cachés están más cerca de lo que realmente están. En otras palabras, asumir que hay nuevas peticiones ICP "en vuelo" en un momento dado, incrementando el número de petición de la respuesta engaña a la caché solicitante para ver un tiempo de ida y vuelta menor de que realmente existe . Opciones Hay un pequeño riesgo en tener los bits del campo de opciones alterado. Cualquier bit de opción debe ser activado en una respuesta si fue activado también en la petición. Cambiar un bit de desactivado a activado es detectable por la caché solicitante, y tal mensaje debe ser ignorado. Cambiar un bit de activo a desactivo está permitido y no tiene efectos negativos. Datos de opciones ICP_FLAG_SRC_RTT es la única opción que utiliza el campo de datos de opciones. Alterar los valores RTT devueltos aquí puede afectar al algoritmo de selección de vecino, tanto forzando o evitando el uso de un vecino. URL El número de petición y la URL son utilizados para generar la entrada de la caché. Alterar la URL causará que falle una búsqueda de la entrada de la caché, y que se ignore la respuesta ICP. Esto es similar en conjunto a bloquear la respuesta ICO. Wessels & Claffy Informativo [Pág. 25] RFC 2187 ICP Septiembre 1997 9.8 Resumen o ICP_OP_HIT_OBJ es particularmente vulnerable a problemas de seguridad debido a que incluye los datos del objeto. Por esto, y otras razones, su uso está desaconsejado. o Falsificar, alterar, insertar, o bloquear mensajes ICP puede causar que una petición falle sólo en dos situaciones: * Si la caché está detrás de un cortafuegos y no puede conectarse directamente al servidor del origen * Si una respuesta ICP_OP_HIT falsa causa que la petición HTTP sea remitida a un hermano, donde la petición es un fallo de caché y el hermano rechaza continuar remitiendo la petición en nombre de la caché que la originó. o Falsificar, alterar, insertar, o bloquear mensajes ICP puede causar fácilmente que las peticiones HTTP sean remitidas (o no remitidas) a ciertos vecinos. Si la caché vecina ha estado también comprometida, entonces ella podría servir contenido falso y contaminar la jerarquía de caché. o Bloquear o retrasar mensajes ICP puede causar que la petición HTTP se retrase más, pero esté al final satisfecha. Wessels & Claffy Informativo [Pág. 26] RFC 2187 ICP Septiembre 1997 10. Referencias [1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, January 1997. [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. [3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and Wessels D., "The Harvest Information Discovery and Access System", Internet Research Task Force - Resource Discovery, http://harvest.transarc.com/. [4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National Laboratory for Applied Network Research, http://www.nlanr.net/ ~wessels/Papers/icp-squid.ps.gz. [5] Wessels D., "The Squid Internet Object Cache", National Laboratory for Applied Network Research, http://squid.nlanr.net/ Squid/ [6] mtrace, Xerox PARC, ftp://ftp.parc.xerox.com/pub/net- research/ ipmulti/. [7] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995. [8] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995. [9] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, NRL, August 1995. Wessels & Claffy Informativo [Pág. 27] RFC 2187 ICP Septiembre 1997 11. Agradecimientos Los autores quieren dar las gracias a Paul A Vixie por su colaboración en este documento, a Martin Hamilton por añadir el desarrollo de mutlicast para ICP, a Eric Rescorla y a Randall Atkinson por ayudar con temas de seguridad, y especialmente a Allyn Romanow por llevarnos por el buen camino. Wessels & Claffy Informativo [Pág. 28] RFC 2187 ICP Septiembre 1997 12. Direcciones de los autores Duane Wessels National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093 EMail: wessels@nlanr.net K. Claffy National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093 EMail: kc@nlanr.net Traducción: Pedro Trevilla Vara de Rey Madrid - España EMail: pedrotrev@eresmas.com Wessels & Claffy Informativo [Pág. 29] RFC 2187 ICP Septiembre 1997 Declaración completa de Copyright Copyright (C) The Internet Society (1997). Reservados todos los derechos. Le está permitido copiar y entregar a terceros este documento en su versión original o traducida. Puede procesar, copiar, publicar y distribuir, en parte o en totalidad, sin restricción de ningún tipo, trabajos derivados que comenten, expliquen o ayuden en la implementación de este documento, siempre que en cada copia o trabajo derivado incluya la mención de Copyright anterior junto con la presente nota. No le está sin embargo permitido modificar en ningún modo este documento, eliminar la mención de Copyright ni las referencias a The Internet Society u otras organizaciones de Internet, excepto con el fin de desarrollar los estándares de Internet (en cuyo caso deberá seguir los procedimientos para copyrights definidos en el proceso de Estándares Internet), o con el fin de traducirlo a otros idiomas distintos del inglés. Los permisos limitados concedidos más arriba son perpétuos y no serán revocados por la 'Internet Society' o sus sucesores o cesionarios. Este documento y la información contenida se ofrece "TAL CUAL". THE INTERNET SOCIETY Y THE INTERNET ENGINEERING TASK FORCE DESCARTAN CUALQUIER GARANTÍA EXPRESA O IMPLICITA POR EL USO DE LA INFORMACIÓN AQUÍ CONTENIDA Y EN PARTICULAR EXCLUYEN, SIN LIMITACIÓN ALGUNA, TODA GARANTÍA SOBRE POSIBLES INFRACCIONES DE DERECHOS O GARANTÍAS IMPLÍCITAS DE COMERCIALIZACIÓN Y ADECUACIÓN A LOS FINES PERSEGUIDOS. Agradecimiento Los fondos para las funciones desempeñadas por el editor RFC son proporcionados actualmente por la Internet Society. Wessels & Claffy Informativo [Pág. 30]