要約

  • RFC 3340 は、BEEPチャネルに閉じた取引識別子と、APEXサービスのデータに埋め込まれて要求元の離脱後も残り得る識別子を分けていた。
  • 同じエンドポイントへ後から接続した別のアプリが最初のアプリへの応答を受け取れるため、エンドポイント名と識別子は相関を示しても、所有権や現在の実行権限までは示さない。

この問題は後世の批評家が見つけた穴ではない。RFC 3340自身が第6.1.1節で例示している。あるアプリケーションがエンドポイントとして接続し、取引識別子を埋め込んだデータをサービスへ送り、その後リレー網から離脱する。しばらくして二番目のアプリケーションが同じエンドポイントとして接続し、自分の要求も送る。そこへ、最初の要求に対するサービスの応答が、最初の識別子を伴って届く。

配送先は間違っていない。現在そのエンドポイントを担うアプリへ届いている。識別子も間違っていない。過去の要求と応答を結んでいる。それでも、受信したアプリがその要求の正当な後継者であるとは限らない。RFCの短い例は、名前の連続性、接続の連続性、処理主体の連続性を別々に扱わなければならない理由を示す。

チャネルで終わる識別子、データの中で残る識別子

APEXはBEEP上で動作する。エンドポイントとリレー、またはリレー同士のモードでは、取引識別子はBEEPチャネルの寿命に限って意味を持つ。接続が解放されればチャネルは消え、アプリケーションはリレー網に接続していない状態へ戻る。attach の識別子を別の接続へ持ち越しても、その操作の文脈は残らない。

一方、APEXサービスとの通信では識別子が転送データの中へ入る。サービスが処理を続ければ、元の接続がなくなった後にも応答が返り得る。そのためRFCは「潜在的に長期間存続する」と記した。そして曖昧さを減らすため、アプリが生成する値は予測困難に見えるべきだとした。

予測困難性は必要でも十分ではない。衝突しにくく、第三者に当てられにくい識別子は、要求を出したプロセスの身元を証明しない。離脱時に要求が取り消されたか、再接続したワークロードが旧作業を継承したか、応答を実行してよいかも示さない。相関キーに主体の証明を背負わせると、便利さが証拠の欠落を隠す。

ok の意味は処理段階ごとに違う

第4.4.4.1節の順序も重要である。リレーは、BEEPクライアントが申告された送信元を代表してデータを送る権限を持つか確認し、データ単位のオプションを処理した後で ok を返す。その後に送信元単位のオプションと各受信者を処理する。したがって最初の ok は入口での受理を示すが、後段完了の証明ではない。

相手が別の管理ドメインにいれば、次のリレーへAPEXセッションを確立し、新しいデータを送り、そのリレーから ok を受けた時点で受信者が処理済みとみなされる。同じ管理ドメインなら、アクセス許可と現在の接続を確認し、対象アプリへデータを渡す。アプリが固有処理を行い ok を返して初めて、その受信者が処理済みになる。それでも利用者や業務の成果までは証明しない。

statusRequest は別の証拠線を作る。対象となる各リレーが報告サービスを通じて後から statusResponse を送り、targetHop を all にすればデータがリレー網を通過した跡を追える。ただし、それは初期応答の意味を拡張するものではない。追跡情報は私設網の構造を漏らすこともあり、RFC 3342は管理境界の入口・出口以外で無効化する選択肢を示した。

認証された名前と要求の所有者

APEXはDNS SRVで管理ドメインのリレーを探した。RFC 3340は、リレーの完全性がDNSとDNSを利用するアプリケーションに依存し、BEEPの開始側が待受側を認証すれば追加保証を得られるとする。BEEPピア認証とアクセス方針により、あるピアが特定エンドポイントとして接続・送信してよいかを制御できる。内容を端末間で認証したければ、ホップ単位の保護だけでなく内容自体への署名が必要だった。

しかし認証の境界を越えて解釈してはいけない。認証は「このピアがこの名を使う権限」を支えても、「このプロセスが過去の要求を所有する」ことまでは支えない。署名済みの古い応答は、サービスが確かに送った内容を強く証明できる。それでも、新しい接続世代がその内容を実行してよいかは別の判断である。

保存すべき台帳には、論理エンドポイント、認証済みピア、BEEPチャネル、接続世代、プロセスまたはワークロード、要求識別子と生成方式、要求本文のハッシュ、サービス側の永続受領、各リレーの確認、状態報告、離脱、次の接続、応答本文のハッシュ、受信世代、採用・隔離・破棄の判断、冪等状態、観測された結果がある。エンドポイント名と識別子はこれらを結ぶ索引であって、台帳そのものではない。

Historicになった理由と、残った教訓

RFC 3340は2002年7月に標準化過程の文書として発行された。アクセスサービスのRFC 3341、オプション集のRFC 3342、プレゼンスサービスのRFC 3343と一組を成す。2012年7月29日、IETF Datatrackerは四文書をHistoricへ変更した理由を記録した。IETFが知る限りこれらの実装は配備されておらず、同等の機能は広く配備されたXMPP、すなわちRFC 6120とRFC 6121が提供していたという。

この記録から言えるのはそこまでである。取引識別子の設計が不採用の原因だったとは書かれていないし、技術的欠陥や事故も証明しない。標準の採用結果と、仕様に記された証拠境界は分けて読むべきだ。コンテナ、ジョブキュー、コールバック、フェイルオーバー後のサービスにも、同じ名前の裏で実行者が交代する問題は残る。

遅い応答をすべて拒否する必要はない。正しいサービスが送り、改ざんされず、旧要求に一致する応答は有用である。ただし現在の受信者がその要求を引き継いだという事実を、別の受領証で結ばなければならない。「届いた」「対応した」「私が扱う権限を持つ」は三つの判断であり、一つの識別子にまとめてはならない。

出典