Summary

  • RFC 1108 は IPv4 オプション 133 を、複数回置ける追加セキュリティラベルの容器として定義し、各形式コードの意味を相互運用可能な別仕様に委ねた。
  • Extended Security Option は必ず Basic Security Option と共存し、設定も共有する必要があった。拡張部分の削除は、パケットの拒否や誤った機密度の付与につながり得た。

番号だけでは動かない拡張

Extended Security Option はタイプ 133 で始まり、長さは可変だが最低 3 オクテット、さらに 1 オクテットの Additional Security Info Format Code を持つ。その後のフィールドは、コードが選んだ構文に従う。選択された形式が認めれば、追加フィールドが空でもよかった。

登録表に名前を載せるだけでは足りない。RFC 1108 は、各形式コードについて、独立した実装同士が相互運用できるほど詳しい構文と、アルゴリズムとして実行できる受理・拒否手順を RFC で示すよう求めた。ビット列を人間向けのラベルへ対応させる情報は非公開でもよいが、機械処理の契約は共有されなければならない。

このオプションはフラグメントにもコピーされ、IPv4 ヘッダーの容量が許す範囲で複数回現れ得た。ただし、繰り返せることと単独で成立することは別である。ESO を持つデータグラムには必ず Basic Security Option が必要で、BSO のない ESO はエラーだった。未登録コード、矛盾した長さ、形式を定義した RFC に反する内容もエラーであり、ICMP Parameter Problem の対象となった。

対応範囲は選択できた。BSO だけを実装して ESO を実装しないシステムも、ESO の一部の形式コードだけを扱うシステムも認められた。しかも BSO の Protection Authority ビットと ESO の形式コードには対応関係がない。隣り合う二つのフィールドが一つの安全判断に関わりながら、別々の登録制度と能力集合に支配されていた。

経路制御にも追加の協調が要る。中継システムが ESO ラベルに応じて保護経路を選ぶには、ルーティングプロトコル側も情報を運べるよう拡張しなければならない。オプションは主張を運ぶだけで、それを実行に移すには、ポートのセキュリティ設定、対応コードの知識、経路状態がそろう必要があった。

削除すると意味も変わる

RFC 7126 は後に、ESO が私設の高セキュリティネットワークで限定的に使われていたことを記録した。ESO を取り除くと、受信側がラベル不備としてパケットを捨てる可能性がある。さらに、データに誤った機密度を結び付け、扱いを強めたり弱めたりするおそれもあった。

だから既定動作は慎重である。装置は将来どの環境に置かれるかを事前には知らないため、ESO があるという理由だけで削除または破棄すべきではない。利用しない環境だと分かっている場合には管理者が破棄を設定でき、装置には監査可能なパケット数の記録も推奨された。

資料から、現在の普及率、現行の対応コード一覧、全製品に共通する挙動までは分からない。確かなのは、拡張性が協調を不要にしたのではなく、登録表、別仕様、継続的に整合させる設定へ協調の場所を移したという点である。

出典