要約

  • 送信側は、32ビットの FROM が逆向きの宛先として使えるとき SRC を立てた。中継アダプターは、その条件を満たさないと判断すればビットを落とせた。
  • 残った SRC が示すのは、アドレスを反転すると発信プロセスへ戻れるという狭い性質である。CRC、プロトコルサーバー選択、物理的な保護、利用者認証、要求の認可はそれぞれ別だった。

1988年2月の RFC 1044 は、IP データグラムを HYPERchannel 装置で運ぶための実装慣行を整理した。既存の16ビット形式をできるだけ壊さず、32ビットアドレスへ拡張し、メッセージ種別を整え、静的な設定表から ARP サーバー、将来のブロードキャスト ARP へ移れる道筋も示した。

その仕様には複数の「正しさ」が同居する。宛先プロセスはどこか。内容は壊れていないか。返信はどこへ戻るか。内包された IP アドレスは何か。RFC 1044 は、それらを一つの信頼印にまとめず、別々のフィールドとして扱った。

FROM は往路を運ぶためのアドレスではなかった

基本形式では TO が配達先を決める。FROM は往路の物理配送には使われず、受信ホストへ渡され、応答先を作るために使われた。通常は16ビットの TO と FROM、さらに対応する trunk マスクを反転すると、元へ返信できるとされた。

ここで得られるのは会話の対称性である。返信先が分かっても、そのプロセスを誰が操作したかは分からない。正しい場所にある装置でも、侵害されたプログラムや権限のない自動処理が要求を送れる。

また、TO の論理部分は最終的なプロトコルサーバーを選んだ。メッセージ種別は中継処理に影響できても、登録済みの完全な TO が選んだサーバーを終点で差し替えることはできない。配達先の選択と途中の分類は別の統制だった。

SRC は経路が減点できる主張だった

32ビット形式には GNA、CRC、SRC が加わる。GNA は拡張アドレスを示す。CRC は対応アダプターによるメッセージ完全性検査を表す。SRC は Source FROM Address Correct、すなわち逆方向に使える送信元アドレスの主張だった。

最初に主張するのは送信ホストである。実際に使ったインターフェースを正しく反映する FROM を用意したなら SRC を立てる。各中継アダプターは、その FROM が逆向きの TO として発信元へ配達されないなら、ビットを落とせる。

これは中継機器が順番に本人確認を追加する方式ではない。経路は最初の主張を残すか、取り下げるだけである。消えたビットは強い帰路主張が維持されなかったことを示す。残ったビットは、規則を実施した経路要素が定義済みの不整合を見つけなかったことを示す。

したがって、未設定は攻撃の証明ではない。送信側が立てなかった可能性も、古い機器が対応しなかった可能性もある。設定済みも暗号学的な認証ではない。経路要素の実装と管理が信頼できるかは、ビットの外側で確認しなければならない。

保証の終点は発信プロセスだった

RFC 1044 は FROM が正しい意味を限定している。到着時にも SRC が立っていれば、TO と FROM を反転したメッセージは、元のメッセージを実際に発したプロセスへ配達される。

この保証は具体的だが、主体認証より狭い。プロセスは人名でもアカウントでも公開鍵でもない。侵害されたプロセスも応答を受け取れる。返信が成功しても、要求が新しいこと、許可されていること、処理結果が正しいことは分からない。

仕様は、FROM に基づくより強い安全性にはアダプターと中間リンクの慎重な物理保護が必要だと述べる。物理的な管理境界が明示され、装置と設定が責任ある主体の下にあるなら、SRC は地域的な判断材料になりうる。しかし SRC 自身は、その管理境界の存在を証明しない。

CRC は別の失敗を扱った

CRC ビットを分けた設計は重要である。対応装置は32ビット CRC を付加し、複数のリンクや内部処理を通過した内容の破損を終点で検査できた。これはバイト列の完全性に関する記録である。

CRC 成功は帰路を保証しない。SRC 成功は内容の無変更を保証しない。どちらも利用者を識別せず、アプリケーションに処理権限を与えない。「検証済み」という一語では、どの証拠が存在したのか後から再現できない。

RFC 791 の IPv4 データグラムは、HYPERchannel の内側に独自の送信元、宛先、プロトコル、全長、ヘッダーチェックサムを持つ。リンクの FROM と IP 送信元が一致すれば構成の整合性を高められるが、二つのアドレスが一致しても許可された主体にはならない。

アドレス解決は所有者を決めなかった

RFC 1044 は、IP アドレス下位部からの生成、ローカル表、既知の ARP サーバー、将来の分散ブロードキャストという段階を描く。RFC 826 の形式は、プロトコルアドレスとリンクアドレスを対応させるために使われた。

静的表、中央サーバー、ローカル応答では証拠の出所が違う。どれも次の HYPERchannel ヘッダーを作るには役立つが、表の更新者、情報の鮮度、装置の所有者、要求の権限を自動的には示さない。

誤った対応でも、返信だけはきれいに戻れる場合がある。SRC は選ばれた対応の可逆性を保てても、その対応が組織上正しいかまでは審査しない。

受信 IP ドライバーには即時判断を求めなかった

仕様の IP ドライバー部分は、送信側が完全に正しい FROM を用意しようとしたとき SRC を立てるよう求める一方、受信側には当時そのビットで特定の動作をしないよう述べる。ビットがない場合、現実または想像上のセキュリティ違反にどう対応するかは、さらに検討が必要だった。

新しい信号をそのまま拒否規則にしなかった点は慎重である。未対応機器を攻撃者とみなせば互換性が障害になる。立ったビットを認証とみなせば、可逆なアドレスが権限へ化ける。運用規則には経路能力、物理管理、アドレス管理、要求の影響が必要だった。

RFC 1044 の歴史的な価値は、物理ネットワークの証拠を明示しながら、その意味を帰路に止めたことにある。一つのビットは返信を助ける。信頼全体を代行はしない。

情報源と証拠の限界

RFC 1044 は各ヘッダー、反転規則、フラグ、物理保護条件、ドライバー指針、解決段階を定める。RFC 791 は内包される IPv4 の境界を、RFC 826 はアドレス解決の一般形式を定める。

これらは仕様を証明するが、特定製品の実装、設置現場の物理的保護、操作者の身元、要求の認可、処理結果は証明しない。