Network Working Group G. Malkin Request for Comments: 1782 Xylogics, Inc. Updates: 1350 A. Harkin Category: Standards Track Hewlett Packard Co. Marzo 1995 Negociación de Opciones para el TFTP Estado de esta Memoria Este documento es la especificación de un protocolo estándar para la comunidad de Internet, y propone discusiones y promueve sugerencias para mejorarlo. Por favor refiérase a la edición actual de los "Protocolos Oficiales y Estándares de Internet" (STD 1) para conocer el estado actual del estándar y de este protocolo. La distribución de esta memoria es ilimitada. Extracto El Protocolo Trivial de Transferencia de Archivos [1] es un protocolo simple, de paso a paso regulado, para la transferencia de archivos que permite a un cliente leer o escribir un archivo en un servidor remoto. Este documento describe una extensión simple del TFTP que le permitirá una negociación previa antes de empezar con la transferencia de archivos. Introducción El mecanismo de negociación de opción propuesto en este documento, es una ampliación compatible con las especificaciones anteriores del protocolo TFTP. Gracias a este mecanismo que es consistente con la petición de paquetes del TFTP, es posible crear una negociación previa antes de proceder a la transferencia propiamente dicha. El mecanismo es simple en principio y lo que hace es forzar una secuencia de petición-respuesta-reconocimiento similar al sistema de paso a paso regulado que usa el mismo TFTP. Mientras que el mecanismo de negociación de opciones es de propósito general, en el que se pueden negociar muchos tipos de opciones, este mecanismo se creo principalmente para dar soporte a la opción de Tamaño de Bloque que se encuentra definido en [2]. Otras opciones adicionales se definen en [3]. Se asume que el lector de este documento se encuentra familiarizado con las especificaciones del TFTP [1] y su terminología. Malkin y Harkin [Pág. 1] RFC 1782 Negociación de Opciones para el TFTP marzo 1995 Formato de los paquetes Las opciones TFTP se añaden tanto a los paquetes de peticiones de lectura como a los de peticiones de escritura. Y se define un nuevo tipo de paquete, el reconocimiento de opción (OACK), que se usa para reconocer la petición de negociación de opciones del cliente. También se define el nuevo código de error 8 para indicar la presencia de una negociación de opciones y con la señalización de este error puede terminarse la transferencia. Las opciones se añaden a los paquetes de peticiones de lectura o de escritura de la forma siguiente: +-------+---~~----+---+---~~---+---+---~~---+---+---~~---+---+--> | cod | archivo | 0 | modo | 0 | opc1 | 0 | valor1 | 0 | < +-------+---~~----+---+---~~---+---+---~~---+---+---~~---+---+--> >-------+---+---~~---+---+ < opcN | 0 | valorN | 0 | >-------+---+---~~---+---+ Los "0" mostrados en estas ilustraciones y los "1" de abajo son todos octetos cero, i.e. terminadores Nulos para los campos precedentes. cod El campo del código de operación puede contener un 1 para peticiones de lectura o un 2 para peticiones de escritura, tal como está definido en [1]. archivo El nombre del archivo para ser leído o escrito, tal como está definido en [1]. Este campo ha de terminarse con un byte nulo. modo Es el modo de la transferencia del archivo: "netascii", "octet", o "mail", tal como está definido en [1]. Este campo ha de terminarse con un byte nulo. opc1 Es la primera opción en ASCII sin tener en cuenta las mayúsculas o minúsculas (p.ej., "blksize"). Este campo ha de terminarse con un byte nulo. valor1 El valor asociado con la primera opción, en ASCII sin tener en cuenta las mayúsculas o minúsculas. Este campo ha de terminarse con un byte nulo. Malkin y Harkin [Pág. 2] RFC 1782 Negociación de Opciones para el TFTP marzo 1995 opcN, valorN Es el último par de opción/valor. Cada campo estará en ASCII sin tener en cuenta las mayúsculas o minúsculas y terminará con un byte nulo. Las opciones y sus valores siempre terminan con un byte nulo, para mantener el formato de las peticiones originales. Si hay que negociar múltiples opciones, estas se añadirán una a continuación de la otra. El orden de colocación de las opciones, es indiferente. La longitud máxima de un paquete de petición será de 512 octetos. El paquete OACK tendrá el siguiente formato: +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ | cod | opc1 | 0 | valor1 | 0 | opcN | 0 | valorN | 0 | +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ cod El campo del código de operación contendrá un 6, para el reconocimiento de la Opción. opc1 Es el reconocimiento de la primera opción, que es una copia de la petición original. valor1 El valor reconocido asociado con la primera opción. La forma en que este valor puede diferir del de la petición original, está detallado en la especificación de la opción. opcN, valorN Es el reconocimiento para el último par de opción/valor. Protocolo de Negociación Tal como se ha mostrado arriba, el cliente añade opciones al final de los paquetes de petición de lectura o escritura, y se pueden añadir cualquier cantidad de opciones, el orden de estas opciones es indiferente. Si el servidor soporta la negociación de opciones, y puede reconocer una o más de las opciones en el paquete de petición, el servidor responderá con un Reconocimiento de Opción (OACK). Cada opción que el servidor reconozca, y acepte su valor, se incluirá en el paquete OACK. Algunas opciones pueden variar sus valores tal como estaban propuestos, pero esto es una característica especifica de esa opción. El servidor no colocará en el OACK cualquier opción que no haya sido Malkin y Harkin [Pág. 3] RFC 1782 Negociación de Opciones para el TFTP marzo 1995 específicamente pedida por el cliente; esto quiere decir, que únicamente el cliente puede iniciar la negociación de opciones. Las opciones que el servidor no soporta, simplemente las omitirá en el OACK; y esto no generará un paquete de error. Si el valor de una opción soportada es inválido en la especificación de esa opción, tendrá que indicar como debe actuar el servidor: no colocará el reconocimiento en el OACK, o responderá con un valor alternativo, o bien enviará un paquete de ERROR con código 8 para terminar la transferencia. Cualquier opción que no se ha reconocido por el servidor, será ignorada por el cliente, y el servidor hará como si nunca se la hubieran pedido. Si se piden múltiples opciones, el cliente usará de estas opciones las que hayan sido reconocidas por el servidor, y no usará aquellas que no se hubieran reconocido por dicho servidor. Cuando el cliente añade opciones al final de los paquetes de petición de lectura, aparecerá una de las siguientes respuestas devueltas por el servidor: OACK - reconocimiento de la petición de lectura y las opciones; DATOS - reconocimiento de una petición de lectura sin opciones; ERROR - la petición ha sido denegada. Cuando el cliente añade opciones al final de los paquetes de petición de escritura, aparecerá una de las siguientes respuestas devueltas por el servidor: OACK - reconocimiento de la petición de escritura y las opciones; ACK - reconocimiento de una petición de escritura sin opciones; ERROR - la petición ha sido denegada. Si un servidor no tiene implementada la negociación de opciones, ignorará cualquiera de ellas que estén añadidas a la petición del cliente. En este caso el servidor devolverá un paquete de DATOS a una petición de lectura o un ACK a una petición de escritura, que es el comportamiento normal de una transferencia TFTP. En el caso que el servidor devuelva un error a una petición que transporta una opción, el cliente podrá intentar repetir esa petición, pero sin añadir las opciones. Esta implementación de opciones podría hacer que el servidor considerará datos extraños en el paquete de petición y por lo tanto erróneos. El cliente tiene dos maneras de valorar la aceptación del paquete de OACK del servidor, dependiendo cómo se realizó la petición de Malkin y Harkin [Pág. 4] RFC 1782 Negociación de Opciones para el TFTP marzo 1995 transferencia original. Si la transferencia se inició con una Petición de Lectura, entonces se enviará un ACK (con el número de bloque puesto a 0) al cliente para que confirme los valores en el paquete OACK del servidor. En cambio si la transferencia se inició con un Paquete de Escritura, entonces el cliente empezará la transferencia con el primer paquete de DATOS, usando los valores negociados. Si el cliente no admite el OACK, enviará un paquete de ERROR, con el código 8 hacia el servidor para terminar la transferencia. Una vez que el cliente reconoce un OACK, con una respuesta apropiada sin error, podrá usar solo las opciones devueltas por el servidor con los valores que dicho cliente está de acuerdo. Recuerde que el servidor no puede realizar una petición de opción; solo puede responder a ella. Si el cliente recibe un OACK que contenga una opción no pedida, debe responder con un paquete de ERROR con el código 8 y terminar la transferencia. Ejemplos Petición de Lectura cliente servidor ------------------------------------------------------- |1|foofile|0|octeto|0|blksize|0|1432|0| --> RRQ <-- |6|blksize|0|1432|0| OACK |4|0| --> ACK <-- |3|1| 1432 octetos de datos | DATA |4|1| --> ACK <-- |3|2| 1432 octetos de datos | DATA |4|2| --> ACK <-- |3|3|<1432 octetos de datos | DATA |4|3| --> ACK Petición de Escritura cliente servidor ------------------------------------------------------- |2|barfile|0|octeto|0|blksize|0|2048|0| --> RRQ <-- |6|blksize|0|2048|0| OACK |3|1| 2048 octetos de datos | --> DATA <-- |4|1| ACK |3|2| 2048 octetos de datos | --> DATA <-- |4|2| ACK |3|3|<2048 octetos de datos | --> DATA <-- |4|3| ACK Consideraciones de seguridad Malkin y Harkin [Pág. 5] RFC 1782 Negociación de Opciones para el TFTP marzo 1995 Los conceptos de seguridad no se comentan en esta memoria. Referencias [1] Sollins, K., "El protocolo TFTP (Revisión 2)", STD 33, RFC 1350, MIT, Julio 1992. [2] Malkin, G., and A. Harkin, "Opción del tamaño de Bloque para TFTP", RFC 1783, Xylogics, Inc., Hewlett Packard Co., Marzo 1995. [3] Malkin, G., and A. Harkin, A., "Opciónes de exceso de Tiempo y Tamaño de Archivo para TFTP", RFC 1784, Xylogics, Inc., Hewlett Packard Co., Marzo 1995. Dirección de los Autores Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803 Phone: (617) 272-8140 EMail: gmalkin@xylogics.com Art Harkin Internet Services Project Information Networks Division 19420 Homestead Road MS 43LN Cupertino, CA 95014 Phone: (408) 447-3755 EMail: ash@cup.hp.com Traductor: Gabriel Ortí i Flores Barcelona Malkin y Harkin [Pág. 6]