要約

  • RFC 5203 では、提供可能性の通知、登録要求、認可、失敗、取消しが別々の状態遷移として表現される。REG_RESPONSE はサービス利用の完了通知ではない。
  • 登録は更新可能で、期限前にも取り消せるソフトステートである。付随サービスが同じ状態を保持し続ける保証ではない。
  • 運用上の健全性には、要求側と登録側の状態、サービス側の受理、設定世代、実利用の通信、最終結果を結び付けた記録が要る。

消えた取消しと残った緑色

あるホストが HIP のサービス登録に成功し、120 秒の有効期間を受け取ったとする。監視画面は署名を検証し、ローカル時計から失効時刻を計算して緑色を表示する。

その後、登録機に接続されたサービスが設定変更によって状態を削除した。登録機はゼロ期間の応答で取消しを知らせようとする。しかし経路変更のため通知は要求側に届かない。要求側の時計ではまだ有効であり、画面も緑色のままだが、次のサービス固有要求は処理されない。

これは説明のための仮想例であり、製品や実障害についての主張ではない。注目すべき点は、最初の登録応答が偽だったわけではないことだ。取消しが観測されないことも、登録期間が未来に残ることも事実である。それでも、現在のサービス状態は導けない。

運用システムが「取消しを受けていない」を「稼働している」へ変換するとき、未知が肯定に書き換えられる。

共通仕様はサービスの手前で止まる

2008 年の Experimental RFC である RFC 5203 は、HIP ホストがランデブーサーバーやミドルボックスなどのサービスへ登録するための共通拡張を定めた。一方で、サービスの発見、登録機の探索、登録後のサービス利用方法は規定しない。

この範囲は合理的である。異なるサービスには異なる準備条件と実行結果がある。共通層が一つの成功意味を押し付ければ、個別サービスが本当に観測した事実を隠してしまう。

RFC の登録は、要求側と登録機が保持する共有状態であり、有限の期間と再登録による更新を持つ。その状態により要求側はサービスから便益を受けられる。しかし、便益を受けられる状態と、便益を実際に受けた結果は別である。

さらに、REG_REQUEST の処理成功により登録機に状態が作られ、サービスにも「場合によって」作られると記されている。この留保は重要だ。登録機の成功を、そのままサービスプロセスの成功へ転記してはならない。

REG_INFO は予約票ではない

登録機は REG_INFO で提供する登録タイプを通知する。過渡的な事情でサービスを提供できない場合は、タイプを含まない空の REG_INFO を送るべきだとされる。再び提供可能になれば、UPDATE で現在の集合を知らせる。

この設計は、提供可能性が時間とともに変わることを最初から認めている。通知は送信時点の声明であって、将来の容量予約ではない。要求側は最後に受け取った関連通知を根拠に要求できるが、その時点から利用時点までに状況は変化し得る。

REG_REQUEST は希望するタイプと期間を示す。登録機は I2 に含まれる Host Identity で要求側を認証し、ローカルポリシーにより認可を判断する。成功したタイプは REG_RESPONSE、完了しなかったタイプは REG_FAILED に入る。

RFC 5203 では、失敗タイプ 0 は追加資格情報、タイプ 1 は登録タイプの利用不能を表す。これらは認可時点の理由である。後でサービスが消えたことを自動的に説明するものではない。

有効期間は状態の寿命であって稼働率ではない

要求側が求める期間と、登録機が与える期間は一致しなくてよい。要求値が通知された最小・最大の範囲内でも、戻り値が同じだと期待してはならない。

付与された期間は、次の状態遷移がなければ登録をいつまで扱うかを決める。更新や期限切れのために不可欠な情報である。しかし、サービスの可用性目標ではない。

ゼロ期間は取消しに使われる。要求側は期限前に取り消せる。登録機や付随サービスも、設定変更などで提供できなくなれば期限前に取り消せる。攻撃時や資源不足のときに登録機が状態を削除できることも、セキュリティ上の考察に含まれる。

したがって、監視には作成時刻、最終更新、予定失効、取消し送信、取消し受信、設定世代を別々に持たせる必要がある。サービス独自の状態には、その状態の識別子と消滅理由が必要になる。

正しい署名から広すぎる結論は出せる

REG_RESPONSE は弱い証拠ではない。HIP によって保護され、認証とポリシー判断の後に生成される。登録機がどのタイプをどの期間認めたかという問いには、適切な証拠である。

しかし署名は文の主語と内容を保護するのであって、文に書かれていない結果を追加しない。登録機の正しい署名は、別プロセスのメモリを保持せず、将来の経路を固定せず、アプリケーションの応答を生成しない。

強い暗号証拠ほど、監視や監査で再利用したくなる。ここに危険がある。一つの認可応答が、探査省略、アラーム抑制、提供実績の証明にまで使われる。

対策は証拠を捨てることではない。正確な範囲を添えることだ。要求者、登録タイプ、期間、ポリシー、設定世代を保存し、次の層から別の受領記録を受け取る。

RFC 8003 の改善も実行証明ではない

RFC 8003 は 2016 年に RFC 5203 を廃止し、Standards Track の拡張として更新した。要求者ごとの提供意思を明確にし、証明書に基づく認可失敗を拡張し、資源不足の失敗タイプを追加した。

失敗理由が細かくなれば、再試行や調査は改善する。資格情報不足、証明書問題、タイプ利用不能、資源不足を区別できるからだ。それでも、通知、要求、応答、失敗、有限期間、取消しという基本構造は残る。

新しい失敗コードは登録判断の説明である。サービスの実行ログではない。RFC 8003 を実装したという表明も、実際のバイナリ、設定、現場のメッセージなしには稼働証拠にならない。

仕様の系譜は設計を説明する。ランニングコードの状態は観測で説明する。片方をもう片方の代わりにしてはならない。

個別サービスが最後の一段を証明する

RFC 5203 は、登録タイプが追加の HIP パラメーターに依存できるとする。その意味はタイプ固有仕様が決める。これは最小共通仕様として健全である。

ランデブーサービスなら、登録された結合、後日の I1 受信、転送、相手側の独立応答が証拠になる。ミドルボックスサービスなら、設置された規則、正確な一致条件、所有者、期間、通過したパケットが必要になる。共通の REG_RESPONSE だけでは、どちらの実行も証明できない。

運用の連鎖は次のように残せる。

通知済み → 要求済み → 認可済み → 登録機状態あり → サービス状態あり → 利用済み → 結果あり。

一段が失敗しても、前段の事実が偽になるとは限らない。だからこそ、各段を残すと障害位置が見える。サービス確認が取れなければ「不明」と表示すべきであり、認可から「正常」を補完してはならない。

取消しが消えても追跡できる記録

最低限の受領記録には次が含まれる。

  • HIP と登録拡張の版、ビルド、設定リビジョン；
  • 要求側と登録機の HIT；
  • REG_INFO の指紋、時刻、タイプ、期間範囲；
  • REG_REQUEST の指紋、タイプ、希望期間；
  • 認証された主体、資格情報、ポリシー版、判断者；
  • REG_RESPONSE または REG_FAILED の指紋、結果、付与期間；
  • 両側の状態 ID、作成、更新、失効；
  • サービス側の状態 ID と明示的な受理；
  • 取消し、退避、再起動、設定変更、資源圧迫；
  • サービス固有の要求、応答、経路、最終結果；
  • 観測できなかった区間。

この記録があれば、取消しが届かなくても二つの履歴が食い違った時点を特定できる。登録機を、観測していないサービス結果の責任者にする必要もなくなる。

RFC 5203 の「成功」は狭いから弱いのではない。狭いから正確である。その正確さを保つことが、サービス可用性を別途測る出発点になる。

出典