要約
draft-ietf-core-conditional-attributes-14は、CoAP Observeにしきい値、変化幅、帯域、エッジ、時間制御を加えるが、静かな通知列を連続した安全状態へ変換するものではない。- 有効な判断には、個別パラメータの対応、サンプリング、条件評価、通知義務、送信時刻、プロキシ越しの配送、ACK、アプリケーション結果を分けた証跡が要る。
ACKの先に残った空白
温度通知はConfirmableで送られ、クライアントはACKを返した。監視基盤はそれを「対応済み」と表示した。しかしACKを返した受信プロセスと、冷却装置を操作するアプリケーションは別だった。後者は停止していた。
通信は成功した。制御は成功していない。両方をひとつの緑色の状態に畳むと、メッセージの権限が物理装置まで拡張されたように見えてしまう。
第14版は2026年9月14日に公開され、2027年3月18日に失効する。CoRE WGの有効なInternet-Draftで、Standards Trackを意図しているが、Datatracker上は最終コメントで指摘された問題のため改訂が必要な状態だ。RFCでも実装証明でもない。
提案の目的は、Observeで受け取る更新を必要なものだけに絞ることにある。サーバーは条件付きURIごとに資源状態の投影を持ち、条件に合う表現だけを通知する。省電力と帯域節約には合理的だが、通知されない状態が存在し得ることを前提にしなければならない。
しきい値は履歴を保存しない
c.gtとc.ltは、最後に報告した値を基準に境界を横切ったときに働く。上限を越えた後で値が上がり続けても、その条件だけでは追加通知は出ない。何回通知されたかから、危険域にいた時間や最大値は復元できない。
c.stは最後の報告値との差を見る。c.pmin中に複数のサンプルがあれば、最後の値だけが残る場合がある。隣り合う通知の差が指定したステップより大きくても矛盾ではない。
c.bandは上下限の並びによって帯域内または帯域外を通知対象にする。c.edgeはブール値の一方向の変化を選ぶ。複数条件が同時に成立しても通知は一つで、優先順位はない。ワイヤ上の一件は、物理世界の一件と対応しない。
知らない条件は失敗にならない
if="core.conditional"は一般的な対応を示せるが、個々のパラメータ一覧は示さない。広告自体も任意である。したがってマーカーの有無から特定条件の実装を断定できない。
構文的に正しいが未対応の条件を受けたサーバーは、それを無効として残りのObserveを処理しなければならない。未対応だけを理由に拒否してはならない。2.05 ContentとObserve Optionが返っても、要求した全条件が実行中とは限らない。
型が違う、期間が正でない、最大期間が最小期間より短い、といった不正値は4.00 Bad Requestになる。増幅の危険がある短すぎる期間を嫌って登録しない場合は、通常のGET応答を返しつつObserve Optionを付けないことができる。成功コードと登録成功は別の事実だ。
評価周期と通知周期
c.epminは、クライアントがそれより頻繁な評価を望まないことを示す。c.epmaxは、次の評価までサーバーが待てる最大時間を定める。いずれも連続測定ではない。短い異常は二つの評価の間で完結し得る。
c.pminは通知間隔の下限であり、成立済み条件の送信を待たせる。c.pmaxは状態が同じでも通知間隔を上から抑えるが、同じ値で固定したとしてもハードリアルタイム契約にはならない。草案はベストエフォートだと明記する。
物理変化、サンプル取得、条件評価、通知可能化、送信、受信には別々の時刻がある。最後のパケット時刻だけでは、どこで沈黙が生じたか分からない。
プロキシは同じ値を同じ証拠として扱わない
Observeはキャッシュとプロキシを利用できる。第14版は、同じ表現を繰り返すc.pmax更新がプロキシによってクライアントへ届かない可能性を認め、Max-Ageをc.pmax以下にする緩和策を示す。サーバーの送信ログはクライアントの受領ログではない。
Confirmable通知は配送証跡を強くするが、ACKが証明するのは対象メッセージの交換である。計測の連続性、以前の欠落、アプリケーションによる解釈、アクチュエータの実行は別に確認する必要がある。
Token、Observeの順序値、信頼できるトランスポート、OSCOREも同様に範囲を持つ。正しい暗号保護は、正しい物理結論を自動生成しない。
投影を取り違えずに終了する
明示的な取消しでは、元の条件付きURIを再送する必要がある。同じ資源でも異なるしきい値は別の投影だ。画面から設定を消しただけでは、サーバー上の関係が終了した証拠にならない。
終了証跡はエンドポイント、Token、完全なURI、取消しOption、応答を結び付ける。そうしなければ、忘れられた観測が電池と帯域を使い、誰も見ていない通知を送り続ける。
静けさを説明する八段階
資源の能力、投影の登録、個別条件の対応、サンプリングと量子化、条件計算、送信スケジュール、プロキシ越しの配送、アプリケーションと物理結果をそれぞれ記録する。この連鎖が閉じて初めて「通知がなかった」の範囲を述べられる。
閉じていなければ、静けさは安定、サンプル間の異常、無視された条件、遅い評価、pminによる抑制、キャッシュ、損失、期限切れ、アプリケーション停止のどれでもあり得る。
凍結した資料は製品、普及率、事故、損失率、安全認証を証明しない。参照される増幅攻撃文書も失効したIRTF Internet-Draftで、特定攻撃の記録ではない。
Lu Hengの記録と権限の区別を当てはめれば、条件付き投影はサーバーが見て送った範囲の調整記録である。運用上の真実を決める権限は、物理状態と実行結果を観測できる場所に残る。
情報源
- Datatracker 第14版
- Datatracker 履歴
- IETFアーカイブ 第14版
- RFC 7252 CoAP
- RFC 7641 CoAP Observe
- RFC 6690 CoRE Link Format
- RFC 8323 信頼できるトランスポート上のCoAP
- RFC 8613 OSCORE
- RFC 9175 CoAP Token処理
- 失効したCoAP増幅攻撃ドラフト
- Lu Heng — On Authority, Belief, and the Internet’s Addressing System
- Lu Heng — Running-Code Primacy
- Lu Heng — The Stability Fallacy
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
