摘要

  • RFC 3617 为 TFTP 引用规定统一语法，同时强烈建议除极受限情形外不要继续使用 TFTP。注册解决的是共同描述问题，不是安全背书。
  • URI 解析成功、服务器接受选项、最后一个 ACK、外部哈希校验、安装完成和启动后的观测各自只证明一层事实。TFTP 本身不提供访问控制、发布者认证、机密性或内建完整性证明。

先看到的是一个整齐的字符串

资产系统里出现 tftp://boot.example/router.img，格式整齐，IANA 注册表也能查到 tftp。审计报告很容易把这两件事合并成“使用标准协议”，然后再把“标准”误读为“经过安全批准”。

RFC 3617 在 2003 年 10 月以信息类 RFC 发布，文本明确说明它并不规定互联网标准。它之所以定义 URI，是因为现实中的设备和工具已经使用 TFTP，需要一种共同、可解析的写法。与此同时，文档用极强措辞反对继续使用 TFTP，并希望统一写法能帮助迁移到现代传输机制。

这不是自相矛盾。淘汰旧依赖之前，首先要能发现和命名它。URI 让扫描器识别协议、主机、文件和模式，也让不同系统交换同一份配置含义。但它不会改变底层协议的能力。

IANA 当前 URI Schemes 注册表列出 tftp 并链接 RFC 3617。该记录证明协调层为一个名字指定了参考文档和变更归属。它没有证明服务器正在运行、实现符合规范、文件经过授权、网络提供保护，或某家厂商的现有设备安全。

URI 没有携带制品清单

RFC 3617 的语法由 tftp://、主机、斜杠、文件名和可选的 ;mode= 组成。模式只有 netascii 与 octet；未写时默认 octet。已经废弃的 mail 模式没有进入新语法。

这条字符串没有软件版本、预期长度、内容哈希、签名者、批准人、过期时间、发布批次、设备类型或回滚槽位。文件路径是服务器本地解释的名字，不是全球不可变对象。同一路径可以在不同时间返回不同字节。

规范允许对 URI 进行读和写。能够描述写操作不等于获得写权限。TFTP 协议内部没有访问控制，权限只能依赖服务器进程、文件系统、网络边界或其他外部措施。写能力必须被当作独立的破坏性权限治理。

RFC 3617 还指出，通过该接口无法在传输前确认文件是否存在或具有什么权限，也不能保证传输可靠、完整。于是“URI 合法”只说明解析器接受了字符串；它没有跨过信任链的第一道门。

netascii 模式可能改变文本表示。发送端与接收端看到的字节不必完全一致。octet 避免这种转换，却依然不提供密码学承诺。模式正确与制品身份正确是两项证据。

ACK 只应当被称作 ACK

RFC 1350 描述基本的读写请求、DATA、ACK 和 ERROR。块号与确认让一个小型传输按顺序推进，最后一个数据块被确认后，协议对话可以结束。

结束对话并不认证内容来源。最后 ACK 能证明观察到的对端接受了相应块，不能证明 DNS 指向预期服务器、路径中没有替换者、服务器目录仍保存批准镜像，或接收端随后没有覆盖文件。

RFC 3617 对缺口写得很直接：没有协议内访问控制，没有中间人保护，没有固有完整性检查，无法从中断处恢复，原始传输一次只允许一个块在途，只有简单超时，没有复杂的慢启动与退避。TFTP 也没有安全缓存语义。

跨管理域会增加另一组不确定性。TFTP 使用 UDP，NAT 和防火墙可能不支持或阻止流量。可达性变化是部署事实，而不是 URI 能承诺的属性。

基础语义也无法在传输前可靠获知大小，客户端必须保护内存和磁盘边界。文件名带 .img 不证明它适合目标设备，更不证明长度合理。

接受参数并没有接受身份

RFC 2347 允许客户端在 RRQ 或 WRQ 后附加选项。服务器通过 OACK 返回自己接受的选项和值；不支持的选项可以被省略，双方必须把它当作从未请求。实际参数可能不同于配置模板。

因此 OACK 是一张有价值但范围很窄的收据。它说明该对端愿意以哪些参数继续，不说明对端身份，不验证文件，也不授权安装。监控必须保存“请求值”和“接受值”，不能只保存计划。

RFC 2348 加入块大小协商。RFC 2349 加入超时与传输大小。预知大小有助于容量控制，合适超时有助于运行；但大小不是哈希。两个不同文件可以有相同字节数，一个错误服务器也可以给出看似合理的数值。

RFC 7440 后来增加窗口大小，使多个块可在确认前发送，提高某些环境的吞吐。它仍然说明 TFTP 没有登录或访问控制，扩展也没有添加安全控制。更快地收到未认证字节不会让这些字节更可信。

启动链把一次下载放大成全队列风险

BOOTP 与 DHCP 的历史材料解释了 TFTP 为什么常出现在初始配置：设备只需少量状态就能得知服务器与启动文件。这里的来源没有证明某个现有产品、部署比例或安全事故，只能证明这种架构关系。

一旦文件参与启动，下载后的每一步都需要单独观察：写入哪个槽位，是否做了外部哈希或签名验证，谁批准激活，重启选择了哪个映像，运行系统报告的版本是什么，业务流量是否恢复。下载成功不能替代这些收据。

集中服务器还形成相关性风险。一个路径配置错误或文件替换可能同时影响整个设备群。简单协议在单台设备上减少组件，却可能在组织层面放大爆炸半径。

完整收据应从批准记录开始：不可变制品 ID、哈希、签名策略、大小、目标设备类别、变更所有者与回滚目标。传输阶段记录精确 URI、解析结果、网段、外部认证或隔离措施、模式、请求和接受选项、块与字节数以及接收后哈希。最后记录安装槽位、激活决定、启动身份和独立服务观测。

这些状态应当分别显示为：已命名、已解析、已协商、已传输、已验证、已安装、已激活、已观测。缺失的一层不能由上一层的绿色状态自动填补。

退出计划必须覆盖最坏的一天

日常配置迁移到受认证传输并不等于完成替代。某些 TFTP 路径只在主系统失效时用于救援。新的机制如果依赖故障时不存在的证书、时钟、DNS 或完整存储，就不能承担同一角色。

正确顺序是先发现并分类所有 URI，再限制服务器接口、客户端、文件、写权限和网段；随后引入外部制品验证与新传输，演练真实恢复场景，最后按设备批次退休旧路径。只调大 blksize 或 windowsize 是性能优化，不是退出。

Heng Lu 的运行代码优先原则在这里要求把符号放回原位。RFC 与注册表提供最薄的共同语言；承担损失的运营者决定本地是否接受。发布不等于采用，注册不等于授权，只有实际运行和可核验收据才能建立结果。

RFC 3617 最成熟之处，是它没有让协调机构假装成安全担保人。它给旧机制一个统一名字，也给管理者一条清晰界线：名字到此为止。

Sources