RFC 5193：PANA成功は関連付けジョブを作成しない

要約

RFC 5193は、PANA以前に安全なチャネルがない環境では、攻撃に耐えるEAP方式が暗号鍵を生成し、その後のプロトコルがPaCとEPの間に逐パケット保護のためのセキュリティ関連付けを作る、という連鎖を示す。
鍵生成はジョブ作成ではなく、ジョブ作成はプロトコル実行ではなく、実行完了は現在のアタッチメントに結び付いたSAの観測でもない。欠落を検知するには、成功イベントだけでなく「次の義務が作られた」という受領証が要る。

障害監視は、存在した処理の失敗を得意とする。キューに入ったジョブが落ちればアラートが出る。再試行が尽きれば赤くなる。だが、作成条件が誤って偽になり、ジョブが最初から存在しなければ、監視対象そのものがない。

RFC 5193の環境分岐は、この無音の欠落を重要にする。PANA以前のPaC-to-EPチャネルがすでに安全なら、後続のセキュア関連付けは不要になり得る。安全でないなら、EAP方式はその環境に適し、さらに後続プロトコルに使う鍵を生成しなければならない。

したがって、「後続処理なし」には二つの意味がある。設計上不要だったのか、必要だったのに義務が生成されなかったのかである。

自動化は環境判定を単なるラベルとして扱うべきではない。判定結果は、EAP方式への制約と、成功後に作るべき仕事の集合を生成する。

必要な記録は、判定ID、対象アタッチメント、根拠、ポリシーバージョン、選択されたEAP方式、鍵生成期待、後続関連付けの要否である。required=trueなら、その判定からジョブIDへの参照が必要になる。参照が空なら、それ自体が失敗状態である。

RFC 5193はジョブキューのデータモデルを規定しない。これは標準の依存関係を運用可能にするための推論である。標準が「この環境では後続プロトコルが必要」と述べるなら、システムは必要性から実行への移行を監査できなければならない。

EAP方式が鍵を生成したという事実は重要である。しかし鍵は入力であって、PaCとEPの間の関連付けそのものではない。どのピアが鍵を利用したか、どのプロトコルが走ったか、どのSAが作られたか、どのリンクまたはIP経路に適用されたかは別の事実である。

鍵の存在をdata_plane_secureへコピーすると、最も高価な実行部分が見えなくなる。逆に、関連付けプロトコルの成功をPANAの成功として書き戻せば、責任面が混ざる。

受領証の連鎖は一方向でよい。環境判定が方式と義務を選ぶ。EAP実行が鍵結果を出す。義務がジョブを作る。ジョブがプロトコル試行を持つ。試行がピアに結び付いたSA結果を持つ。後段の成功は前段の証拠を補強しても、前段が存在したことを捏造しない。

運用画面にとって、認証成功は分かりやすい終点である。ユーザー名、時刻、結果を一行で示せる。セキュア関連付けは別装置、別キュー、別プロトコルにまたがりやすく、表示が難しい。

そのため、一つの緑色状態にまとめるインセンティブが生まれる。画面は簡潔になるが、成功の権限が拡張される。PANAの結果が、まだ実行されていない関連付けの代わりに語り始める。

本稿はRFC 5191の記事を繰り返さない。そちらは認証、認可、EP適用、データ面結果の境界を扱う。ここで焦点にするのは一段前、RFC 5193の環境分類が後続義務を生成したか、その義務が実行対象として存在したかである。

ジョブIDだけでも足りない。関連付けは具体的なPaC、インターフェース、下層ピア、EP、アタッチメント版に結び付かなければならない。移動やフェイルオーバーの後に古いジョブが成功しても、新しい経路の保護を証明しない。

スケジューラは入力の関連性を検査する必要がある。現在のアタッチメント版とジョブの版が一致するか。対象EPは同じか。鍵材料は同じPANA/EAP文脈から来たか。古い作業なら、成功として保存しつつ現在の要求は未充足のままにする。

結果の上書きは原因を失わせる。新しいジョブが成功したからといって、最初のジョブが欠落していた事実を削除してはならない。欠落は設計不良を示し、後の修復は現在状態を示す。両方が必要である。

もちろん、後続ジョブがないことが正しい環境もある。RFC 5193は、物理的に保護されたアクセスや、すでに認証・暗号化された下層チャネルを例に挙げる。その場合、PANA後に新しい関連付けを走らせる必要はなくなり得る。

だから監査は「ジョブがない＝障害」と単純化できない。まず、PANA前チャネルの保護を示すアタッチメント固有の受領証を確認する。その受領証が有効で、現在のPaC-to-EP経路を覆うなら、required=falseには理由がある。

能力一覧や共置情報は理由にならない。IPsec対応、暗号化設定、PAA/EP同居は、それぞれ現在チャネルの観測とは異なる。不要判定は、実行を省略する権限を持つため、実行以上に明確な出所が必要である。

運用指標には、secure-after判定数、鍵生成成功数、関連付け必須数、ジョブ作成数、対象一致数、SA観測数を別々に置く。差分がゼロであることを期待するのではなく、差分の理由を列挙可能にする。

たとえば鍵生成成功が100、必須判定が80、ジョブ作成が79なら、一件は実行前に消えた。ジョブ80、SA79なら、別の面で止まった。すべてを「保護成功率99%」へ圧縮すると、所有者が変わる境界を失う。

Lu Hengの現実層の考え方はここで実務的である。ジョブ行は保護ではない。しかし、ジョブ行すらない場合、システムは必要だと判断した作業を実行世界へ渡していない。その不在は第一級の証拠である。