要約

  • RFC 9611は同じTSi/TSrに複数のChild SAを作り、CPUやキューごとに独立した鍵とシーケンス空間を持たせ、共有カウンターの同期を避ける。
  • SA_RESOURCE_INFOはグループを示す。任意識別子はデバッグ専用で、相手のCPUを指定しない。TS_MAX_QUEUEはそのセレクター組だけの上限である。
  • 交渉成功の後に、入出力の導入、ローカル資源への結合、実パケットの分布、リプレイと損失、rekey、削除後の復帰、サービス性能を確認して初めて能力を主張できる。

監視画面には複数の成功したSAが並ぶ。だがカウンターを見ると、ほぼ全パケットが最初の一つを通っている。別の装置では受信用SAをすべて導入したものの、送信用は一つしかない。SA数と利用可能な並列度は別の数字である。

RFC 9611は、単一Child SAの鍵、暗号状態、シーケンス番号を多数のCPUが共有するとロックがボトルネックになる問題を扱う。複数の通常SAを用いれば、同じトラフィック方針を保ちながら、各資源が独立した鍵とカウンターを持てる。

同一でなければならないのはアルゴリズム、TSi/TSr、モード、圧縮などの契約である。独立すべきなのはSPI、鍵、シーケンス、実行資源である。前者はIKEv2が確認する。後者はローカル計測が確認する。

識別子は配置命令ではない

SA_RESOURCE_INFOの任意データは、同じセレクターを持つメンバーをデバッグ時に区別するために使える。しかし相手はそれを運用制御に使ってはならない。実CPU番号を露出すれば、どのパケットがどの資源に入るかを攻撃者へ知らせかねない。

また、一方の「queue-4」は他方で意味を持たない。これは認可、スケジューリング命令、ハードウェア身元、処理完了証明のいずれでもない。共通仕様はグループの最小意味だけを持ち、将来の配置判断をローカルに残す。

独立カウンターは入口にすぎない

RFC 4303のESPではシーケンスがリプレイ防止に関わり、RFC 6479は受信窓の実装文脈を与える。RFC 9611は保護を外すのではなく、複数の正当な状態領域に分ける。

文書にある単一CPUの約5 Gbit/sから25～30 CPUの40～60 Gbit/sという例は動機であって保証ではない。NIC、暗号、ドライバー、パケット長、フロー分布で結果は変わる。SAごとの双方向パケット・バイト、CPU/キュー、整合性・リプレイ失敗、損失、遅延、アプリ受信量を同時に測る必要がある。

方向ごとの義務は対称ではない

資源の少ないピアは使わない送信SAを省略できるが、交渉した受信SAはすべて導入しなければならない。相手はそこへ送信する権利を得たからである。ホストでは入出力を同じCPUに置くのが通常望ましく、非対称トラフィックを扱うゲートウェイでは別々に移動できる。

省略した送信側を後から追加するには、IKEデーモンが破棄する予定だった鍵材料が必要になることもある。資源移動と鍵消去は独立した運用項目ではない。

過渡状態を上限に含める

オンデマンド作成では両端が同時に開始し得る。最初のパケットは既存SAを通り、その応答が逆方向の取得を起こす。rekeyでは新旧SAが一時的に重なる。RFC 9611がCPU数の少なくとも二倍を推奨するのは、この正常な山を拒否しないためである。

特定TSi/TSrで上限に達したときはTS_MAX_QUEUEを返す。NO_ADDITIONAL_SASでは、異なるセレクターまで拒否したと誤解され得る。

Delete後の復帰にも所有者が要る。資源情報を含むローカル取得イベントがなければ、いつ再作成するか分からない。直ちに戻せば削除との無限ループ、戻さなければ最初のSAだけに固定される。RFC 2367のSADB_ACQUIRE経路をローカル資源情報で補う理由である。

この機能は信頼関係のある高負荷ゲートウェイ向けである。大量のSAは状態とSAD検索コストを増やす。低信頼の多数クライアントがいるリモートアクセスでは、標準はper-CPU SAも既定有効化も推奨しない。

情報源