Protocolo trivial de transferencia de archivos

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

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

Resumen

Debido a su diseño simple, TFTP se puede implementar fácilmente mediante código con una pequeña huella de memoria. 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 System on a Chip (SoC) con muy pocos recursos.). 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. Actualmente, TFTP prácticamente no se utiliza para transferencias por Internet.

El diseño de TFTP se inspiró en el protocolo anterior EFTP, que formaba parte del conjunto de protocolos PARC Universal Packet. TFTP fue definido por primera vez en 1980 por IEN 133. En junio de 1981, el Protocolo TFTP (Revisión 2) se publicó como RFC 783 y luego se actualizó en julio de 1992 mediante 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 TFTP's especificación original.

TFTP es un protocolo simple para transferir archivos, implementado sobre los protocolos UDP/IP mediante 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 funciones avanzadas que se ofrecen. por 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 renombrar archivos o directorios y no tiene disposiciones para la autenticación de usuarios. Actualmente, TFTP generalmente solo se usa en redes de área local (LAN).

Detalles

(W1) Host A requests to write

(W2) Server S reconoce solicitud

(W3) Host A envía paquetes de datos numerados

(R1) Host A requests to read

(R2) Server S envía el paquete de datos 1

(R3) Un paquete de datos reconoce 1

En TFTP, el cliente inicia una transferencia emitiendo 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 en los términos especificados por RFC 2347. Si el servidor accede a la solicitud, el archivo se envía en bloques de longitud fija de 512 bytes por defecto o el número especificado en el tamaño de bloque opción negociada definida por RFC 2348. Cada bloque de datos transferidos, que generalmente se transporta dentro de un solo 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 receptor previsto expirará y podrá retransmitir su último paquete (que puede ser de datos o un acuse de recibo), lo que hará que el remitente del paquete perdido vuelva a transmitir ese paquete perdido. El remitente debe tener solo un paquete disponible para la retransmisión, ya que el reconocimiento del paso de bloqueo garantiza que todos los paquetes más antiguos se hayan recibido correctamente. Tenga en cuenta que ambos dispositivos involucrados en una transferencia se consideran emisores y receptores. Uno envía datos y recibe reconocimientos, el otro envía reconocimientos y recibe datos.

TFTP define tres modos de transferencia: netascii, octeto y correo.

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 de 0x20 a 0x7F (los caracteres imprimibles y el espacio) y ocho de los personajes de control. Los caracteres de control permitidos incluyen el null (0x00), la alimentación de línea (LF, 0x0A), y la devolución del carro (CR, 0x0D). Netascii también requiere que el marcador final de línea en un host sea traducido al par de caracteres CR LF para la transmisión, y que cualquier CR debe ser seguido por un LF o el null.
2. Octet permite la transferencia de bytes arbitrarios crudos de 8 bits, con el archivo recibido resultante byte-per-byte idéntico al enviado. Más correctamente, si un host recibe un archivo octet y luego lo devuelve, el archivo devuelto debe ser idéntico al original.
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 del destinatario como nombre de archivo. RFC 1350 declaró este modo de transferencia obsoleto.

TFTP utiliza UDP como protocolo de transporte. Siempre se inicia una solicitud de transferencia con destino al puerto 69, pero el remitente y el receptor eligen los puertos de transferencia de datos de forma independiente durante la inicialización de la transferencia. Los puertos se eligen al azar de acuerdo con los parámetros de la pila de red, generalmente de la gama de puertos efímeros.

1. El host iniciador A envía un paquete RRQ (bajo petición de lectura) o WRQ (bajo petición de escritura) para acoger S en el puerto número 69, que contiene el nombre de archivo, modo de transferencia, y opcionalmente cualquier opción negociada bajo los términos de RFC 2347.
2. S respuestas con una opción ACK si se utilizaron opciones, y un paquete ACK (reconocimiento) a WRQ y directamente con un paquete DATA a RRQ. Packet es enviado desde un puerto efímero asignado al azar, y todos los paquetes futuros a host S deben ser dirigidos a este puerto.
3. El host fuente envía paquetes DATA numerados al host de destino, todos menos el último que contiene un bloque de datos completo (512 bytes default). El host de destino responde con paquetes de ACK numerados para todos los paquetes DATA.
4. El paquete DATA 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 DATA final que contiene 0 bytes de datos.
5. Receptor responde a cada DAAT con ACK numerado asociado. El remitente responde a la primera ACK recibida de un bloque con DATA del siguiente bloque.
6. Si un ACK no es eventualmente recibido, un temporizador de retransmisión reenvia el paquete DATA.

TFTP siempre se ha asociado al arranque de red. Uno de los primeros intentos en este sentido fue Bootstrap Loading usando el estándar TFTP RFC 906, publicado en 1984, que estableció el estándar RFC 783 del Trivial File Transfer Protocol publicado en 1981 para ser utilizado como el protocolo estándar de transferencia de archivos para la carga de arranque. Le siguió poco después el estándar RFC 951 (BOOTP) del protocolo Bootstrap, publicado en 1985, que permitía que una máquina cliente sin disco descubriera su propia dirección IP, la dirección de un servidor TFTP y el nombre de un programa Network Bootstrap. (NBP) para ser transferido TFTP, cargado en la memoria y ejecutado. El protocolo de configuración de host dinámico estándar RFC 2131 (DHCP) publicado en 1997 mejoró las capacidades de BOOTP. Finalmente, en diciembre de 1998 se lanzó la versión 2.0 de Preboot Execution Environment (PXE), y en septiembre de 1999 se hizo pública la actualización 2.1 contando con TFTP como protocolo de transferencia de archivos. Intel ha decidido recientemente admitir ampliamente PXE dentro de la nueva especificación UEFI extendiendo el soporte TFTP a todos los entornos EFI/UEFI.

El protocolo original tiene un límite de tamaño de archivo de transferencia de 512 bytes/bloque x 65 535 bloques = 32 MB. En 1998, este límite se amplió a 65 535 bytes/bloque x 65 535 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 supera la MTU mínima en cualquier punto de la ruta de la red, la fragmentación y el reensamblaje de IP Ocurrirá no solo agregando más sobrecarga, sino que también conducirá a una falla total de transferencia cuando la implementación minimalista de la pila de IP en el BOOTP o ROM PXE de un host no implemente (o no lo haga correctamente) la fragmentación y el reensamblaje de IP. Si los paquetes TFTP se deben mantener dentro de la MTU Ethernet estándar (1500), el valor del tamaño del bloque se calcula como 1500 menos los encabezados de TFTP (4 bytes), UDP (8 bytes) e IP (20 bytes) = 1468 bytes/bloque, esto 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 transferencia de números de bloques (el contador de bloques vuelve a 0 o 1 después de 65535), lo que proporciona un tamaño de archivo de transferencia esencialmente ilimitado.

Dado que TFTP utiliza UDP, tiene que proporcionar su propio transporte y soporte de sesión. Cada archivo transferido a través de TFTP constituye un intercambio independiente. Clásicamente, esta transferencia se realiza en bloque, con solo un paquete (ya sea un bloque de datos o un "reconocimiento") alternativamente en vuelo en la red en cualquier momento. Debido a esta estrategia de bloque de datos único, 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 con ventanas en Windows 2008 como parte de sus Servicios de implementación de Windows (WDS), en enero de 2015 se publicó la opción RFC 7440 de TFTP Windowsize. 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 la opción Blocksize RFC 2348

Consideraciones de seguridad

TFTP no incluye mecanismos de inicio de sesión ni de control de acceso. Se debe tener cuidado al usar TFTP para transferencias de archivos donde se necesita autenticación, control de acceso, confidencialidad o verificación de integridad. Tenga en cuenta que esos servicios de seguridad podrían suministrarse por encima o por debajo de la capa en la que se ejecuta TFTP. También se debe tener cuidado en los derechos otorgados a un proceso de servidor TFTP para no violar la seguridad del sistema de archivos del servidor. TFTP a menudo se instala con controles tales que solo los archivos que tienen acceso público de lectura 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 al protocolo puedan generar problemas de responsabilidad insuperables.

Documentación de estándares IETF