Summary

  • 11月2日の個人提出草案は、鍵管理装置のIDとIPアドレス、QKDリンクの鍵生成速度をIS-ISのGENINFOで伝える。制御装置はその情報から中継ノードの順番を決める。
  • 草案はIS-ISがKM-IPのアドレス形式を検証せず、制御装置へ透過的に渡すと記す。広告は候補の提示であり、鍵を受け取る資格の確認は別の判断だ。

アプリケーションまたは鍵管理主体が送信元、宛先、必要な鍵速度を指定する。制御装置はIS-ISで広告されたノードとリンクの情報を集め、信頼する中継ノードの順番を選び、送信元にSRv6のセグメント列を設定する。UDPの鍵中継パケットはその経路をたどる。ルーティング広告の一つのアドレス欄が、鍵素材の行き先を決める材料になる。草案が描く構成であり、稼働網の測定結果ではない。

提案される能力情報には8オクテットのKM-IDが入り、IS-ISドメイン内で一意でなければならない。下位のKM-IPにはIPv4またはIPv6アドレスを載せる。KM-IPが一つもなければ受信側はQKD能力情報全体を無視する。アドレスがあっても、IS-ISは形式を検証せず制御装置へ渡す。別の情報は隣接ノードと物理インターフェースを指定する。任意の32ビット値は毎秒何キロビットの鍵を生成できるか示す。広告元は設定した期間、速度の更新を抑えられるため、制御装置が見る数字は現状より古いことがある。

IS-ISの暗号認証はLSPの送り主と完全性を確かめる助けになる。しかしKM-IPの先がそのサービスの鍵を預かる資格まで自動的に証明するわけではない。

草案の安全性の節は、偽のID、アドレス、リンク能力が鍵素材の誤配送や妨害につながると認め、認証を勧める。制御装置がアドレスと中継権限を別途どう確認するかは規定していない。形式は正しいが別の鍵管理装置に属するアドレスを流し、制御装置の判断を記録すべきだ。

RFC 6823はアプリケーション情報用のGENINFO TLV 251を定め、非ルーティング情報の更新がLSPの洪水送信と処理を増やすと警告した。標準化RFCがゼロ番インスタンスを認めない限り非ゼロのIS-ISインスタンスを使い、想定更新頻度を示すよう求める。新草案はQKD用Application IDとして101を提案するが、旧装置は未対応の情報を無視できる。IETFの状態記録は個人提出のInternet-Draftとし、IANAの登録簿では1がTRILL、2から65535は未割当だ。正式割当、制御装置の認可規則、実際の鍵配送記録が運用判断の材料になる。