stringtranslate.com

Protocolo trivial de transferencia de archivos

El Protocolo trivial de transferencia de archivos ( TFTP ) es un protocolo de transferencia de archivos simple y continuo que permite a un cliente obtener un archivo de un host remoto o colocarlo en él . Uno de sus usos principales es en las primeras etapas del arranque de los nodos desde una red de área local . TFTP se ha utilizado para esta aplicación porque es muy fácil de implementar.

TFTP se estandarizó por primera vez en 1981 [1] y la especificación actual del protocolo se puede encontrar en RFC  1350.

Descripción general

Debido a su diseño simple, TFTP se puede implementar fácilmente mediante código con un consumo de memoria reducido . Por lo tanto, es el protocolo de elección para las etapas iniciales de cualquier estrategia de arranque de red como BOOTP , PXE , BSDP , etc., cuando se apunta desde computadoras con muchos recursos a computadoras de placa única (SBC) y sistemas en un chip (SoC) con recursos muy bajos. También se utiliza para transferir imágenes de firmware y archivos de configuración a dispositivos de red como enrutadores , cortafuegos , teléfonos IP , etc. Hoy en día, TFTP prácticamente no se utiliza para transferencias por Internet.

El diseño de TFTP fue influenciado por el protocolo anterior EFTP , que era parte de la suite de protocolos de paquetes universales PARC . TFTP fue definido por primera vez en 1980 por IEN 133. [2] En junio de 1981, el Protocolo TFTP (Revisión 2) fue publicado como RFC 783 y posteriormente actualizado en julio de 1992 por RFC 1350 que solucionó, entre otras cosas, el síndrome del aprendiz de brujo . En marzo de 1995, la Extensión de opción TFTP RFC 1782 actualizada posteriormente en mayo de 1998 por RFC 2347, definió el mecanismo de negociación de opciones que establece el marco para las opciones de transferencia de archivos que se negociarán antes de la transferencia utilizando un mecanismo que es consistente con la especificación original de TFTP.

TFTP es un protocolo simple para transferir archivos, implementado sobre los protocolos UDP/IP utilizando el conocido puerto número 69. TFTP fue diseñado para ser pequeño y fácil de implementar, y por lo tanto carece de la mayoría de las características avanzadas que ofrecen los protocolos de transferencia de archivos más robustos. TFTP solo lee y escribe archivos desde o hacia un servidor remoto. No puede enumerar, eliminar o cambiar el nombre de archivos o directorios y no tiene disposiciones para la autenticación de usuarios. Hoy en día, TFTP generalmente solo se utiliza en redes de área local (LAN).

Detalles

(W1) El host A solicita escribir
(W2) El servidor S reconoce la solicitud
(W3) El host A envía paquetes de datos numerados
(R1) El host A solicita leer
(R2) El servidor S envía el paquete de datos 1
(R3) El host A reconoce el paquete de datos 1

En TFTP, una transferencia se inicia cuando el cliente emite una solicitud para leer o escribir un archivo en particular en el servidor. La solicitud puede incluir opcionalmente un conjunto de parámetros de transferencia negociados propuestos por el cliente según los términos especificados por RFC 2347. Si el servidor acepta la solicitud, el archivo se envía en bloques de longitud fija de 512 bytes por defecto o la cantidad especificada en la opción negociada de tamaño de bloque definida por RFC 2348. Cada bloque de datos transferidos, que normalmente se transporta dentro de un único paquete IP para evitar la fragmentación de IP, debe ser reconocido por un paquete de reconocimiento antes de que se pueda enviar el siguiente bloque. Un paquete de datos de menos de 512 bytes o la opción de tamaño de bloque acordada señala la finalización de una transferencia. Si un paquete se pierde en la red, el destinatario previsto agotará el tiempo de espera y podrá retransmitir su último paquete (que puede ser de datos o un reconocimiento), lo que hará que el remitente del paquete perdido retransmita ese paquete perdido. El remitente debe tener a mano solo un paquete para la retransmisión, ya que el acuse de recibo de bloqueo garantiza que todos los paquetes anteriores se hayan recibido correctamente. Observe que ambos dispositivos involucrados en una transferencia se consideran remitentes y receptores. Uno envía datos y recibe acuses de recibo, el otro envía acuses de recibo y recibe datos.

TFTP define tres modos de transferencia: netascii, octet y mail.

  1. Netascii es una forma modificada de ASCII , definida en RFC 764. Consiste en una extensión de 8 bits del espacio de caracteres ASCII de 7 bits desde 0x20 hasta 0x7F (los caracteres imprimibles y el espacio) y ocho de los caracteres de control. Los caracteres de control permitidos incluyen el nulo (0x00), el avance de línea (LF, 0x0A) y el retorno de carro (CR, 0x0D). Netascii también requiere que el marcador de final de línea en un host se traduzca al par de caracteres CR LF para su transmisión, y que cualquier CR debe ir seguido de un LF o del nulo.
  2. Octet permite la transferencia de bytes arbitrarios de 8 bits, y el archivo recibido es idéntico byte por byte al enviado. Más correctamente, si un host recibe un archivo de octetos y luego lo devuelve, el archivo devuelto debe ser idéntico al original. [3]
  3. El modo de transferencia de correo utiliza la transferencia Netascii, pero el archivo se envía a un destinatario de correo electrónico especificando la dirección de correo electrónico de ese destinatario como nombre de archivo. La RFC 1350 declaró obsoleto este modo de transferencia.

TFTP utiliza UDP como protocolo de transporte . Una solicitud de transferencia siempre se inicia apuntando al puerto 69, pero los puertos de transferencia de datos son elegidos independientemente por el emisor y el receptor durante la inicialización de la transferencia. Los puertos se eligen al azar según los parámetros de la pila de red, normalmente de entre el rango de puertos efímeros . [4]

  1. El host iniciador A envía un paquete RRQ (solicitud de lectura) o WRQ (solicitud de escritura) al host S en el puerto número 69, que contiene el nombre del archivo, el modo de transferencia y, opcionalmente, cualquier opción negociada según los términos del RFC 2347.
  2. S responde con una opción ACK si se usaron opciones y un paquete ACK (reconocimiento) a WRQ y directamente con un paquete DATA a RRQ. El paquete se envía desde un puerto efímero asignado aleatoriamente y todos los paquetes futuros al host S deben dirigirse a este puerto.
  3. El host de origen envía paquetes de DATOS numerados al host de destino. Todos, excepto el último, contienen un bloque de datos de tamaño completo (512 bytes por defecto). El host de destino responde con paquetes ACK numerados para todos los paquetes de DATOS.
  4. El paquete de DATOS final debe contener menos que un bloque de datos de tamaño completo para indicar que es el último. Si el tamaño del archivo transferido es un múltiplo exacto del tamaño del bloque, la fuente envía un paquete de DATOS final que contiene 0 bytes de datos.
  5. El receptor responde a cada DATA con un ACK numerado asociado. El emisor responde al primer ACK recibido de un bloque con los DATA del siguiente bloque.
  6. Si finalmente no se recibe un ACK, un temporizador de retransmisión reenvía el paquete DATA.

TFTP siempre ha estado asociado al arranque en red. Uno de los primeros intentos en este sentido fue el estándar RFC 906 de Bootstrap Loading using TFTP, publicado en 1984, que estableció el estándar RFC 783 de Trivial File Transfer Protocol publicado en 1981 para ser utilizado como el protocolo de transferencia de archivos estándar para la carga de bootstrap. Fue seguido poco después por el estándar de Bootstrap Protocol RFC 951 (BOOTP), publicado en 1985, que permitía a una máquina cliente sin disco descubrir su propia dirección IP, la dirección de un servidor TFTP y el nombre de un Network Bootstrap Program (NBP) para ser transferido por TFTP, cargado en memoria y ejecutado. El estándar de Dynamic Host Configuration Protocol RFC 2131 (DHCP) publicado en 1997 mejoró las capacidades de BOOTP. Finalmente, la versión 2.0 del Preboot Execution Environment (PXE) fue lanzada en diciembre de 1998, y la actualización 2.1 se hizo pública en septiembre de 1999 contando con TFTP como su protocolo de transferencia de archivos. [5] Intel ha decidido recientemente dar soporte amplio a PXE dentro de la nueva especificación UEFI extendiendo el soporte de TFTP a todos los entornos EFI/UEFI. [6] [7]

El protocolo original tiene un límite de tamaño de archivo de transferencia de 512 bytes/bloque x 65535 bloques = 32 MB. En 1998, este límite se amplió a 65535 bytes/bloque x 65535 bloques = 4 GB mediante la opción de tamaño de bloque TFTP RFC 2348. Si el tamaño de bloque definido produce un tamaño de paquete IP que excede la MTU mínima en cualquier punto de la ruta de red, se producirá fragmentación y reensamblado de IP, lo que no solo agregará más sobrecarga [8] sino que también provocará un fallo total de la transferencia cuando la implementación de la pila IP minimalista en la ROM BOOTP o PXE de un host no implementa (o no implementa correctamente) la fragmentación y reensamblado de IP. [9] Si los paquetes TFTP deben mantenerse dentro de la MTU estándar de Ethernet (1500), el valor del tamaño de bloque se calcula como 1500 menos los encabezados de TFTP (4 bytes), UDP (8 bytes) e IP (20 bytes) = 1468 bytes/bloque, lo que da un límite de 1468 bytes/bloque x 65535 bloques = 92 MB. Hoy en día, la mayoría de los servidores y clientes admiten la renovación del número de bloques (el contador de bloques vuelve a 0 o 1 [10] después de 65535), lo que da un tamaño de archivo de transferencia esencialmente ilimitado.

Dado que TFTP utiliza UDP, debe proporcionar su propio soporte de transporte y sesión. Cada archivo transferido a través de TFTP constituye un intercambio independiente. Clásicamente, esta transferencia se realiza en secuencia, con solo un paquete (ya sea un bloque de datos o un "reconocimiento") alternativamente en tránsito en la red en cualquier momento. Debido a esta estrategia de un solo bloque de datos en lugar de enviar una mayor cantidad de bloques de datos ininterrumpidos antes de pausar la transferencia para esperar el reconocimiento correspondiente (ventana), TFTP proporciona un bajo rendimiento, especialmente en enlaces de alta latencia . Microsoft introdujo TFTP en ventana en Windows 2008 como parte de sus Servicios de Implementación de Windows (WDS), en enero de 2015 se publicó TFTP Windowsize Option RFC 7440. Esto mejora sustancialmente el rendimiento para cosas como el arranque PXE sin el efecto secundario de fragmentación de IP que a veces se observa en Blocksize Option RFC 2348 [11].

Consideraciones de seguridad

TFTP no incluye mecanismos de inicio de sesión ni de control de acceso. Se debe tener cuidado al utilizar TFTP para transferencias de archivos en las que se necesita autenticación, control de acceso, confidencialidad o comprobación de integridad. Tenga en cuenta que esos servicios de seguridad se pueden proporcionar por encima o por debajo de la capa en la que se ejecuta TFTP. También se debe tener cuidado con los derechos otorgados a un proceso de servidor TFTP para no violar la seguridad del sistema de archivos del servidor. TFTP se instala a menudo con controles de modo que solo los archivos que tienen acceso de lectura público estén disponibles a través de TFTP. Además, normalmente no se permite enumerar, eliminar, renombrar y escribir archivos a través de TFTP. No se recomiendan las transferencias de archivos TFTP cuando las limitaciones inherentes del protocolo podrían generar problemas de responsabilidad insuperables. [12]

Documentación de estándares IETF

Véase también

Referencias

  1. ^ RFC 783
  2. ^ Karen R. Sollins (29 de enero de 1980). El protocolo TFTP. IETF . IEN 133. Consultado el 1 de mayo de 2010 .
  3. ^ RFC 1350, página 5.
  4. ^ Karen R. Sollins (julio de 1992). El protocolo TFTP (revisión 2). IETF . doi : 10.17487/RFC1350 . RFC 1350 . Consultado el 1 de mayo de 2010 .
  5. ^ "Especificación del entorno de ejecución de prearranque (PXE) - Versión 2.1" (PDF) . Intel Corporation. 20 de septiembre de 1999. Archivado desde el original (PDF) el 2 de noviembre de 2013. Consultado el 8 de febrero de 2014 .
  6. ^ "Especificación de interfaz de firmware extensible unificada" (PDF) . UEFI. 2013-12-02 . Consultado el 2014-04-04 .
  7. ^ "Análisis del rendimiento del arranque PXE de UEFI" (PDF) . Intel Corporation. 2 de febrero de 2014. Archivado desde el original (PDF) el 8 de agosto de 2014. Consultado el 4 de abril de 2014 .
  8. ^ RFC 2348, página 3.
  9. ^ RFC 5505, página 7.
  10. ^ "Ampliación de TFTP". CompuPhase . Consultado el 12 de diciembre de 2018 .
  11. ^ RFC 7440, página 1.
  12. ^ RFC 7440, página 7.