Простой протокол передачи файлов TFTP поверх UDP

Введение

Очень базовый протокол передачи данных по UDP.

Протокол тривиальной передачи файлов (TFTP) — это простой протокол передачи файлов, работающий в режиме «шаг за шагом», который позволяет клиенту получать файл с удалённого хоста или передавать файл на удалённый хост. Одно из основных его применений — на начальных этапах загрузки узлов из локальной сети. TFTP используется для этой задачи благодаря своей простоте реализации. TFTP был впервые стандартизирован в 1981 году, а текущую спецификацию протокола можно найти в .

Обзор

Благодаря своей простой конструкции, TFTP может быть легко реализован кодом с небольшим объемом памяти. Поэтому он является протоколом выбора для начальных этапов любой стратегии сетевой загрузки, такой как BOOTP, PXE, BSDP и т. д., при работе как с высокопроизводительными компьютерами, так и с маломощными одноплатными компьютерами (SBC) и системами на кристалле (SoC). Он также используется для передачи образов прошивки и файлов конфигурации на сетевые устройства, такие как маршрутизаторы, брандмауэры, IP-телефоны и т. д. В настоящее время TFTP практически не используется для передачи данных в Интернете. При разработке TFTP оказал влияние более ранний протокол EFTP, который входил в состав пакета протоколов PARC Universal Packet. TFTP был впервые определен в 1980 году в IEN 133. В июне 1981 года протокол TFTP (ревизия 2) был опубликован как RFC 783, а позднее обновлен в июле 1992 года RFC 1350, который, среди прочего, устранил проблему "синдрома ученика чародея". В марте 1995 года RFC 1782, посвященный расширению опций TFTP, был обновлен в мае 1998 года RFC 2347 и определил механизм согласования опций, который устанавливает основу для согласования опций передачи файлов перед передачей с использованием механизма, соответствующего первоначальной спецификации TFTP. TFTP – это простой протокол для передачи файлов, реализованный поверх протоколов UDP/IP с использованием известного порта 69. TFTP был разработан как компактный и простой в реализации, поэтому ему не хватает большинства расширенных функций, предлагаемых более надежными протоколами передачи файлов. TFTP может только читать и записывать файлы на удаленный сервер или с него. Он не поддерживает перечисление, удаление или переименование файлов и каталогов, а также не предусматривает аутентификацию пользователей. В настоящее время TFTP обычно используется только в локальных сетях (LAN).

Подробности

В TFTP передача инициируется клиентом, отправляющим запрос на чтение или запись определенного файла на сервере. Запрос может опционально включать набор согласованных параметров передачи, предложенных клиентом в соответствии с условиями, указанными в RFC 2347. Если сервер удовлетворяет запрос, файл отправляется блоками фиксированной длины 512 байт по умолчанию или в количестве, указанном в опции согласования размера блока, определенной RFC 2348. Каждый блок передаваемых данных, который обычно передается в рамках одного IP-пакета во избежание фрагментации IP, должен быть подтвержден пакетом подтверждения (ACK) перед отправкой следующего блока. Пакет данных размером менее 512 байт или согласованного размера блока сигнализирует об окончании передачи. Если пакет теряется в сети, предполагаемый получатель ожидает истечения времени ожидания и может повторно отправить свой последний пакет (который может содержать данные или подтверждение), что приведет к повторной отправке потерянного пакета отправителем. Отправитель должен хранить только один пакет для повторной отправки, поскольку подтверждение в режиме «шаг за шагом» гарантирует, что все предыдущие пакеты были успешно получены. Следует отметить, что оба устройства, участвующие в передаче, рассматриваются как отправители и получатели. Один отправляет данные и получает подтверждения, а другой отправляет подтверждения и получает данные. TFTP определяет три режима передачи: netascii, octet и mail. Netascii – это модифицированная форма ASCII, определенная в RFC 764. Она состоит из 8-битного расширения 7-битного пространства символов ASCII от 0x20 до 0x7F (печатные символы и пробел) и восьми управляющих символов. Допустимые управляющие символы включают нулевой (0x00), перевод строки (LF, 0x0A) и возврат каретки (CR, 0x0D). Netascii также требует, чтобы маркер конца строки на хосте был преобразован в пару символов CR LF для передачи, и чтобы за каждым CR следовал либо LF, либо нулевой символ. Режим octet позволяет передавать произвольные сырые 8-битные байты, при этом полученный файл будет идентичен отправленному байт в байт. В частности, если хост получает octet-файл и затем возвращает его, возвращенный файл должен быть идентичен исходному. Режим передачи почты использует передачу Netascii, но файл отправляется получателю электронной почты, указав адрес электронной почты этого получателя в качестве имени файла. RFC 1350 объявил этот режим передачи устаревшим. TFTP использует UDP в качестве транспортного протокола. Запрос на передачу всегда инициируется на порт 69, но порты передачи данных выбираются независимо отправителем и получателем во время инициализации передачи. Порты выбираются случайным образом в соответствии с параметрами сетевого стека, обычно из диапазона эфемерных портов. Инициирующий хост A отправляет пакет RRQ (запрос на чтение) или WRQ (запрос на запись) хосту S на номер порта 69, содержащий имя файла, режим передачи и, опционально, любые согласованные параметры в соответствии с условиями RFC 2347. S отвечает пакетом Option ACK, если использовались параметры, и пакетом ACK (подтверждение) на WRQ и непосредственно пакетом DATA на RRQ. Пакет отправляется с случайно выделенного эфемерного порта, и все последующие пакеты хосту S должны быть направлены на этот порт. Отправляющий хост отправляет нумерованные пакеты DATA на хост назначения, все, кроме последнего, содержащие блок данных полного размера (по умолчанию 512 байт). Хост назначения отвечает нумерованными пакетами ACK на все пакеты DATA. Последний пакет DATA должен содержать менее полного блока данных, чтобы сигнализировать о том, что он последний. Если размер передаваемого файла является точным кратным размеру блока, отправитель отправляет последний пакет DATA, содержащий 0 байт данных. Получатель отвечает на каждый пакет DATA соответствующим нумерованным ACK. Отправитель отвечает на первый полученный ACK блока пакетом DATA следующего блока. Если ACK не получен в конечном итоге, таймер повторной отправки повторно отправляет пакет DATA. TFTP исторически связан с сетевой загрузкой. Одной из первых попыток в этом направлении был стандарт загрузки Bootstrap с использованием TFTP RFC 906, опубликованный в 1984 году, который установил стандарт Trivial File Transfer Protocol RFC 783, опубликованный в 1981 году, в качестве стандартного протокола передачи файлов для загрузки Bootstrap. Вскоре после этого последовал стандарт протокола Bootstrap RFC 951 (BOOTP), опубликованный в 1985 году, который позволял клиентской машине без диска обнаруживать свой собственный IP-адрес, адрес сервера TFTP и имя сетевой программы загрузки (NBP) для передачи через TFTP, загрузки в память и выполнения. Стандарт протокола динамической конфигурации хоста RFC 2131 (DHCP), опубликованный в 1997 году, улучшил возможности BOOTP. Наконец, Preboot Execution Environment (PXE) версии 2.0 был выпущен в декабре 1998 года, а обновление 2.1 было опубликовано в сентябре 1999 года, используя TFTP в качестве протокола передачи файлов. Intel недавно решил широко поддерживать PXE в новой спецификации UEFI, расширив поддержку TFTP на все среды EFI/UEFI. Исходный протокол имеет ограничение на размер передаваемого файла 512 байт/блок x 65535 блоков = 32 МБ. В 1998 году это ограничение было увеличено до 65535 байт/блок x 65535 блоков = 4 ГБ с помощью опции размера блока TFTP RFC 2348. Если определенный размер блока приводит к размеру IP-пакета, превышающему минимальный MTU в любой точке сетевого пути, произойдет фрагментация и сборка IP, что не только добавит дополнительную нагрузку, но и приведет к полной неудаче передачи, когда минималистичная реализация стека IP в BOOTP или PXE ROM хоста не реализует (или не реализует должным образом) фрагментацию и сборку IP. Если пакеты TFTP должны соответствовать стандартному MTU Ethernet (1500), значение размера блока рассчитывается как 1500 минус заголовки TFTP (4 байта), UDP (8 байт) и IP (20 байт) = 1468 байт/блок, что дает предел 1468 байт/блок x 65535 блоков = 92 МБ. Сегодня большинство серверов и клиентов поддерживают перенос номера блока (счетчик блоков возвращается к 0 или 1 после 65535), что дает практически неограниченный размер передаваемого файла. Поскольку TFTP использует UDP, он должен обеспечивать собственную транспортную и сессионную поддержку. Каждый файл, передаваемый через TFTP, представляет собой независимый обмен. Традиционно эта передача выполняется в режиме «шаг за шагом», когда в сети одновременно находится только один пакет (блок данных или «подтверждение»). Благодаря этой стратегии с одним блоком данных, а не отправке большего количества непрерывных блоков данных перед приостановкой передачи для ожидания соответствующего подтверждения (windowing), TFTP обеспечивает низкую пропускную способность, особенно по каналам связи с высокой задержкой. Microsoft представила TFTP с окнами в Windows 2008 как часть Windows Deployment Services (WDS), в январе 2015 года была опубликована опция размера окна TFTP RFC 7440. Это значительно повышает производительность для таких задач, как загрузка PXE, без побочного эффекта фрагментации IP, иногда наблюдаемого в опции размера блока RFC 2348.

In TFTP, a transfer is initiated by the client issuing a request to read or write a particular file on the server. The request can optionally include a set of negotiated transfer parameters proposed by the client under the terms specified by RFC 2347. If the server grants the request, the file is sent in fixed length blocks of 512 bytes by default or the number specified in the blocksize negotiated option defined by RFC 2348. Each block of transferred data, which is usually carried within a single IP packet in order to avoid IP fragmentation, must be acknowledged by an acknowledgment packet before the next block can be sent. A data packet of less than 512 bytes or the agreed blocksize option signals termination of a transfer. If a packet gets lost in the network, the intended recipient will timeout and may retransmit their last packet (which may be data or an acknowledgment), thus causing the sender of the lost packet to retransmit that lost packet. The sender has to keep just one packet on hand for retransmission, since the lock step acknowledgment guarantees that all older packets have been correctly received. Notice that both devices involved in a transfer are considered senders and receivers. One sends data and receives acknowledgments, the other sends acknowledgments and receives data. TFTP defines three modes of transfer: netascii, octet, and mail. Netascii is a modified form of ASCII, defined in RFC 764. It consists of an 8 bit extension of the 7 bit ASCII character space from 0x20 to 0x7F (the printable characters and the space) and eight of the control characters. The allowed control characters include the null (0x00), the line feed (LF, 0x0A), and the carriage return (CR, 0x0D). Netascii also requires that the end of line marker on a host be translated to the character pair CR LF for transmission, and that any CR must be followed by either a LF or the null. Octet allows for the transfer of arbitrary raw 8 bit bytes, with the received file resulting byte per byte identical to the one sent. More correctly, if a host receives an octet file and then returns it, the returned file must be identical to the original. Mail transfer mode uses Netascii transfer, but the file is sent to an email recipient by specifying that recipient's email address as the file name. RFC 1350 declared this mode of transfer obsolete. TFTP uses UDP as its transport protocol. A transfer request is always initiated targeting port 69, but the data transfer ports are chosen independently by the sender and receiver during the transfer initialization. The ports are chosen at random according to the parameters of the networking stack, typically from the range of ephemeral ports. The initiating host A sends an RRQ (read request) or WRQ (write request) packet to host S at port number 69, containing the filename, transfer mode, and optionally any negotiated option under the terms of RFC 2347. S replies with an option ACK if options were used, and an ACK (acknowledgement) packet to WRQ and directly with a DATA packet to RRQ. Packet is sent from a randomly allocated ephemeral port, and all future packets to host S should be directed to this port. The source host sends numbered DATA packets to the destination host, all but the last containing a full sized block of data (512 bytes default). The destination host replies with numbered ACK packets for all DATA packets. The final DATA packet must contain less than a full sized block of data to signal that it is the last. If the size of the transferred file is an exact multiple of the block size, the source sends a final DATA packet containing 0 bytes of data. Receiver responds to each DATA with associated numbered ACK. Sender responds to the first received ACK of a block with DATA of the next block. If an ACK is not eventually received, a retransmit timer re sends DATA packet. TFTP has always been associated to network booting. One of the first attempts in this regard was the Bootstrap Loading using TFTP standard RFC 906, published in 1984, which established the 1981 published Trivial File Transfer Protocol standard RFC 783 to be used as the standard file transfer protocol for bootstrap loading. It was followed shortly after by the Bootstrap Protocol standard RFC 951 (BOOTP), published in 1985, which allowed a disk less client machine to discover its own IP address, the address of a TFTP server, and the name of a Network Bootstrap Program (NBP) to be TFTP transferred, loaded into memory, and executed. Dynamic Host Configuration Protocol standard RFC 2131 (DHCP) published in 1997 improved BOOTP capabilities. Finally, the Preboot Execution Environment (PXE) version 2.0 was released in December 1998, and the update 2.1 was made public in September 1999 counting on TFTP as its file transfer protocol. Intel has recently decided to widely support PXE within the new UEFI specification extending the TFTP support to all EFI/UEFI environments. The original protocol has a transfer file size limit of 512 bytes/block x 65535 blocks = 32 MB. In 1998 this limit was extended to 65535 bytes/block x 65535 blocks = 4 GB by TFTP Blocksize Option RFC 2348. If the defined blocksize produces an IP packet size that exceeds the minimum MTU at any point of the network path, IP fragmentation and reassembly will occur not only adding more overhead but also leading to total transfer failure when the minimalist IP stack implementation in a host's BOOTP or PXE ROM does not (or fails to properly) implement IP fragmentation and reassembly. If TFTP packets should be kept within the standard Ethernet MTU (1500), the blocksize value is calculated as 1500 minus headers of TFTP (4 bytes), UDP (8 bytes) and IP (20 bytes) = 1468 bytes/block, this gives a limit of 1468 bytes/block x 65535 blocks = 92 MB. Today most servers and clients support block number roll over (block counter going back to 0 or 1 after 65535) which gives an essentially unlimited transfer file size. Since TFTP utilizes UDP, it has to supply its own transport and session support. Each file transferred via TFTP constitutes an independent exchange. Classically, this transfer is performed in lock step, with only one packet (either a block of data, or an 'acknowledgement') alternatively in flight on the network at any time. Due to this single data block strategy instead of sending a larger amount of uninterrupted data blocks before pausing the transfer to wait for the corresponding acknowledge (windowing), TFTP provides low throughput especially over high latency links. Microsoft introduced windowed TFTP in Windows 2008 as part of their Windows Deployment Services (WDS), in January 2015 TFTP Windowsize Option RFC 7440 was published. This substantially improves performance for things like PXE booting without the IP fragmentation side effect sometimes observed on Blocksize Option RFC 2348

Относительно безопасности

TFTP не предусматривает механизмов аутентификации или контроля доступа. При использовании TFTP для передачи файлов, когда требуется аутентификация, контроль доступа, конфиденциальность или проверка целостности, необходимо соблюдать осторожность. Следует учитывать, что эти функции безопасности могут быть реализованы на более высоком или низком уровне, чем уровень, на котором работает TFTP. Также необходимо тщательно настраивать права процесса TFTP-сервера, чтобы не скомпрометировать безопасность файловой системы сервера. TFTP часто устанавливается с ограничениями, допускающими доступ только к файлам, имеющим публичные права на чтение. Как правило, TFTP не поддерживает просмотр содержимого каталогов, удаление, переименование и запись файлов. Передача файлов по TFTP не рекомендуется в случаях, когда присущие протоколу ограничения могут повлечь за собой серьезную юридическую ответственность.

Документация стандартов IETF

RFC Номер Название Опубликованный Автор Устаревшая и информация об обновлениях Протокол TFTP (Ревизия 1) Июнь 1981K. Sollins Загрузка с помощью TFTP Июнь 1984Ross Finlayson Протокол загрузки Сентябрь 1985Bill CroftОбновлено в Протоколе TFTP (Ревизия 2) Июль 1992K. SollinsОбновлено в TFTP Option Extension Март 1995G. Malkin Протокол динамической конфигурации хоста Март 1997R. DromsОбновлено в TFTP Option Extension Май 1998G. Malkin TFTP Опция размера блока Май 1998G. Malkin TFTP Опции интервала времени ожидания и размера передачи Май 1998G. Malkin Принципы конфигурации интернет-хоста Май 2009B. Aboba TFTP Опция размера окна Январь 2015P. Masotta