要約

  • UDP版CoAPのMessage IDは、メッセージ重複の検出とACK/Resetの対応付けを担う。Tokenは対応するエンドポイント情報とともに、応答を未完了の要求へ結び付ける。
  • Tokenの一致は相関の受領証であり、人、端末所有者、認証主体、権限、現在の資源状態、アプリケーションや物理動作の完了を単独では証明しない。

設計の境界を確かめるには、何が追加されたかだけでなく、何が削除されても動くかを見るとよい。

RFC 7252のCoAPはUDP上でMessage IDとTokenを使う。RFC 8323はCoAPをTCP、TLS、WebSocketsへ載せる際、TypeとMessage IDを取り除いた。信頼性のあるトランスポートが再送と重複排除を引き受けるからだ。一方、Tokenは残った。TCPはバイトを確実に届けられても、どのCoAP応答がどのCoAP要求に対するものかまでは知らない。

Carsten BormannはRFC 7252の3人の著者の一人であり、RFC 8323では著者一覧の先頭に記載される。この二つの文書は、同じ人物の経歴を飾る材料というより、二種類の状態を混同しないための比較装置として読める。

Message IDの寿命は交換時間で終わる

UDPではACKが失われる。Confirmableメッセージを送った側は再送し、受信側は同じ送信元エンドポイントから同じMessage IDを再び見ることがある。RFC 7252では、重複したConfirmableの各コピーに応答しつつ、通常は中の要求または応答を一度だけ処理する。

Message IDは16ビットで、同じエンドポイントとの通信ではEXCHANGE_LIFETIME内に再利用してはならない。ACKまたはResetを照合するときも、数値だけでなく相手側エンドポイントが一致する必要がある。従って、証拠の単位は「42番」ではなく、エンドポイント、値、時刻、メッセージ型、再送状態を含む。

ここで分かるのは、同じメッセージ交換をもう見たか、届いたACK/Resetがどのメッセージに属するか、という範囲である。同じ利用者か、同じ会社の装置か、同じ業務指図かは別問題だ。

ネットワークが一つの要求を二度運んでも、アプリケーションが二度処理したとは限らない。逆に、CoAP層が重複を正しく除外しても、アプリケーション内部の再試行が同じ作用を二度起こすことはある。Message IDの台帳と業務操作の台帳を一つにしてはいけない。

Tokenは要求待ちテーブルの索引である

Tokenはクライアントが作り、サーバーは結果となる応答へ変更せずに入れて返す。クライアントはその値と相手側エンドポイントを使い、ローカルに保持する未完了要求を探す。RFC 7252は、これを「request ID」と呼ぶこともできたと説明する。

一意性の範囲は、現在使われているTokenと送信元・宛先エンドポイントの組である。別エンドポイントなら同じ値を使える。宛先ごとに要求が直列で他のTokenがなければ、空のTokenも正当になり得る。自分が生成していないTokenを受け取ったエンドポイントは、内容や構造を推測せず不透明な値として扱わなければならない。

この規則は、Tokenを利用者名や資格情報として読むことを拒む。サーバーはクライアントのローカル索引を反射するだけで、その索引に埋め込まれた意味を承認していない。

piggybacked応答では、ACKのMessage IDと応答のTokenが同時に一致する。分離応答では、Tokenが元の要求を追跡し、新しいメッセージは別のMessage IDを持つ。この差を保存しないログは、ACK待ちの障害と応答待ちの障害を区別できない。

UDPとTCPを同じ試験で比べる

運用チームは、同じアプリケーション動作をUDPと信頼性のあるトランスポートで試すことで、責任範囲を切り分けられる。

UDPだけで再現するなら、Message IDの再利用、重複キャッシュ、ACK/Reset、再送タイマー、交換寿命が候補になる。両方で再現するなら、Token生成、要求待ちテーブル、エンドポイントまたは接続への束縛、プロキシ、応答処理を先に見る。TCP/TLSだけなら、フレーミング、接続再確立、セッション管理も加わる。

TLS接続で相手を認証できる場合でも、認証結果はTLSセッションの証拠である。Tokenはそのセッション上の要求相関に使われる。セッション再開、証明書更新、要求タイムアウトは別々に発生するため、token_verifiedという一項目へまとめると失効条件を表現できない。

薄い共通仕様が強いのは、すべてを一つの番号へ押し込むからではない。独立した実装が最低限のフィールドで協調し、残る判断を各運用者へ返せるからである。

ランダム性が防ぐのは見えない攻撃者の推測

トランスポート層のセキュリティを使わない場合、RFC 7252は非自明でランダムなTokenを推奨する。一般のインターネットに接続するクライアントには少なくとも32ビットのランダム成分が勧められる。目的は、経路外の攻撃者が未完了要求のTokenを推測し、偽応答を差し込むのを難しくすることだ。

Message IDは通常連番で推測しやすく、分離応答なら元のMessage IDに頼らず攻撃できるため、この防御にはあまり寄与しない。

だが、ランダムなTokenは本人確認ではない。経路上の観測者は値を読める。正規の中間装置は自分のホップの値を知る。乱数生成器が壊れれば反復する。古い要求状態が残れば遅延応答を誤って受け入れる可能性もある。

監査には、Token長、生成方式、再利用範囲、待ち時間、エンドポイント、観測点、セキュリティモードを残す必要がある。プライバシー上、原値を広いログへ出せないなら、必要な結合を保つ鍵付きダイジェストなどを使える。値を隠すことと、意味の境界を消すことは違う。

プロキシの向こうでは別のTokenになる

CoAPのTokenはホップごとの機能である。中間装置は下流クライアントのTokenとトランスポートアドレスを保持し、上流サーバーへは自分の要求と自分のTokenを送る。上流応答を受け取ると、ローカルの対応表から下流情報を復元する。

従って、サーバー側で採取したTokenだけから、元のクライアントを特定することはできない。必要なのは、下流観測、上流観測、それらを結ぶ中間装置のローカル記録である。インターフェース、生成時刻、失効時刻、ソフトウェア版も必要になる。

監視基盤が全経路のUUIDを追加すること自体は有用だ。しかし、それはCoAPが線上で運んだ識別子ではなく、基盤が作った派生オブジェクトである。マッピング処理とログ保管が誤れば、UUIDも誤る。由来を明示しなければ、便利な索引が偽のプロトコル事実になる。

状態を往復させても責任は往復しない

RFC 8974は、要求ごとの状態の一部を長いTokenへ直列化し、サーバーが反射した値からクライアントが復元する方法を扱う。著者はKlaus HartkeとMichael Richardsonであり、Bormannではない。本稿では、先行するToken設計を拡張したときの限界を見るために用いる。

同RFCは「stateless」が単純化であると明記する。サーバーごとの状態、Token生成、輻輳制御は残る。UDPのConfirmableならメッセージ交換状態も残る。拡張Tokenへ依存する前には、別の確実な仕組みがない限り、状態を持つ要求で対応能力を確認しなければならない。

直列化した状態には完全性、リプレイ防止、鮮度、機密性、形式更新の対策が要る。大きすぎるTokenは制約ノードのメモリを圧迫する。複数の「状態を持たない」中間装置が連なると、各ホップの情報が追加されて値が成長する。

サーバーが返したのは不透明なバイト列である。中身の正しさを証明したわけではない。クライアントは自分が作った状態を自分の保護方式で回収する。保管場所は変わっても、判断主体は移らない。

調査記録を九つの欄に戻す

最初の欄は観測点と時刻。次にトランスポート、エンドポイントまたは接続。第三にセキュリティモード、セッション、認証された相手の主張を置く。

第四はUDPでのType、Message ID、再送、重複判定。第五はToken長と安全な値表現、生成・再利用方針。第六はメソッド、対象、待機要求。第七はACK/Resetと応答形式。第八は応答コード、資源版、鮮度。第九は認可、アプリケーションのコミット、装置の独立した結果である。

同じ行に表示しても、同じ主体の事実にはならない。セキュリティ担当は相手認証を、クライアント実装は相関を、プロキシはホップ対応を、サーバーは認可と資源処理を、装置所有者は物理結果を管理する。

後から一つのsuccessへ圧縮するなら、元の欄を消してはならない。要約は証拠の上に置くもので、証拠と入れ替えるものではない。

Bormannの名前にも同じ境界を適用する

2026年8月30日に確認したIETFプロフィールは、Carsten Bormannについて65本のRFC、CoREとThing-to-Thing Research Groupの議長などを掲載する。これは時点依存の経歴情報である。

文書から確定できるのは、RFC 7252の共同著者、RFC 8323の先頭著者という役割だ。両文書は公開審査を受けたIETFの集団的成果であり、一人の所有物ではない。特定実装の適合性や運用判断は、作者名ではなく稼働コード、設定、採取記録、状態遷移、結果で確かめる。

参加と著者性を証拠として尊重し、他者を拘束する権限へ膨らませない。同じように、Tokenの一致を正しく評価し、人物の証明へ膨らませない。狭い結論は弱い結論ではない。反証可能な結論である。

Tokenは返答を見つけた。その先を証明するのは、別の受領証だ。

出典