要約

  • RFC 3617 は TFTP 参照の共通構文を登録した一方、極めて限定的な事情を除いて TFTP の継続利用を強く非推奨とした。標準的な名前は安全性の承認ではない。
  • URI の解析、モード変換、OACK、最終 ACK、外部ハッシュ、インストール、起動後の観測は別々の事実である。TFTP 自体にはアクセス制御、発行者認証、機密性、固有の完全性検証がない。

同じ「ファイル」という言葉に二つの実体があった

運用者が ;mode=netascii を付けた URI を登録する。サーバーとクライアントは仕様どおりに文字表現を変換し、転送を終える。プロトコル上は成功でも、送信元のバイト列と受信側のバイト列を同一のハッシュで扱う設計なら、評価は失敗し得る。

RFC 3617 は 2003 年 10 月に Informational RFC として公開され、Internet Standard を規定する文書ではない。既存機器が TFTP を参照する共通形式を必要としていたため URI を定義したが、本文は TFTP の継続利用を強く戒める。共通名が新しい転送方式への移行を容易にすることも期待していた。

古い仕組みを正確に表現することと、その仕組みを推奨することは別である。構文がなければ資産管理は自由記述に埋もれ、どの装置が何に依存しているか比較しにくい。構文は可視性を与えるが、下位プロトコルの性質は変えない。

IANA URI Schemes レジストリの tftp 行は RFC 3617 を参照する。これは名前の衝突を避け、仕様を探せるようにする調整記録である。現在のサービス、導入量、製品適合性、ファイルの安全性を示す測定記録ではない。

構文が運ぶものと運ばないもの

URI は tftp://、ホスト、ファイル、任意のモードで構成される。モードは netascii または octet、省略時は octet である。廃止済みの mail は対象外となった。

そこには成果物の版、期待サイズ、ダイジェスト、署名者、承認者、有効期限、対象機種、配布リング、ロールバック先がない。サーバー上の同じ名前が翌日に別の内容を指しても、URI は変わらない。

読み出しと書き込みが操作として定義されても、文字列は権限を付与しない。TFTP 内部にはアクセス制御がないため、サーバープロセス、ファイルシステム、ネットワーク分離など外部の判断が必要になる。書き込み URI は単なる参照ではなく、変更能力として扱うべきである。

RFC 3617 は、転送前に存在や権限を確認できず、到着の完全性や信頼性も保証されないと説明する。妥当な URI は、到達不能、拒否、途中終了、誤った内容のいずれも排除しない。

netascii は論理的なテキスト転送のために表現を変える。octet はその変換を避けるが、暗号学的な同一性を与えない。どちらのモードでも、承認済み成果物との比較値は別の経路で供給しなければならない。

最終 ACK は最終成果ではない

RFC 1350 の基本交換は RRQ または WRQ、DATA、ACK、ERROR から成る。ブロック番号と確認で小さな実装を成立させる。最後のブロックへの ACK は会話の終端を示すが、発行者の身元を示さない。

経路上の置換、誤った DNS 応答、サーバー側の差し替え、受信後の書き換えは、最終 ACK だけでは区別できない。ACK を「検証済み」と表示すると、プロトコルの進行を成果物の真実へ昇格させてしまう。

RFC 3617 が列挙する制約は多い。プロトコル内アクセス制御がなく、中間者への保護もなく、固有の完全性検査がない。途中再開はできず、元の方式は一度に一ブロックだけを送り、単純なタイムアウトしか持たない。安全なキャッシュ意味論もない。

管理境界を越えると、UDP、NAT、ファイアウォールの挙動も加わる。URI にホストが書かれていることは、現在そこへ到達できるという保証ではない。

基本の意味論では転送前サイズが確定せず、実装はメモリとディスクの上限を守る必要がある。見慣れた拡張子は容量制御にも形式検証にもならない。

オプションの合意は内容への合意ではない

RFC 2347 はクライアント起点のオプション交渉と OACK を導入した。サーバーが受け入れないオプションは省略され、要求されなかったものとして扱われる。したがって監査記録には要求値と実効値の両方が必要である。

RFC 2348 のブロックサイズ、RFC 2349 のタイムアウトと転送サイズは運用を改善する。tsize は容量判断に役立つが、同じ長さの別ファイルを排除しない。値が正しいことと内容が承認済みであることは別だ。

RFC 7440 のウィンドウサイズは複数ブロックを一度に進め、性能を改善できる。同文書はなお TFTP にログインやアクセス制御がなく、拡張が安全性を追加しないと述べる。高速化は信頼レベルを上げない。

証拠の語彙を狭く保つ必要がある。OACK はパラメータ受諾、最終 ACK は観測された交換終端、外部ハッシュは期待値との一致、署名検証は受理した鍵と内容の結合を示す。インストールと実行結果はさらに後ろにある。

ブート用途では観測者自身が置き換わる

BOOTP と DHCP の系譜は、初期状態の少ない装置がサーバーと起動ファイルを知る構成を説明する。これは歴史的な機構の証拠であり、特定の現行製品や普及率を示すものではない。

起動イメージを受け取る場合、受信側ソフトウェアは次の起動で置き換えられる可能性がある。古い状態を観測できる主体が消える前に、受信したダイジェスト、インストール先、承認記録、ロールバック像を外部へ残さなければならない。

一台のサーバーが多くの装置を供給すれば、誤設定や差し替えは相関した変更になる。小さな端末実装という局所的な利点が、フリート全体の集中リスクに変わる。

堅い受領書は承認済み成果物 ID、ハッシュ、署名方針、サイズ、対象機種、変更責任者から始まる。次に正確な URI、名前解決、ネットワーク区画、外部のサーバー認証または隔離、モード、要求・受諾オプション、ブロック数、受信ハッシュを結ぶ。最後にスロット、起動選択、実行版、サービス観測を記録する。

廃止は復旧試験が終わってから

通常の配布を認証付き転送へ移しても、故障時の救済経路が残る。新方式が証明書、正確な時刻、DNS、完全なストレージに依存し、それらが失われた場面では動かないなら、同じ役割の代替ではない。

まず URI とサーバーを発見し、通常・試験・救済・休眠に分類する。次にインターフェース、クライアント、ファイル、操作、区画を限定する。外部成果物検証と新しい転送を導入し、実際の故障条件で演習した後、段階的に TFTP を退役させる。

Heng Lu の running-code の考え方は、登録名を権威へ膨らませない。最小仕様は相互運用に必要なフィールドを共有できる。採用、拒否、隔離、移行は損失を負う運用者の局所判断である。公開文書ではなく、実装された遷移と観測可能な受領書が現実を作る。

RFC 3617 は古いプロトコルへ勲章を与えたのではない。退役させるために、まず正確な名札を付けたのである。

Sources