要約

  • FC-SP の SA は単方向だが同種の二本が一組として存在し、t11FcSpSaPairTable はアクティブな双方向ペアごとに一行を持つ。その行だけではフレームがどちらかの SA を使ったと分からない。
  • 適用範囲には順序付き Traffic Selector、方向、bypass・discard・protect・verify の動作、SPI、交渉済み transform が必要で、上位層の結果はさらに別の証拠である。

ペアは状態であり、利用記録ではない

各アクティブ SA は SADB に SPI、シーケンスカウンタ、transform パラメータを持つ。SA 自体は単方向だが、反対方向の同種 SA と必ず対になる。この構造を MIB はペア行として公開する。

その行が示すのは、観測したエンティティに現在ペアがあることだ。双方にトラフィックがあったこと、特定フレームが保護されたこと、ストレージ操作が成功したことは示さない。状態の存在と状態の使用は異なるイベントである。

Selector がフレームの意味を決める

Traffic Selector は順序を持つ。ある項目は FC-2 frame や CT_IU を bypass または discard し、別の項目は protect または verify して対応 SA を指す。探索順で最初に一致した項目が処理を決める。

したがって、同じ Fabric にアクティブ SA があるという理由だけでフレームへ「暗号化済み」の印を付けられない。方向、選択順、一致項目、動作、SPI、transform、当該 epoch のカウンタが必要だ。

提案テーブルも結果ではない。Initiator が提示する値、Responder が受け入れ可能な値、交渉で合意した値は三つの段階である。設定上の好みを実セッションへコピーしてはならない。

Fibre Channel の仕組みを IPsec と呼ばない

RFC は SA Management を Fibre Channel 向け IKEv2 サブセットと説明し、IPsec ではないと明記する。ESP_Header は FC-2 frame、CT_Authentication は CT_IU を保護する。

名前や概念の類似はプロトコル同一性を証明しない。証跡には FC-SP の方式、保護対象、方向、交渉済み transform と報告エンティティを残す。

認証は SA の可能性を作る

秘密、証明書、パスワードに基づく基盤が用意され、DH-CHAP、FCAP、FCPAP は相互認証と任意の共有鍵生成を行える。その鍵は SA 構築に使われ得る。IKEv2-AUTH は認証と SA 管理を組み合わせられる。

設定済み方式から実行済み認証を推測できず、認証から SA を、SA からフレームを、フレームから上位処理を推測できない。外部検証サーバーが到達不能ならローカル情報を使う場合もあり、設定されたサーバープロトコルは実際の経路ではない。

ポリシーは編集から実施へ飛ばない

RFC 5324 は非アクティブ Policy Objects を編集領域として持つ。管理者がオブジェクトを変更し、それらを参照する新しい Policy Summary を作り、別の有効化操作を呼ぶ。操作には成功と失敗がある。

現在実施されている内容は、読み取り専用のアクティブ Policy Objects が示す。設定行、要求、有効化結果、アクティブ集合の再読という四段階を保存する必要がある。

Summary は各アクティブオブジェクトへのポインターとその暗号学的ハッシュを持つ。ハッシュは参照バージョンを結ぶが、全 Switch への同時配布や実施を証明しない。Fabric の管理名は Summary ではなく Switch Membership List にある。

永続性は書込み可能性ではない

StorageType が permanent(4) でも、対応情報が書込み可能である必要はない。再起動後に残るか、管理面から変更できるか、現在有効かは別の問いだ。

アクティブと非アクティブの双方はサーバーセッション後も残る。一方、読取りの整合性が保証されるのは server session 内だけである。ロック外の巡回取得は、個々に正しい行から存在しなかった一時点を組み立て得る。

デフォルト寿命を残り時間と表示しない

SA 寿命は時間または通過バイト数で表せる。デフォルトは明示値のない SA にだけ適用され、限界に達すれば終了して必要に応じて置換される。

初期値、単位、明示かデフォルトか、消費量、作成 epoch、終了、置換先を分ける。デフォルト八時間という設定をアクティブ SA の残り時間として表示すれば、存在しない測定を作る。

通知は失敗より少なくなるよう設計される

認証失敗は入ってくる各 frame で起こり得るため、t11FcSpSaNotifyAuthFailure はレート制御される。一つの SA の最初の失敗後、同じ窓の後続通知は抑制される。Fabric 内で通知済み SA 数が設定上限に達すれば、別 SA の最初の通知も抑制される。

失敗の検出とカウントは続けなければならない。trap がないことは、失敗なし、無効化、抑制、収集損失、再起動のいずれでもあり得る。窓、上限、抑制数、失敗カウンタ、sysUpTime が一緒に必要だ。

拒否履歴は最古行を捨てる

拒否テーブルの最大はゼロから1000で、満杯なら最古の情報を新しい拒否で置換する。再起動後は少なくなり、未対応実装では最大が常にゼロになる。

空表は「拒否なし」を証明しない。最終通知の種別も管理システム再起動以降だけの状態である。履歴容量、退避、再起動、収集配送を知らずに否定証拠として使えない。

カウンタの索引を落とさない

管理インスタンス、Fabric、エンティティ、インターフェースが所有者を決める。InterfaceIndexOrZero のゼロは、そのインスタンスから Fabric へ向かう全インターフェースを表す。非一時集計は消滅した SA の一時カウンタを含み得る。

索引なしの数値、sysUpTime なしの差分、Counter32 wrap を扱わない傾向には決定権がない。

決定証跡

ポリシーには整合したセッション、非アクティブ名とハッシュ、提案 Summary、要求元、状態、失敗理由、変換後のアクティブ Summary を残す。SA にはエンティティ、インターフェース、peer、両方向、SPI、transform、Selector 順、寿命とカウンタを残す。

障害主張には通知設定、窓、上限、抑制、履歴容量、退避、再起動、収集結果を追加する。利用と配送には別のフレーム観測と上位結果が必要だ。

出典