要約

  • RFC 3358 は、下位層の完全性検査だけでは経路処理が読む PDU を守れない場合に備え、IS-IS の CSNP、PSNP、IIH に任意の 16 ビット Fletcher チェックサム TLV を定義した。
  • 欠如とゼロ値は互換性のため受理され、誤った値、重複、許可されない PDU への配置は破棄される。これは偶発的な破損の検出であり、送信者の認証ではない。

入口では何も起きていないように見える。フレームは到着し、リンク層の検査を通り、上位へ渡される。ところが IS-IS の処理が長さフィールドを読む段階で、受信した構造が送信時の構造と同じとは限らない。緑色の状態表示が誤っているのではない。その表示の射程を、人が勝手に延長していたのである。

2002 年 8 月に Informational RFC として公開された RFC 3358 は、ISIS ワーキンググループの T. Przygienda による文書である。対象は限定されていた。LSP にはすでにチェックサムがあった一方、Complete Sequence Number PDU、Partial Sequence Number PDU、IS-IS Hello PDU は下位層の完全性に依存していた。

その依存は、下位実装の不具合や、期待したチェック機能を備えないリンク技術によって崩れる。破損した PDU が経路処理に届き、とくに PDU 長や TLV 長が変わると、単なる値の誤りでは済まない。パーサーが認識する境界そのものが動き、後続のバイト列が別の項目として読まれる。

RFC が懸念したのは、この意味の増幅である。要約 PDU が実在しない多数の LSP、あるいは空の LSP を列挙しているように見える可能性があった。物理的には小さな変化でも、リンク状態データベースへの主張として解釈された瞬間、多数の処理を誘発し得る。

修正は控えめだった。タイプ 12、長さ 2 オクテットの任意 TLV に、文書の規則に従って PDU 全体から計算した 16 ビット Fletcher チェックサムを入れる。RFC 3359 はタイプ 12 を IS-IS TLV のコードポイント表に記録した。新しさは計算法より、経路 PDU を理解する境界で新しい受領証を発行した点にある。

対応する受信側は、許可された単一 TLV に非ゼロ値があれば検証する。不一致なら PDU を破棄する。TLV が二つ以上ある場合も、許可されない PDU 種別に置かれた場合も破棄する。曖昧な構造をデータベース処理へ進ませないための規則である。

ただし、TLV が無いことは違反ではない。過去の実装はタイプ 12 を送らず、任意拡張の公開だけで既存の隣接を壊すわけにはいかなかった。未知の TLV を通常どおり扱う古い受信側は、新しい検証をしないまま PDU を処理し得る。仕様の存在、送信側の対応、受信側の検証は別々の事実である。

値ゼロにも固有の意味がある。RFC はゼロを正しいものとして扱うが、非ゼロの Fletcher 値を比較した証拠ではない。運用では、欠如、ゼロ、非ゼロで成功、非ゼロで失敗、重複、不正配置を分けなければならない。「チェックサム正常」という一項目にまとめれば、検証の有無が見えなくなる。

認証との関係は、この差をさらに明確にする。暗号学的認証と別のチェックサムが互いの対象フィールドを含むと、計算順序や循環依存が生じる。RFC 3358 は HMAC-MD5 のような認証を使う場合、任意チェックサムを省略するかゼロにするよう求める。RFC 5304 と RFC 5310 が扱う IS-IS 認証は、タイプ 12 とは別の証拠を生む。

Fletcher チェックサムは偶発的なビット変化を検出できる。しかし、PDU の発信者、権限、再送の新鮮さ、能動的な改変者を証明しない。攻撃者が内容を変えて値を再計算できるなら、単純なチェックサムは身元証明にならない。したがって、鍵や盾の比喩ではなく、別の測定ゲートとして理解すべきである。

歴史資料にも範囲がある。RFC 1195 は TCP/IP と二重環境における統合 IS-IS を記述する。RFC 1142 は ISO 10589 関連資料を再掲したが、RFC 7142 は後に Historic へ移し、IETF 標準にする意図ではなかったと整理した。この系譜から RFC 3358 の普及率を推測することはできない。

後続 RFC は PDU の重要性を示すが、特定事故の証拠ではない。RFC 5303 はポイントツーポイント IIH に三者ハンドシェイク情報を加え、RFC 5306 は再起動信号を扱い、RFC 6232 はパージされた LSP の発信元を識別する。いずれも、2002 年の破損シナリオが実際の障害原因だったとは述べていない。

RFC 3358 には、固有名付きの停止事例、ベンダー別採用一覧、導入率、導入前後の故障削減値がない。文書が提供するのは実装の状態遷移であり、世界の導入実績ではない。この欠落は弱点ではなく、記事が越えてはいけない証拠境界である。

実務では、隣接ごとの観測が必要になる。送信側が TLV を出すか、受信側が理解するか、認証のためゼロを使うか、誤値・重複・不正種別を別々に数えるかを確認する。異常が出たら、インターフェースのエラー、パケット捕捉、ソフトウェア版、トポロジー変更と時間を合わせる。チェックサムは破損が見えた場所を示すが、その発生源を単独では示さない。

導入も段階的であるべきだ。まず能力と認証設定を棚卸しし、欠如を直ちに障害扱いせず受信検証を有効にする。非ゼロ検証と破棄理由の基準値を作り、状態が変わったときだけ追加証拠を集める。混在環境の互換性と、完全に対応した隣接の強い受領証を同じ言葉で表してはならない。

ここから一般原則が得られる。完全性の結果には必ず範囲がある。フレーム検査、PDU チェックサム、認証、データベース整合性、経路の正しさ、利用者の到達性は、それぞれ異なる問いに答える。一つの層の成功を、次の層の正しさへ自動的に昇格させてはいけない。

本稿は Lu Heng の二つの論考を明示的な編集上の視点として使う。「Minimum Initial Specification」は、局所的に導入できる小さな仕様が全体更新を待たずに証拠を増やす構造を捉える。「Reality Layers」は、物理的なバイト、象徴的な成功表示、プロトコル解釈、事故説明を分離する。これは RFC 著者の意図を追加する主張ではない。

フレームの検査は確かに通っていた。ただし、経路処理が必要とした証明は、そこではまだ発行されていなかった。

出典